Scan request looks ignored when wpa_state is in scanning state with dbus interface

[Jouni Malinen]

On Thu, Feb 25, 2016 at 12:23:57PM -0600, Dan Williams wrote:
> 2) a supplicant SCHED_SCAN never completes.  There is only one enabled
> network, and this is the first sched_scan, and apparently those are
> never timed out.  Since the AP is turned off, no scan results for that
> AP will ever be delivered.

What do you mean with SCHED_SCAN completing? This is supposed to offload
scanning (search of a matching network) to the driver/firmware and
report results if such a network is found. If no such network is ever
found, this is not supposed to "complete".

> Jouni, this seems like a supplicant bug?  The code is pretty clear, the
> following block never gets run because ssid==NULL (because there's only
> one enabled network/SSID and max_sched_scan_ssids >= 1) and this is the
> first sched_scan:
> 
> 	/* If we have more SSIDs to scan, add a timeout so we scan them too */
> 	if (ssid || !wpa_s->first_sched_scan) {
> 		wpa_s->sched_scan_timed_out = 0;
> 		eloop_register_timeout(wpa_s->sched_scan_timeout, 0,
> 				       wpa_supplicant_sched_scan_timeout,
> 				       wpa_s, NULL);
> 		wpa_s->first_sched_scan = 0;
> 		wpa_s->sched_scan_timeout /= 2;
> 		wpa_s->sched_scan_interval *= 2;
> 		if (wpa_s->sched_scan_timeout < wpa_s->sched_scan_interval) {
> 			wpa_s->sched_scan_interval = 10;
> 			wpa_s->sched_scan_timeout = max_sched_scan_ssids * 2;
> 		}
> 	}
> 
> It seems like all scans should have a timeout.

Why? This timeout is used to rotate through all the configured SSIDs if
a single sched_scan operation cannot be used for them all. If a single
sched_scan can handle this, it is supposed to run indefinitely until
stopped.

-- 
Jouni Malinen                                            PGP id EFC895FA