dhclient: renewal failure due to invalid route selection

[Guillaume Nault]

Hi,

Here's a problem that has already been reported a few times on
dhcp-users[0]. The problem is that dhclient sends its unicast packets
using the fallback interface. Since the socket used by the fallback
interface isn't bound to any network device, unicast packets are sent
following the local routing tables. The output interface can then be
different from the device to be configured, which prevents dhclient to
complete its renewal phase (thus requiring a new discovery after the
first lease expires).


The problem generally goes with multi-homed hosts. E.g. on a host with
two interfaces, both configured with DHCP, where both interfaces
get an IP address on the same subnet.

For both interfaces, the discovery stage works fine and they get their
first lease correctly: packets are sent using the interface to be
configured (at this stage packets are broadcasted using the packet
interface).

Once interfaces enter the renewal stage, they use the fallback
interface to send a unicast DHCP Request. Since packets are now routed
depending on the local routing tables, both DHCP Requests are likely to
be routed through the same interface (as both interfaces belong to the
same subnet). So one of the DHCP Request is sent by an interface which
is not the interface to be configured. This packet is discarded by the
DHCP server and dclient then has to re-enter the discovery stage after
timeout.


FWIW, the attached patch is the POC I wrote to work around this issue
(rebased on latest master commit 001b9d53). It just temporarily binds
the fallback interface with SO_BINDTODEVICE. That works, but an
upstream fix would be very much appreciated. Several users seem to get
hit by problems originating from this issue[1].


Regards,

Guillaume


[0]: see my original report at https://lists.isc.org/pipermail/dhcp-users/2013-February/016398.html
     and another one https://lists.isc.org/pipermail/dhcp-users/2014-April/017835.html

[1]: https://community.ubnt.com/t5/EdgeMAX/WAN-dropped-DHCP-renew-fixes-it/m-p/783774
     https://bugzilla.redhat.com/show_bug.cgi?id=1177351
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bind_fb_iface_001b9d53.patch
Type: text/x-diff
Size: 2109 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/dhcp-hackers/attachments/20141230/13da7753/attachment.bin>