On Mon, May 13, 2013 at 09:40:59AM +0100, Mike Williams wrote: > Hi, > > I have been upgrading my machines to 5.3 this weekend and I am > seeing some strange behaviours with dhclient. The config is simple: > > /etc/dhclient.conf > send host-name "pc-1"; > request subnet-mask, broadcast-address, routers, domain-name, > domain-name-servers, host-name; > > (FWIW The dhcp server serves up constant IP addresses based on the MAC) > > There is only one i/f with the wrinkle that I am temporarily running > an inet alias off the i/f as well: > > /etc/hostname.re0 > dhcp NONE NONE NONE NONE > inet alias 192.168.67.24 255.255.255.0 NONE
Upgraded from what version? Yes, the 5.3 dhclient will remove all aliases as part of taking control of the interface. So a renewal will remove the interface. In fact adding the alias should either cause dhclient to exit, or the alias will be removed when the lease is obtained. This behaviour was mentioned in the release notes: "all existing addresses on the interface are deleted when binding a new lease." > > Up to the upgrade this was ticking along with no problems. > > Now, whenever the lease expires the dhclient daemon exits taking the > inet alias with it, and I have no connectivity. I can restart > dhclient but this leaves the inet alias dead. > > /var/log/daemon shows the following (*): > > May 13 03:50:46 pc-1 dhclient[28001]: DHCPREQUEST on re0 to > 192.168.67.2 port 67 > May 13 03:50:46 pc-1 dhclient[28001]: DHCPACK from 192.168.67.2 > (00:40:63:dd:9f:c0) > ... > May 13 03:50:46 pc-1 dhclient[28001]: 192.168.67.40, not > 192.168.67.40, deleted from re0; exiting Now that is an unfortunate and insufficiently useful error message. > > However if I force a renewal with pkill -HUP dhclient I see this: > > May 13 09:10:41 pc-1 dhclient[25646]: bound to 192.168.67.40 -- > renewal in 43200 seconds. And that does NOT remove the alias? That would be contrary to my expectation. > > So it looks like an issue when the lease times out. There was > nothing in the upgrade notes, and a search through the lists on > marc.info only brings up to release note improvements, nothing about > any configuration changes that may be needed. > > (*) For full context I have avahi-daemon installed so the full > daemon log for the time the lease expired is as follows: > > May 13 01:32:24 pc-1 identd[23433]: Connection from xxx.yyy.zzz > May 13 03:50:46 pc-1 dhclient[28001]: DHCPREQUEST on re0 to > 192.168.67.2 port 67 > May 13 03:50:46 pc-1 dhclient[28001]: DHCPACK from 192.168.67.2 > (00:40:63:dd:9f:c0) > May 13 03:50:46 pc-1 avahi-daemon[10755]: Withdrawing address record > for 192.168.67.40 on re0. > May 13 03:50:46 pc-1 avahi-daemon[10755]: Withdrawing address record > for 192.168.67.24 on re0. > May 13 03:50:46 pc-1 avahi-daemon[10755]: Leaving mDNS multicast > group on interface re0.IPv4 with address 192.168.67.24. > May 13 03:50:46 pc-1 avahi-daemon[10755]: IP_DROP_MEMBERSHIP failed: > Can't assign requested address > May 13 03:50:46 pc-1 avahi-daemon[10755]: Interface re0.IPv4 no > longer relevant for mDNS. > May 13 03:50:46 pc-1 avahi-daemon[10755]: Joining mDNS multicast > group on interface re0.IPv4 with address 192.168.67.40. > May 13 03:50:46 pc-1 avahi-daemon[10755]: New relevant interface > re0.IPv4 for mDNS. > May 13 03:50:46 pc-1 avahi-daemon[10755]: Registering new address > record for 192.168.67.40 on re0.IPv4. > May 13 03:50:46 pc-1 dhclient[28001]: 192.168.67.40, not > 192.168.67.40, deleted from re0; exiting > May 13 03:50:46 pc-1 avahi-daemon[10755]: Withdrawing address record > for 192.168.67.40 on re0. > May 13 03:50:46 pc-1 avahi-daemon[10755]: Leaving mDNS multicast > group on interface re0.IPv4 with address 192.168.67.40. > May 13 03:50:46 pc-1 avahi-daemon[10755]: IP_DROP_MEMBERSHIP failed: > Can't assign requested address > May 13 03:50:46 pc-1 avahi-daemon[10755]: Interface re0.IPv4 no > longer relevant for mDNS. > May 13 04:10:10 pc-1 ntpd[18186]: 0 out of 1 peers valid > > Let the beatings with the clue bat begin. > > -- > Mike > Not sure what Avahi is doing. :-) If you capture the output from 'route monitor', you can see what RTM_NEWADDR, RTM_DELADDR, etc. messages are flying around that dhclient will be paying attention to. Bottom line: alias and dhclient do not play well together. They never have in a general sense, and 5.3 tightens things up significantly. We are looking at making them work together safely and reliably. .... Ken
