dhclient exiting on lease expiry
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 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 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. 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
Re: dhclient exiting on lease expiry
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
Re: dhclient exiting on lease expiry
On 05/13/13 15:19, Kenneth R Westerback wrote: 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? 5.2 release. 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. Ok, I can live with that, time to sort out the temporariness (sp?) of the alias. 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. I feel a new tagline in the offing ;-) 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. No, it does remove the alias as well. I was comparing the behaviour of a forced renewal to lease expiry on the dhclient daemon. 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. Me neither, but there is a functional link and avahi does seem to be acting in relation to dhclient behaviour. I provided the context if anyone had a light-bulb moment because of it. I'll report what route monitor reports when the lease next expires. 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. Nice to hear, I'll sort myself out re aliases. -- Mike
