[PATCH] Do not retry scan after failure if operating in ap_mode

[Jouni Malinen]

On Mon, Aug 10, 2015 at 02:53:10PM +0300, Pasi Sj?holm wrote:
> This is happening due external process requesting for a scan over dbus
> which then triggers wpa_supplicant_trigger_scan().

Ah.. I was trying to reproduce using the control interface SCAN command
instead of D-Bus Scan() and that did not work.. Even with D-Bus, one
needs to pick the specific case that calls wpa_supplicant_trigger_scan()
directly. And this shows where one of the issues is.. That (or well,
those) code paths did not set MANUAL_SCAN_REQ anywhere.

The following changes should fix this:

diff --git a/wpa_supplicant/dbus/dbus_new_handlers.c b/wpa_supplicant/dbus/dbus_new_handlers.c
index 1c04e92..67562a5 100644
--- a/wpa_supplicant/dbus/dbus_new_handlers.c
+++ b/wpa_supplicant/dbus/dbus_new_handlers.c
@@ -1341,6 +1341,7 @@ DBusMessage * wpas_dbus_handler_scan(DBusMessage *message,
 			}
 
 			if (params.freqs && params.freqs[0]) {
+				wpa_s->last_scan_req = MANUAL_SCAN_REQ;
 				if (wpa_supplicant_trigger_scan(wpa_s,
 								&params)) {
 					reply = wpas_dbus_error_scan_error(
@@ -1367,6 +1368,7 @@ DBusMessage * wpas_dbus_handler_scan(DBusMessage *message,
 			wpa_supplicant_cancel_sched_scan(wpa_s);
 		}
 
+		wpa_s->last_scan_req = MANUAL_SCAN_REQ;
 		if (wpa_supplicant_trigger_scan(wpa_s, &params)) {
 			reply = wpas_dbus_error_scan_error(
 				message, "Scan request rejected");

> 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.

This should have been called with wpa_s->last_scan_req ==
MANUAL_SCAN_REQ in the case you described..

I don't think the retry case in wpas_trigger_scan_cb() is an issue and
looking at wpa_s->last_ssid looks quite odd when the goal is to check
whether there is currently an AP mode operation in progress. While this
is not strictly speaking needed with the change I mentioned above, the
AP mode case can be handled with following should there be another path
that can hit here with wpa_s->last_scan_req != MANUAL_SCAN_REQ:

diff --git a/wpa_supplicant/scan.c b/wpa_supplicant/scan.c
index 8d0d1a5..d7049a1 100644
--- a/wpa_supplicant/scan.c
+++ b/wpa_supplicant/scan.c
@@ -808,6 +808,9 @@ static void wpa_supplicant_scan(void *eloop_ctx, void *timeout_ctx)
 	}
 
 	if (wpa_s->last_scan_req != MANUAL_SCAN_REQ &&
+#ifdef CONFIG_AP
+	    !wpa_s->ap_iface &&
+#endif /* CONFIG_AP */
 	    wpa_s->conf->ap_scan == 2) {
 		wpa_s->connect_without_scan = NULL;
 		wpa_s->prev_scan_wildcard = 0;

-- 
Jouni Malinen                                            PGP id EFC895FA