[pkg-dhcp-devel] Bug#459813: [ISC-Bugs #21695] [madduck at debian.org: Bug#459813: ] Really: unreliable DHCPACK delivery to dhclient
David Hankins via RT
dhcp-bugs at isc.org
Tue Jul 13 21:22:07 UTC 2010
The DHCP software uses a common library for socket handling code. Because of
RFC 2131 requirements for the ability to receive 'directed unicasts' to
unconfigured addresses (without ARP), and also for platform agnostic support
for the all-ones limited broadcast address (255.255.255.255), we use a raw
socket on a interface-by-interface basis in order to receive DHCP messages.
This socket receives all DHCP packets for that interface, and is used to
transmit all "strange" directed unicasts, broadcasts, etc.
All DHCP software in the package - dhclient dhcrelay dhcpd - therefore has the
limitation that it will only receive packets physically received on the
interface it is configured to handle. If the packet is received on any other
interface, it is not read by an open raw socket by the DHCP software and
therefore isn't received.
The standard BSD socket on UDP ports 67/68 opened by these same pieces of
software is used for outbound unicast transmission only. We call it "the
fallback interface." This socket allows us to send UDP queries or replies in
unicast, using IP routing or ARP, without having to implement both of those
features over our existing raw socket. But: Any packet received on this BSD
socket is discarded. In future I intend to examine if we can set the socket
receive buffer size to zero to eliminate the extra read overhead, but I am
Consequently, if the client configuring "intf0" is replied to by a DHCP server
that by unicast directs its reply to the client by first routing it to "intf1",
our client will be unable to see the reply. It will continue to attempt to
retransmit its renewal until REBINDING time. At REBINDING time, the client
switches to the raw socket as a limited broadcast on the connected interface -
this packet is picked up by a relay agent and the reply from the DHCP server is
directed through the relay agent, thus again reaching the raw socket on the
This is the only scenario I can imagine the described behavior happening.
Please advise if this doesn't sound familiar at all. Sorry for this known
limitation in our DHCP client software, as well as the other corner cases that
aren't well supported in our DHCP software suite. I hope to consider all of
these corner cases in the manufacture of our new IO system in BIND 10's DHCP
software (hopefully also eliminating the need for long-term raw sockets).
I'm not certain without examining software if switching to a single client
governing both interfaces actually will resolve the issue (I don't know if we
take the source interface structure into account when searching xid's for
matching DHCP state sessions). I think it is probable that using a single
dhclient is an effective workaround.
Note that this can change significantly if the client is built with USE_SOCKETS
instead of USE_LPF. But in this case the client is also incompatible with
Windows DHCP server. So I presume USE_LPF is in use.
Note also that the DHCPv6 software does not have this limitation owing to
multiple reasons, but primarily thanks to link-local addressing it does not
need or use raw sockets.
More information about the pkg-dhcp-devel