FS#26402 - [netcfg] 2.6.8-1 writes a runfile when it shouldn't

Attached to Project: Arch Linux
Opened by Jaroslav Stepanek (jarda-wien) - Tuesday, 11 October 2011, 20:09 GMT
Last edited by Eric Belanger (Snowman) - Tuesday, 30 April 2013, 01:08 GMT
Task Type Bug Report
Category Arch Projects
Status Closed
Assigned To Jouke Witteveen (jouke)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

Description:
There is a problem with starting a new wireless profile after the computer has been hibernated with another profile active (this is a typical laptop usage scenario -> hibernate at school connected to the school network and wake up somewhere else trying to connect to another network).

When the users starts the new profile too fast, so that some part is not yet working, netcfg says the profile couldn't be connected because wpa_supplicant didn't start possibly due to a configuration error.

At this stage the old network profile is not connected anymore and the new profile could not be activated. netcfg leaves a file in /run/network/profiles/newprofilename, which would indicate an active profile.

"netcfg current" says newprofile is active. (because it merely does a ls on /run/network/profiles/)
"netcfg -d newprofile" says profile is not connected.
"netcfg newprofile" says profile is already connected.

Solution:
netcfg should not write a file to /run/network/profiles/, unless the profile really is connected. netcfg should not say a profile is connected when it is not and vice versa.


Additional info:
netcfg 2.6.8-1
wpa_supplicant 0.7.3-3
pm-utils 1.4.1-3


Steps to reproduce:
It is quite tricky to reproduce because you have to be outside of range of profile <A> when the computer wakes up - otherwise netcfg will just connect to <A> automatically.
1. Go to hibernation with profile <A> connected.
2. Wake up from hibernation and try to connect to profile <B> right after the start.
3. wpa_supplicant will not start because of a possible config error.
4. netcfg current will say profile B is connected, though it isn't.
5. netcfg -d B says profile not connected. netcfg B says profile is already connected.
6. rm /run/network/profiles/B and netcfg B should work....
This task depends upon

Closed by  Eric Belanger (Snowman)
Tuesday, 30 April 2013, 01:08 GMT
Reason for closing:  Won't fix
Additional comments about closing:  netcfg has been moved to AUR
Comment by Alfredo Palhares (masterkorp) - Tuesday, 07 February 2012, 21:35 GMT
I am treating this bug on my github fork https://github.com/masterkorp/netcfg/issues/1
Comment by Leonid Isaev (lisaev) - Monday, 20 February 2012, 23:27 GMT
Why can't you just put a hook into /etc/pm/sleep.d which disconnect the current profile?
Comment by Jouke Witteveen (jouke) - Monday, 15 October 2012, 08:52 GMT
Is this bug still present in current versions of netcfg?
Comment by Kenneth Henderick (ibex) - Monday, 18 March 2013, 17:15 GMT
This is still present in netcfg v3.0

Loading...