|Summary:||dhclient/dhclient-script: dhclient default route not working when given a /32 netmask|
|Component:||bin||Assignee:||freebsd-bugs mailing list <bugs>|
|Severity:||Affects Many People||CC:||bz, dch, emaste|
Description sigsys 2019-11-07 21:44:40 UTC
There's a certain VM where autoconfiguration via DHCP works with Linux but not FreeBSD. I have no information on how this VM is setup apart that it's hosted with KVM/QEMU. The DHCP server sends a lease with a /32 netmask. This makes adding the default route fail since it is not reachable via any interface. Linux's dhclient-script seem to usually have a special case for that and explicitly adds an interface route to the router's address. FreeBSD's dhclient-script has a special case for when the router address is the same as the leased address, but not when it's a different address that doesn't fall in the interface's subnet. With this change, DHCP just works on this VM: Index: sbin/dhclient/dhclient-script =================================================================== --- sbin/dhclient/dhclient-script (revision 354408) +++ sbin/dhclient/dhclient-script (working copy) @@ -173,6 +173,9 @@ if [ "$new_ip_address" = "$router" ]; then route add default -iface $router >/dev/null 2>&1 else + if [ "$new_subnet_mask" = "255.255.255.255" ]; then + route add "$router" -iface "$interface" >/dev/null 2>&1 + fi route add default $router >/dev/null 2>&1 fi fi
Comment 1 Dave Cottlehuber 2019-11-28 23:45:20 UTC
I have seen this in Google Cloud, Packet.net and other infrastructures. In the first case Google patched their DHCP setup to accommodate this. In the past I have manually overridden this using settings in dhclient.conf. Patch seems reasonable to me.
Comment 2 Bjoern A. Zeeb 2019-11-29 00:47:35 UTC
I thought Linux used to simply arp for an off-link gateway and then use it. I've seen this elsewhere as well with recovery images and documentation, e.g., https://wiki.hetzner.de/index.php/Cloud_IP_static#FreeBSD for static configuration. While I don't do much IPv4 anymore, it seems a proper workaround. +1 on the idea of the change (not reviewed).