Bugzilla – Bug 937
No disassociation when wpa_supplicant is stopped
Last modified: 2006-12-21 21:29:11
You need to log in before you can comment on or make changes to this bug.
I noticed that when I terminate wpa_supplicant, the ipw2200 driver stays in the "associated" state but of course no traffic can be sent or received anymore. I don't think this behaviour is correct, since it won't try to reassociate to an open network if one is available.
Created an attachment (id=703) [details] dissassociate and sw_reset when wpa_supplicant is terminated The provided patch corrects this by explicitely disassociating and triggering a sw_reset. Now when wpa_supplicant is terminated, the driver automatically disassociate and reassociate to any available open network.
Which wpa_supplicant version do you use? From bug #671, it should already be fixed in new wpa_supplicant (for example 0.4.8)
(In reply to comment #2) > Which wpa_supplicant version do you use? From bug #671, it should already be > fixed in new wpa_supplicant (for example 0.4.8) I was sure I had version 0.5.2, but after checking I still use version 0.4.7 (the last one in debian testing). I am very sorry for filing dumb bug reports ;)
according to Comment #3, remark it.
After I terminate wpa_supplicant I can't see that Disassociate frame is sent towards an AP, this happens while using both ipw2200 and ipw3945 (latest releases). I use wpa_supplicant 0.5.5 (latest) Linux 2.6.17-2-686 compiled with WEXT v20 ipw3945 driver version 1.1.3 1. organise a connection by means of wpa_supplicant (I use WPA2/TLS) wpa_supplicant -i <ifname> -D wext -c <cfg_file> Note that I use wext here (generic interface) 2. Ctrl^C or when I run supplicant in the background "terminate" in wpa_cli 3. I can see that a client is disconnected (I guess that was the original problem reported), but on AP I still an active client, which means my active time is still calculated on AP and that will be taken into account when RADIUS Accounting Stop is sent due to idle timeout event. So the problem is that not disassociate nor deauthenticate 802.11 frame is sent by a client. ====================== When I use the same wpa_supplicant 0.5.5 with Atheros card as: wpa_supplicant -D madwifi ... There is no such a problem, I can see disassociate frame coming out od a client and everything is ok, because AP immediatelly forgets about the client. ===================== I'm not sure but it seems to me there were no such a problem when I used ipw2200 + wpa_supplicant specifying -D ipw (ipw driver-specific interface), but now when ipw tends to support WEXT interface I've got such a problem. Can you please verify if this is a problem of WEXT support for "ipw" drivers family? Thanks.
I've checked the following configuration: Linux 2.6.18 wpa_supplicant 0.5.5 ipw2200: Intel(R) PRO/Wireless 2200/2915 Network Driver, 1.1.2k WEXT v20 And I can see that it WORKS fine - it sends Disassociate frame from a station. I've got stuck with it, really strange, maybe this is a problem of Linux kernel? Note that I used both ipw2200 and ipw3945 drivers and they do not send Disassociate frame when my configuration is: Linux 2.6.17-2-686 compiled with WEXT v20 ipw3945 driver version 1.1.3 (ipw2200 is 1.1.0)
(In reply to comment #6) > I've checked the following configuration: > > Linux 2.6.18 > wpa_supplicant 0.5.5 > ipw2200: Intel(R) PRO/Wireless 2200/2915 Network Driver, 1.1.2k > WEXT v20 > > And I can see that it WORKS fine - it sends Disassociate frame from a station. So the problem is fixed in the new version, right?