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
