After resuming from suspend, a previously connected wifi won't come up again. This is due to /etc/wpa_supplicant/wpa_cli.sh calling 'net.wlan0 --quiet start' although it is already running. Changing the command to pass 'restart' parameter instead, it succeeds and the wireless connection is usable again afterwards. Initially I thought the DISCONNECT event would get lost, but I was wrong - instead I had to discover that the call to 'net.wlan0 --quiet stop' which is supposed to follow that event has deliberately been disabled (by prefixing it with 'false', so it will fail without doing anything). The reason for that is given in a comment, stating 'stop' would set the interface down (which then would allow no CONNECT event anymore). Though this assumption is wrong, probably due to env var 'IN_BACKGROUND' being set by wpa_cli.sh prior to calling the network start script. Having that set and calling 'net.wlan0 stop' will leave wlan0 interface up. Long story short: please reenable stopping the interface upon DISCONNECT event so I don't have to restart wireless manually after each resume from sleep. Thanks, Phil
Created attachment 529064 [details, diff] Call "restart" instead of just "start" on CONNECTED Sorry for necro-posting, but since this bugreport is exactly what I am here for, i found it redundant to open a new bug for this. The problem described by Phil is still present as of net-wireless/wpa_supplicant-2.6-r6. It can even be described more widely: Suppose you have multiple lines in your /etc/conf.d/net: config_homenet="192.168.0.21/24" config_eduroam="dhcp" If I am at home, I want a static IP. Now I suspend or hibernate my laptop and go to the university. There I resume my laptop. wpa_cli.sh calls "net.wlan0 start", but since this service is already started, it is basically a no-op. Since my previous configuration is still active, net.wlan0 now tries to set a static IP, while I am connected with eduroam. Most likely, this will fail. I will have to manually restart the service to get a working connection. If however wpa_cli.sh would call "net.wlan0 restart" instead, the configuration file would be read in again and the service will start with the desired options. Another example without suspending my laptop: Suppose "homenet" is my mobile access point I carry around. If I arrive at my university, I switch off the AP, while my laptop is still on and connected. wpa_supplicant will recognize the vanishing "homenet", do a quick scan, and will connect me with "eduroam". But again, the configuration will never be re-read since the service never stopped. I will get the same problem as described above. Like above, wpa_cli.sh should call "restart" here to account for the changed network. The fix will be an additional two characters in wpa_cli.sh ("re") and I do not see any drawbacks that I am aware of. The other point Phil mentioned, regarding the DISCONNECTED hook: I do not have it enabled and it works quite fine this way. I do not see a reason to re-enable it for this specific issue. But maybe someone with more insight on the decision to disable it in the first place can enlighten us.
+1 This bug causes per-SSID variables in /etc/conf.d/net to be ignored, as Florian noticed. However, I think that the correct way to fix this bug is to reenable the DISCONNECT event (maybe with "--nodeps" flag; this is the configuration I am currently using) - there is no reason for network configuration daemons, like dhcpcd, to be running if there is no network. Also, this was the state of affairs util bug 373921 came and commented this handler out. That bug is now solved in the proper way, since /lib/netifrc/net/wpa_supplicant.sh explicitly avoids stopping wpa_supplicant in its "post_stop" hook when called with IN_BACKGROUND env variable set (which /etc/wpa_supplicant/wpa_cli.sh sets).
(In reply to Maciej S. Szmigiero from comment #2) > However, I think that the correct way to fix this bug is to reenable the > DISCONNECT event (maybe with "--nodeps" flag; this is the configuration I am > currently using) - there is no reason for network configuration daemons, like > dhcpcd, to be running if there is no network. BTW, both sys-apps/ifplugd and sys-apps/netplug Ethernet cable detection daemons call "start" / "stop" on their network interface init script upon the relevant cable in / out event, so there is no reason why the wireless equivalent of a network cable being connected or disconnected (AP association / disassociation) should do something different. The relevant scripts are here: https://gitweb.gentoo.org/repo/gentoo.git/tree/sys-apps/netplug/files/netplug-2 https://gitweb.gentoo.org/repo/gentoo.git/tree/sys-apps/ifplugd/files/ifplugd.action
