ISC DHCP 服务器正在 Fedora 10 上运行。由于它没有执行其他任何操作,所以没人费心去更新它...我注意到一些对我来说非常奇怪的行为:DHCP 服务器以广播的形式获取 DISCOVER,将 OFFER 作为单播发送到 DHCP 中继 - 然后立即将相同的提议作为广播发送。
客户端本身行为不当,它不断发送 DHCP DISCOVER 数据包,但我认为这不会导致服务器广播该提议。有谁知道为什么会发生这种情况 - 这可能是这个石器时代服务器的一个功能吗?
答案1
我不确定它是否真的有问题。DHCP 受到以下约束:RFC2131,其中明确指出(您可以自己检查,第 24 页顶部)DHCPOFFER、DHCPACK、DHCPNAK 通过单播传送发送给客户端,但某些客户端实现不允许接收此类单播,直到配置了正确的 IP 地址。
这种实现将任何 DHCPDISCOVER 或 DHCPREQUEST 消息中的“标志”字段中的 BROADCAST 位设置为 1,进而指示服务器和 bootp 中继代理使用广播传送,而不是(更常见的)单播传送。
编辑:
是的,当然:听起来你几乎从未使用过的服务器有一个这样的仅广播的 DHCP 实现。但是,如果你使用 tcpdump/wireshark 查看其初始 DHCPDISCOVER 消息,那么你可以自己检查广播位是否已设置,无需猜测。
你可以通过使用让你的生活变得更加轻松dhcpdump而不是通过过滤器tcpdump或者wireshark因为它只会捕获 dhcp 数据包,并以易于访问的方式呈现给您。例如,在我的家庭网络上,我捕获了此请求:
$ sudo dhcpdump -i wlan0
TIME: 2014-06-14 18:52:31.848
IP: 0.0.0.0 (f8:1a:67:aa:80:56) > 255.255.255.255 (ff:ff:ff:ff:ff:ff)
OP: 1 (BOOTPREQUEST)
HTYPE: 1 (Ethernet)
HLEN: 6
HOPS: 0
XID: 10929113
SECS: 0
FLAGS: 7f80
CIADDR: 0.0.0.0
YIADDR: 0.0.0.0
SIADDR: 0.0.0.0
GIADDR: 0.0.0.0
CHADDR: 00:07:88:e8:6c:cf:00:00:00:00:00:00:00:00:00:00
SNAME: .
FNAME: .
OPTION: 53 ( 1) DHCP message type 3 (DHCPREQUEST)
OPTION: 50 ( 4) Request IP address 192.168.11.52
OPTION: 57 ( 2) Maximum DHCP message size 1500
OPTION: 60 ( 12) Vendor class identifier dhcpcd-5.5.6
OPTION: 12 ( 24) Host name android-e0cf12b56a84f291
OPTION: 55 ( 9) Parameter Request List 1 (Subnet mask)
33 (Static route)
3 (Routers)
6 (DNS server)
15 (Domainname)
28 (Broadcast address)
51 (IP address leasetime)
58 (T1)
59 (T2)
让我们感兴趣的是:
FLAGS: 7f80
这当然是一个十六进制格式的数字,其第一的位是0:因此,根据RFC2131,第十页,这是一个接受单播回复的请求。如果第一个位是1,那么它将发出信号,表示 DHCP 客户端需要播送回复。