FS#23293 - [netcfg] Please terminate 'dhcpcd' using the correct '-k' option

Attached to Project: Arch Linux
Opened by Xavion (Xavion) - Wednesday, 16 March 2011, 03:26 GMT
Last edited by Rémy Oudompheng (remyoudompheng) - Friday, 08 July 2011, 05:25 GMT
Task Type Bug Report
Category Arch Projects
Status Closed
Assigned To Thomas Bächler (brain0)
Andrea Scarpino (BaSh)
Rémy Oudompheng (remyoudompheng)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

This bug report is intended for the maintainer of the 'netcfg' package. It is not a duplicate of " FS#23282 ", since the problem exists in both packages. I just posted the following to the 'NetworkManager' bug databases, as it suffers from the same problem.

-----

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.
This task depends upon

Closed by  Rémy Oudompheng (remyoudompheng)
Friday, 08 July 2011, 05:25 GMT
Reason for closing:  Implemented
Comment by Xavion (Xavion) - Wednesday, 16 March 2011, 10:20 GMT
I've taken another look at the problem tonight. As far as 'netcfg' is concerned, you simply need to change "dhcpcd -qx "$INTERFACE" &>/dev/null" to "dhcpcd -qk "$INTERFACE" &>/dev/null" in "/usr/lib/network/connections/ethernet".

This works for Ethernet and wireless, provided that users call 'netcfg' directly or use "net-auto-wired". If they use "net-auto-wireless" instead, 'dhcpcd' is killed without the '-k' option. This is probably because "/usr/lib/network/connections/ethernet" isn't used.
Comment by Andrea Scarpino (BaSh) - Wednesday, 16 March 2011, 18:04 GMT Comment by Xavion (Xavion) - Thursday, 17 March 2011, 06:02 GMT
Thanks for committing the first modification to your repository. I've just finished looking into the remaining "net-auto-wireless" case. The problem is that it's not calling "dhcpcd -qk "$INTERFACE" &>/dev/null" at all.

Rather than doing so directly, it's probably better to use your framework. You can add something like "/usr/bin/netcfg iface-down "$interface"" directly above "stop_wpa $2" in "/usr/bin/netcfg-wpa_actiond". Doing this ensures that the stale ".lease" file is removed when the "net-auto-wireless" daemon is stopped.

You guys might have a better idea, since you know your code better than I do. Since it's a significant addition, you might wanna check that everything works as expected at your end before committing this change to the repository.
Comment by Xavion (Xavion) - Thursday, 17 March 2011, 07:27 GMT
I just noticed a couple of other things that are relevant. You should probably also change "report_debug ethernet_down dhcpcd -qx "$INTERFACE"" to "report_debug ethernet_down dhcpcd -qk "$INTERFACE"" in "/usr/lib/network/connections/ethernet".

I see that your "ethernet_up()" function in "/usr/lib/network/connections/ethernet" contains support for 'dhclient', but your "ethernet_down()" function in the same file does not.

This means that instances of 'dhclient' remain running after disconnecting and their stale leases aren't removed either. I might see if I can figure out a solution to this problem relatively soon.
Comment by Xavion (Xavion) - Thursday, 17 March 2011, 09:01 GMT
Okay, I've worked out how to get 'dhclient' removing stale lease files. However, there doesn't seem to be a way to make it quit afterwards, so I've added a 'kill' line to the code for tidiness.

You can probably just replace the "ethernet_down()" function of your "/usr/lib/network/connections/ethernet" file with what I've included in the attachment. It works fine here, but you should probably test it at your end too.

BTW, I just opened " FS#23308 ", since 'dhclient' can't create the lease files at all right now. You might wonder why I'm complaining, since it fixes my problem. It's the horribly dodgy nature of such an accidental workaround that I couldn't condone :-).
Comment by Xavion (Xavion) - Friday, 18 March 2011, 03:09 GMT
I realised that there's an alternative solution to this problem, which has both a bonus and a drawback. The bonus is that it won't negatively affect routers that can handle unrecognised lease files properly. The drawback is that it requires manual configuration by users with dodgy routers and an entry must be added to the 'Troubleshooting' section of the 'netcfg' wiki article.

This new wiki section would advise users with routers like mine to add either of the following lines to a "/etc/network.d/interfaces/eth0" file:
PRE_DOWN="dhcpcd -qk eth0 &>/dev/null || true"
PRE_DOWN="dhclient -q -r eth0 &>/dev/null || true"

Two of the lines in my above attachment of the new "ethernet_down()" function could then be softened to retain lease files as follows:
dhcpcd -qx "$INTERFACE" &>/dev/null
dhclient -q -x "$INTERFACE" &>/dev/null

This compromised method might be better, assuming that users with dodgy routers are wise enough to read the wiki article. I dunno if that'll be the case, given that I lived with this problem for months before finally deciding to do something about it.
Comment by Xavion (Xavion) - Saturday, 19 March 2011, 08:08 GMT
It looks like you guys are waiting for some patches :-). For this reason, I've attached them to this comment. These modifications adopt the most recent approach that I suggested, which I think is the fairest solution for all involved. After committing these changes to your repository, you may close this bug report when ready.
Comment by Xavion (Xavion) - Saturday, 04 June 2011, 04:24 GMT
  • Field changed: Percent Complete (100% → 0%)
I noticed that you didn't just apply my "netcfg-wpa_actiond.patch" file directly. The way you've got it, "netcfg -i $interface" is called outside of the 'stop' section. From memory, it only worked when I placed it between "[[ -f "$IFACE_DIR/$interface" ]] && source "$IFACE_DIR/$interface"" and "stop_wpa $2".

Another point to note is that I recently convinced the 'dhcpcd' author to fix the problem that my "ethernet.patch" file works around at his end. I then submitted the same request to the authors of 'dhclient'. They initially acknowledged the problem, but I haven't heard anything back from them since.
Comment by Rémy Oudompheng (remyoudompheng) - Sunday, 19 June 2011, 17:31 GMT
Patch has been applied.
Comment by Xavion (Xavion) - Tuesday, 21 June 2011, 08:22 GMT
  • Field changed: Percent Complete (100% → 0%)
Sorry mate, you guys botched it up again. You didn't apply my "ethernet.patch" file properly. You haven't included any of the new 'dhclient' code that I wrote. As it stands, you're killing 'dhcpcd' but not 'dhclient'. It's inconsistent to stop one and leave the other running.
Comment by Rémy Oudompheng (remyoudompheng) - Friday, 08 July 2011, 05:25 GMT
Should be ok now.

Loading...