Use of wpa_cli, for example reassociate or select_network n, cause the network interface to go gown. After search, I've found that /etc/wpa_supplicant/wpa_cli.sh execute /etc/init.d/net.interface stop when wpa_cli receives DISCONNECT and that's what is happen when you do a new association. Reproducible: Always Steps to Reproduce: 1. Install and configure wpa_supplicant 2. ping a machine 3. do a wpa_cli reassociate 4. try to ping a machine
I confirm this. And what is more, wpa_supplicant is stopped when client is deassociated from AP due to any reason (for example, due to temporary signal loss). Because wpa_supplicant is stopped on the interface, no more associations with any AP will occur, and interface will stay "down" untill it is brought up manually. The root of this problem is in script /lib/rc/net/wpa_supplicant.sh from sys-apps/openrc, not in wpa_supplicant (somebody, please change summary and assignee) Perhaps more correct behavior is not to stop wpa_supplicant and wpa_cli on the interface if "stop" operation is caused by wpa_supplicant (i. e., when IN_BACKGROUND is set). In this case, "wpa_cli reassociate" (and signal loss, i believe) won't cause stopping wpa_supplicant, and interface will be automatically brought up when wpa_supplicant will be able to associate with AP again. Here is the patch which realizes this idea: --- wpa_supplicant.sh.orig 2009-12-21 18:30:17.000000000 +0300 +++ wpa_supplicant.sh 2010-03-11 12:44:54.000000000 +0300 @@ -183,9 +183,11 @@ fi if yesno "${IN_BACKGROUND}"; then - # Only stop wpa_supplicant if it's not the controlling daemon - ! service_started_daemon "${RC_SVCNAME}" "${wpas}" 1 + # Don't stop wpa_supplicant & wpa_cli if in background + return 0 fi + # Only stop wpa_supplicant if it's not the controlling daemon + ! service_started_daemon "${RC_SVCNAME}" "${wpas}" 1 [ $? != 0 ] && return 0 local pidfile="/var/run/wpa_cli-${IFACE}.pid"
If you can still duplicate this with openrc-0.6.1-r1 feel free to reopen. I am reassigning then resolving test request.
Please post back with your results.
openrc-0.6.1-r1, nothing has changed. If I do 'wpa_cli reassociate', interface goes down and doesn't go up. Temporary deassociation from AP (initiated by AP) has the same effect - interface goes down without further attempts to associate. (please, reopen the bug - I don't have sufficient permissions for it)
As per comment #2, reopening.
(In reply to comment #1) > I confirm this. And what is more, wpa_supplicant is stopped when client is > deassociated from AP due to any reason (for example, due to temporary signal > loss). Because wpa_supplicant is stopped on the interface, no more associations > with any AP will occur, and interface will stay "down" untill it is brought up > manually. > The root of this problem is in script /lib/rc/net/wpa_supplicant.sh from > sys-apps/openrc, not in wpa_supplicant (somebody, please change summary and > assignee) > Perhaps more correct behavior is not to stop wpa_supplicant and wpa_cli on the > interface if "stop" operation is caused by wpa_supplicant (i. e., when > IN_BACKGROUND is set). In this case, "wpa_cli reassociate" (and signal loss, i > believe) won't cause stopping wpa_supplicant, and interface will be > automatically brought up when wpa_supplicant will be able to associate with AP > again. > Here is the patch which realizes this idea: This patch has been applied to the git overlay and will be included in the next release. Thanks much. William
I am re-opening this bug. The fix we used caused bug #334663, so I am reverting it.
I checked this without using the net.* scripts, and it appears to be an issue within wpa_supplicant itself. Here is my procedure. 1) make sure that no net.* scripts for wireless interfaces are in the runlevels. 2) make sure that the networks are configured in /etc/wpa_supplicant/wpa_supplicant.conf 3) stop all wireless interfaces that you have started with net.* scripts. 4) start the wpa_supplicant daemon directly: rc-service wpa_supplicant start 5) start the dhcpcd daemon: rc-service dhcpcd start In this setup, wpa_supplicant and dhcpcd have control of the interfaces themselves, and you should use wpa_cli to control wpa_supplicant. 6) ping a machine to show that you have a network connection. 7) issue the reassociate command: wpa_cli reassociate wlan0 8) ping a machine to show that the interface is down. The only way to get the interface back at this point is to restart wpa_supplicant. On the other hand, if you replace the command in step 7 with the following: wpa_cli disconnect wlan0 wpa_cli reconnect wlan0 the interface will come back.
Does this work with the latest 0.7.x version in the tree?
(In reply to comment #9) > Does this work with the latest 0.7.x version in the tree? I ran both my test and the original reporter's test using wpa_supplicant-0.7.2-r3 and openrc-0.6.3, and the issue appears to be resolved. If everyone is ok with doing so, we can close this bug.
(In reply to comment #10) > I ran both my test and the original reporter's test using > wpa_supplicant-0.7.2-r3 and openrc-0.6.3, and the issue appears to be > resolved. > > If everyone is ok with doing so, we can close this bug. > Seems like it might be about time to mark 0.7.x of hostapd and wpa_supplicant stable, since there are more and more problems with 0.6 that won't be resolved upstream. (Anyway, the next release in the 0.7 will be called stable by upstream)
I'm closing this bug, since 0.7.3 has hit the tree. 0.7.3 is the first stable version from upstream, so untill it is marked stable (within a month if all goes well), people will have to use the unstable keyword.
This problem is still present even with latest versions of wpa_supplicant-0.7.3-r1 and openrc-0.6.8. Steps to reproduce: /etc/init.d/net.wlan0 restart (wlan0 is now up) wpa_cli -i wlan0 reassociate (several seconds later interface goes down, wpa_supplicant and wpa_cli are stopped). It is not so important bug of itself (since you rarely need to reassociate manually), but the same thing happens when you temporary lose wifi signal (or AP forces reassociation for some reason). It is much more important, since in this case wifi connection goes down and will not get up until you perform "net.wlan0 restart" manually. It is openrc problem, NOT wpa_supplicant one. Please reopen the bug.
(In reply to comment #13) > This problem is still present even with latest versions of > wpa_supplicant-0.7.3-r1 and openrc-0.6.8. Steps to reproduce: > /etc/init.d/net.wlan0 restart > (wlan0 is now up) > wpa_cli -i wlan0 reassociate > (several seconds later interface goes down, wpa_supplicant and wpa_cli are > stopped). On my system, this does not happen. If I run this sequence the interface comes back up and everything works. Mobile herd, do you have any ideas? Thanks, William
(In reply to comment #14) > On my system, this does not happen. If I run this sequence the interface comes > back up and everything works. > > Mobile herd, do you have any ideas? How did you configured network? I have the following lines in /etc/conf.d/net: modules=("wpa_supplicant") wpa_supplicant_wlan0="-Dwext" Perhaps you didn't configure wpa_supplicant in /etc/conf.d/net and run in as separate daemon? In this case, as far as I understand, you won't be affected by this bug, because wpa_supplicant won't be stopped when interface goes down.
I just ran the test again with the following setup: /etc/conf.d/net: modules=("wpa_supplicant") wpa_supplicant_wlan0="-Dwext" net.wlan0 is in the default runlevel and wpa_supplicant is not in any runlevel. I rebooted then as root did: rc-service net.wlan0 restart wpa_cli -i wlan0 reassociate The interface disconnected and reconnected successfully. My original /etc/conf.d/net was blank, but with the same setup for net.wlan0 and wpa_supplicant. I'm not sure what else to try for this. Thanks, William
