GNOME Bugzilla – Bug 644798
Please terminate 'dhcpcd' using the correct '-k' option
Last modified: 2013-05-15 13:59:39 UTC
If my modem/router is switched off (e.g. overnight), I can't reconnect - via Ethernet or wireless - the next time it's switched on, without having to mess around first. This is because your script doesn't terminate 'dhcpcd' via the '-k' option. The effect is that the stale ".lease" file from the previous session (day) remains in "/var/lib/dhcpcd/". This ".lease" file is automatically reused when reconnecting, but my modem/router forgot about it while switched off (e.g. overnight). This means that initial connection attempts are rejected until I delete it. I'm guessing that all users with NetComm modem/routers - and probably others - would be facing this problem every time they switch theirs on. Will you please terminate 'dhcpcd' using the '-k' option in future releases? For example, instead of using "/usr/bin/killall dhcpcd", you would use "/sbin/dhcpcd -k [interface]". I have already tested this here and I can confirm that the stale ".lease" file is deleted as expected.
So this certainly is a problem; however, there's another side to the problem. Terminating and releasing the lease means that the lease must be re-acquired if the connection happens again. That usually means an additional 2 - 5 seconds of time spend doing the DHCP requests to get a new lease, whereas a simple renew can save a bunch of time. If we released the lease every time the connection went down, there wouldn't much point to having leases in the first place... So this is a tradeoff between dealing with routers that don't properly handle DHCP lease lifetimes, making DHCP lease acquisition fast, and reacquiring a previous address to ensure uninterrupted TCP communications if a glitch happens. In short, I'm not quite sure what to do here. We certainly want the advantages of faster DHCP and address reacquisition, but we also don't want things to fail. So perhaps the solution is to figure out how to get dhcpcd to request a completely new lease if the renew fails? That would fix your problem while at the same time preserving the benefits of having leasefiles at all.
I was kinda hoping that you wouldn't realise the other side to the problem :-). It's all good, as I'm happy to work with you towards a compromised resolution. An Arch Linux developer provided me with a similar response, which you might be interested in reading here: https://bugs.archlinux.org/task/23282 I'll see if I can determine exactly how my NetComm NB6W handles the lease-rejection process. I'll post the details here once I've figured out what's happening.
Created attachment 183483 [details] Output given when lease is unrecognised
I've thought more about your opinion that the lease file should remain, to permit quickly reacquiring the same IP address after a glitch occurs. I think the lease file would still be there after a 'glitch', since it would only be removed when the user intentionally disconnects (or reboots). Okay, I've worked out what's going on at my end. You're right that my modem/router is behaving oddly. You can see from the attached output what happened when I then tried to reconnect. Instead of rejecting the (now) unrecognised lease, my modem/router acknowledged it and set the IP address to "0.0.0.0". I just posted a more detailed description of this new information to the 'dhcpcd' mailing list. You can view my email here: http://roy.marples.name/archives/dhcpcd-discuss/2011/0310.html. I will also contact the technical support area of NetComm to see if they can provide any insight about the issue.
I've made some further programmatic suggestions to Arch Linux that will work-around the problem. If anyone is interested, these can be viewed here: https://bugs.archlinux.org/task/23293. Perhaps NetworkManager might also like to implement one of my suggestions somehow. I suppose the last one (specifying pre- and post- commands) could be hidden away in a configuration file somewhere.
I think the correct approach would be to work around the problem in DHCP clients. Unless there's a specific solution to the problem that wouldn't affect the DHCP exchange otherwise, I don't think anybody is going to fix this. Please reopen if a supported DHCP client (dhclient, dhcpcd) has a solution but it's somehow blocked by NetworkManager.
I know that a workaround for this problem was implemented in 'dhcpcd' a while ago. I repeatedly asked the 'dhclient' developers to do the same but they didn't respond. For what it's worth, I agree with your decision not to modify NetworkManager in this case.
(In reply to comment #7) > I know that a workaround for this problem was implemented in 'dhcpcd' a while > ago. Is that of any help at least to users of NetworkManager used with dhcpcd? > I repeatedly asked the 'dhclient' developers to do the same but they > didn't respond. The 'dhclient' fedora package has a load of patches that have been used for a long time in no way controversial. The upstream is not responsive even in that case. > For what it's worth, I agree with your decision not to modify > NetworkManager in this case. A patch from an interested person with non-invasive way to mitigate the problem would be a good reason to reopen (or maybe better to post in a new bug report).
Yes, the 'dhcpcd' workaround prevents the problem from affecting NetworkManager users. Hence, I'd be putting more pressure on the 'dhclient' developers instead of encouraging the formulation of a patch for NetworkManager.
Thanks!