[PATCH] Handle disconnect event while scanning for WPS

[Chiras, Robert]

Hi Jouni,

In the meantime, I found why the driver was sending that DISCONNECT event.
In kernel 3.10, when wpa_supplicant was sending  a disconnect or deauth to nl80211, after disconnecting the AP in driver, cfg80211 SME was responsible to send back a DISCONNECT event to wpa_supplicant. But, that event didn't have the NL80211_ATTR_DISCONNECTED_BY_AP set (which means that it was a locally generated DISCONNECT event).
Starting with kernel 3.14, the driver needs to report the disconnect through cfg80211 SME event handling. But, by doing this, there is no way to tell that this is a locally generated disconnect, and cfg80211 SME automatically assumes that this DISCONNECT event comes from AP (see cfg80211_process_wdev_events from net/wireless/util.c, where it uses a hardcoded "true" for the from_ap parameter when calls __cfg80211_disconnected). This will cause nl80211 to generate a DISCONNECTED event with the NL80211_ATTR_DISCONNECTED_BY_AP attribute set.

And, this is why, when wpa_supplicant receives this disconnect event will set the disconnected to 1.
We will continue investigate this issue in kernel too, but I think that your patch in wpa_supplicant is a good practice, avoiding driver issues like the one explained above.

Best regards,
Robert

-----Original Message-----
From: hostap-bounces at lists.shmoo.com [mailto:hostap-bounces at lists.shmoo.com] On Behalf Of Jouni Malinen
Sent: Saturday, September 27, 2014 10:41 PM
To: hostap at lists.shmoo.com
Subject: Re: [PATCH] Handle disconnect event while scanning for WPS

On Sat, Sep 27, 2014 at 10:33:30PM +0300, Jouni Malinen wrote:
> Would you be able to share a debug log showing a case where this is 
> triggered? I'd assume this is with "STA_AUTOCONNECT 0" since that 
> would be needed to get wpa_s->disconnected set to 1 on deauthentication event.
> However, when I tested trying to force that, I saw wpa_s->disconnected 
> getting cleared immediately in wpas_wps_reassoc() and the following 
> disconnection event getting ignored, so wpa_s->disconnected did not 
> get set to 1 again.
> 
> Do you have commit d6a36f3956cc49c77376eceaef2e14548ca0bf30
> ('nl80211: Mask out deauth even after own deauth request') included in 
> the version that you are testing with?

If I break that mechanism and disable autoconnect, I can reproduce the issue. I'm not sure how exactly this would happen with that deauth event ignoring case in place. Or well, maybe there is a driver that ends up generating multiple disconnection events that somehow is able to bypass that.

> The autoconnect disabled case is already trying to skip the part of 
> setting wpa_s->disconnected through "wpa_s->key_mgmt == 
> WPA_KEY_MGMT_WPS", but maybe that has been broken by some of the newer 
> changes. As such, more appropriate fix would likely be to add this
> wpas_wps_searching(wpa_s) as a condition there in
> wpa_supplicant_event_disassoc_finish() for setting disconnected=1 
> rather than in this scan event handling case.

It looks like this is safe to do, so I'm planning on applying following instead of the proposed change in scan result event processing.


diff --git a/wpa_supplicant/events.c b/wpa_supplicant/events.c
--- a/wpa_supplicant/events.c
+++ b/wpa_supplicant/events.c
@@ -2159,10 +2159,12 @@ static void wpa_supplicant_event_disassoc_finish(struct wpa_supplicant *wpa_s,
 	}
 	if (!wpa_s->disconnected &&
 	    (!wpa_s->auto_reconnect_disabled ||
-	     wpa_s->key_mgmt == WPA_KEY_MGMT_WPS)) {
+	     wpa_s->key_mgmt == WPA_KEY_MGMT_WPS ||
+	     wpas_wps_searching(wpa_s))) {
 		wpa_dbg(wpa_s, MSG_DEBUG, "Auto connect enabled: try to "
-			"reconnect (wps=%d wpa_state=%d)",
+			"reconnect (wps=%d/%d wpa_state=%d)",
 			wpa_s->key_mgmt == WPA_KEY_MGMT_WPS,
+			wpas_wps_searching(wpa_s),
 			wpa_s->wpa_state);
 		if (wpa_s->wpa_state == WPA_COMPLETED &&
 		    wpa_s->current_ssid &&
 
-- 
Jouni Malinen                                            PGP id EFC895FA
_______________________________________________
HostAP mailing list
HostAP at lists.shmoo.com
http://lists.shmoo.com/mailman/listinfo/hostap