DHCP misbehavior

Question

ISC DHCP Server is running on Fedora 10. Since it's doing nothing else nobody bothered updating it... I've noticed behavior that looks very strange to me: the DHCP server gets a DISCOVER as broadcast, sends OFFER as unicast to the DHCP relay - and immediately afterwards sends the same offer as a bcast.

The client itself is misbehaving, it's continuously sending DHCP DISCOVER packets, but I don't think that could cause the server to bcast the offer. Does anyone have any idea why this might happen - is it maybe a feature of this stone-age server?

Answer 1

I am not sure it is really misbehaving. DHCP is is disciplined by RFC2131, which states explicitly (you can check yourself, top of page 24) that DHCPOFFER, DHCPACK, DHCPNAK are sent to the client via unicast delivery, except that some client implementations don't allow reception of such unicasts until a proper IP address has been configured.

Such implementations set the BROADCAST bit in the 'flags' field to 1 in any DHCPDISCOVER or DHCPREQUEST messages, which in turn instructs the server and bootp relay agent to use a broadcast delivery instead of the (more usual) unicast one.

EDIT:

Yes, by all means: it sounds like your almost-never-used server has one such broadcast-only DHCP implementations. However, if you see its initial DHCPDISCOVER message with tcpdump/wireshark, then you can check yourself whether the broadcast bit is set or not, no need to guess.

You can actually make your life much easier by using dhcpdump instead of working through the filters of either tcpdump or wireshark, because it will capture only dhcp packets, and will present them to you in an easily accessible fashion. For instance, on my home network, I captured this request:

 $ 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)

The line that interests us is:

 FLAGS: 7f80

This is of course a number in hexadecimal format, whose first bit is 0: thus, according to RFC2131, page ten, this is is a request that accepts a unicast reply. If the very first bit had been a 1, then it would have signalled that the DHCP client required a broadcast reply.