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 getting sidetracked. 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 client's interface. 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. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
