| Message ID | 1411204531-29849-1-git-send-email-robert.chiras@intel.com |
|---|---|
| State | Superseded |
| Headers | show |
On Sat, Sep 20, 2014 at 12:15:31PM +0300, Robert Chiras wrote: > If we are already connected to an AP and we initiate a WPS connection, > wpa_supplicant will first disconnect from the current AP then initiate a > scan request. The driver, will send us a disconnect event with > ReasonCode 3 (WLAN_REASON_DEAUTH_LEAVING), confirming the disconnection > from te current AP. > If this happens during a WPS connection, when scan results receive, this > disconnect will cause the process to stop. > So, if a disconnect event is received while scanning for WPS connection, > ignore this event and continue with WPS connection. > diff --git a/wpa_supplicant/events.c b/wpa_supplicant/events.c > @@ -1356,8 +1356,16 @@ static int _wpa_supplicant_event_scan_results(struct wpa_supplicant *wpa_s, > if (wpa_s->disconnected) { > - wpa_supplicant_set_state(wpa_s, WPA_DISCONNECTED); > - goto scan_work_done; > + if (wpas_wps_searching(wpa_s)) { > + /* Received a disconnect while scanning for WPS; ignore it > + * and continue with WPS process. > + * */ > + wpa_s->disconnected = 0; > + wpa_s->reassociate = 1; This does not look correct.. Having wpa_s->disconnected getting set to 1 during WPS operation is the issue that would need to be resolved, not this type of change to hide that case. That said, I'm not sure I understand how this can happen.. 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? 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.
diff --git a/wpa_supplicant/events.c b/wpa_supplicant/events.c index ba9e083..634e4c6 100644 --- a/wpa_supplicant/events.c +++ b/wpa_supplicant/events.c @@ -1356,8 +1356,16 @@ static int _wpa_supplicant_event_scan_results(struct wpa_supplicant *wpa_s, goto scan_work_done; if (wpa_s->disconnected) { - wpa_supplicant_set_state(wpa_s, WPA_DISCONNECTED); - goto scan_work_done; + if (wpas_wps_searching(wpa_s)) { + /* Received a disconnect while scanning for WPS; ignore it + * and continue with WPS process. + * */ + wpa_s->disconnected = 0; + wpa_s->reassociate = 1; + } else { + wpa_supplicant_set_state(wpa_s, WPA_DISCONNECTED); + goto scan_work_done; + } } if (!wpas_driver_bss_selection(wpa_s) &&
If we are already connected to an AP and we initiate a WPS connection, wpa_supplicant will first disconnect from the current AP then initiate a scan request. The driver, will send us a disconnect event with ReasonCode 3 (WLAN_REASON_DEAUTH_LEAVING), confirming the disconnection from te current AP. If this happens during a WPS connection, when scan results receive, this disconnect will cause the process to stop. So, if a disconnect event is received while scanning for WPS connection, ignore this event and continue with WPS connection. Change-Id: I9332959a25012426cbb8c5ee035b04269c81b6ed Signed-off-by: Robert Chiras <robert.chiras@intel.com> --- wpa_supplicant/events.c | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-)