| Message ID | 1438728155-26987-1-git-send-email-pasi.sjoholm@jolla.com |
|---|---|
| State | Superseded |
| Headers | show |
On Wed, Aug 05, 2015 at 01:42:35AM +0300, pasi.sjoholm@jolla.com wrote: > Commit 2d9c99e37b29a639dafa431df38e1586a31ba887 introduced > a regression while running in ap_mode together with ap_scan > configured with value of 2. > > Retrying caused following path to be called: > wpa_supplicant_req_scan()->wpa_supplicant_scan()-> > wpa_supplicant_assoc_try()->wpa_supplicant_associate()-> > wpa_supplicant_create_ap() > > Which eventually teared down the currently configured > ap_mode by calling wpa_supplicant_ap_deinit(). Would you be able to provide a debug log showing the sequence in which this is hit? > @@ -186,6 +186,9 @@ static void wpas_trigger_scan_cb(struct wpa_radio_work *work, int deinit) > if (wpa_s->disconnected) > retry = 0; > > + if (wpa_s->last_ssid && wpa_s->last_ssid->mode == WPAS_MODE_AP) > + retry = 0; This would imply that we are currently running an AP mode interface and something start a scan. What was that something? And what happened next? I'm trying to understand especially that wpa_supplicant_assoc_try() call in the sequence. Why would that be called here when AP mode was already running?
On 08.08.2015 23:17, Jouni Malinen wrote: > On Wed, Aug 05, 2015 at 01:42:35AM +0300, pasi.sjoholm@jolla.com > wrote: >> Commit 2d9c99e37b29a639dafa431df38e1586a31ba887 introduced a >> regression while running in ap_mode together with ap_scan >> configured with value of 2. >> >> Retrying caused following path to be called: >> wpa_supplicant_req_scan()->wpa_supplicant_scan()-> >> wpa_supplicant_assoc_try()->wpa_supplicant_associate()-> >> wpa_supplicant_create_ap() >> >> Which eventually teared down the currently configured ap_mode by >> calling wpa_supplicant_ap_deinit(). > Would you be able to provide a debug log showing the sequence in > which this is hit? Yes, I can provide it. Will try to send it later today. >> @@ -186,6 +186,9 @@ static void wpas_trigger_scan_cb(struct >> wpa_radio_work *work, int deinit) if (wpa_s->disconnected) retry >> = 0; >> >> + if (wpa_s->last_ssid && wpa_s->last_ssid->mode == >> WPAS_MODE_AP) + retry = 0; > This would imply that we are currently running an AP mode interface > and something start a scan. What was that something? And what > happened next? I'm trying to understand especially that > wpa_supplicant_assoc_try() call in the sequence. Why would that be > called here when AP mode was already running? This is happening due external process requesting for a scan over dbus which then triggers wpa_supplicant_trigger_scan(). Eg. Let's have mobile device running in AP mode and user starting an application which wants show/use the device location by using available wlan networks as one the of inputs in addition to cellular network cells. Anyway, the device wlan chip does not support scanning (errno: operation not supported) while it's running in AP mode and therefore wpa_supplicant retries the scanning after initial scan failed. Eventually in wpa_supplicant_scan() there's a code section: --cut-- if (wpa_s->last_scan_req != MANUAL_SCAN_REQ && wpa_s->conf->ap_scan == 2) { wpa_s->connect_without_scan = NULL; wpa_s->prev_scan_wildcard = 0; wpa_supplicant_assoc_try(wpa_s, ssid); return; --cut-- The last_scan_req in this case is INITIAL_SCAN_REQ as no scans have been made after AP mode has been setup, and then we have set ap_scan with the value of 2. Br, Pasi
diff --git a/wpa_supplicant/scan.c b/wpa_supplicant/scan.c index 8d0d1a5..cb42456 100644 --- a/wpa_supplicant/scan.c +++ b/wpa_supplicant/scan.c @@ -186,6 +186,9 @@ static void wpas_trigger_scan_cb(struct wpa_radio_work *work, int deinit) if (wpa_s->disconnected) retry = 0; + if (wpa_s->last_ssid && wpa_s->last_ssid->mode == WPAS_MODE_AP) + retry = 0; + wpa_supplicant_notify_scanning(wpa_s, 0); wpas_notify_scan_done(wpa_s, 0); if (wpa_s->wpa_state == WPA_SCANNING)