Yet another obscure problem. /etc/dhcp/dhclient-exit-hooks is supposed to run (if it exists) after dhclient has accepted a new DHCP IP from your ISP and done all its stuff. One would assume that would include setting the IP on your actual interface.
I have a problem where a script that /etc/dhcp/dhclient-exit-hooks talks to (async through a named pipe, so after that it won't block) then does some stuff based on what /sbin/ip says the ip address is. I am expecting this to be the *new* ip address. But what it seems to be doing is still using the old ip, meaning (if I'm following my extremely complex scripts properly) /sbin/ip is still returning the old ip at that point.
Does anyone have experience with dhclient, or its hooks? Is this even possible? Even weirder is my scripts wait an additional 10s before checking /sbin/ip so even if there was a short delay, it shouldn't still give me the old ip.
The /sbin/ip command I use it: /sbin/ip -o -4 addr list <interface> then I parse out the address.
Is there anything in the linux networking layer that would cause an IP bind to "not show up" for >10s?
Secondly, debug testing this will be very difficult because our Shaw IP's change so infrequently. I suppose I could "trick it" by switching NICs and/or changing my NIC's MAC. I've never done that before, is that easy and safe?
On 14-01-02 01:15 AM, Trevor Cordes wrote:
Yet another obscure problem. /etc/dhcp/dhclient-exit-hooks is supposed to run (if it exists) after dhclient has accepted a new DHCP IP from your ISP and done all its stuff. One would assume that would include setting the IP on your actual interface.
RTFM: dhclient-script(8). The exit hooks are supposed to get called at every step of the DHCP process, and you should examine - at least - ${OPERATION} to determine what stage you're at before assuming that the new IP has already been assigned and bound to the interface.
In other words, what you're seeing is the expected (i.e. correct) behaviour.
Secondly, debug testing this will be very difficult because our Shaw IP's change so infrequently. I suppose I could "trick it" by switching NICs and/or changing my NIC's MAC. I've never done that before, is that easy and safe?
...or just put a DHCP server of your own in front of the system you're testing. Changing the MAC address will cause the cable modem (usually) to stop forwarding packets after the 2nd change, at least until you reboot the cable modem.
On 2014-01-02 Adam Thompson wrote:
RTFM: dhclient-script(8).
Been there, done that. :-) I tried to simplify my list posting a bit by not getting too in depth.
The exit hooks are supposed to get called at every step of the DHCP process, and you should examine - at least - ${OPERATION} to determine what stage you're at before assuming that the new IP has already been assigned and bound to the interface.
I'm checking $reason, but only loosely as I originally could not guess which of the 12 state changes I really cared about, so my scripts re-evaluate the whole situation on nearly every state change. Missing ip address changes is *very bad* in my situation.
In other words, what you're seeing is the expected (i.e. correct) behaviour.
I wish that were true. It's very strange as my scripts indicated in the logs that only one call to dhclient-exit-hooks was made when this change happened (happened to be on a reboot). Even if I was acting on an interim state change, it should have triggered again on the final (I guess BOUND?) state change, and so properly caught the IP change. I do not log the $reason, but I will start now.
I did find one new thing RTFMing again, since I wrote these scripts they seem to have added /etc/dhcp/dhclient-up-hooks which may be a better choice (can't think of why I would not have used that before). That explicitly says it runs "after dhclient brings an interface UP with a new IP address, subnet mask, and routes". That's exactly what I want. If it captures all possible ways an IP can change, it may be better than exit-hooks.
...or just put a DHCP server of your own in front of the system you're testing. Changing the MAC address will cause the cable modem (usually) to stop forwarding packets after the 2nd change, at least until you reboot the cable modem.
Good idea, though a bit of a pain in my situation. It would have to be a router I control the DHCP server on (to delete entries), like a full *nix box. Not sure even custom router f/w lets you do that? Definitely easier than the Shaw-fooling route. PS I find Shaw modems need a reboot on any NIC/MAC change, not just the 2nd.
Hold that thought... I found some more useful logs I was making and followed the program flow a bit deeper. Higher-up scripts seem to be seeing the correct new IP on time. I dug into some lower-level stuff and found the script that was outputting the incorrect (old) IP was getting it via DNS. The DNS, even though it's local (caching named) must be caching the old IP of the box for a while. I'll have to see where/how I'm updating that entry and either get it to update faster and flush cache, or not use DNS at all (see below).
So there probably is no problem in the dhclient stuff at all, just in where I'm pulling the IP from at a certain point.
Doh!
(If you're curious, I'm using DNS because I am resolving two hosts, one if which is "me" and one which is remote, but I don't know which is which. Or, more precisely, I was trying to avoid adding that complication.)
-
Adam Thompson -
Trevor Cordes