Fix race condition with PNO stop followed immediately by PNO start

Commit dd271857a5 ('Skip normal scan when
PNO is already in progress') fixed issues with normal scans getting
rejected by the driver when PNO scan is already running. The part about
skipping such a scan request is fine, but the part about clearing
wpa_s->pno back to 0 in EVENT_SCHED_SCAN_STOPPED handler is problematic.

If PNO is stopped ("SET pno 0") and then restarted ("SET pno 1")
immediately, it is possible for the EVENT_SCHED_SCAN_STOPPED event from
the stopping part to be received only after the new PNO instance has
been started. This would have resulted in clearing wpa_s->pno and the
driver and wpa_supplicant getting out of sync. This would then prevent
PNO from being stopped with "SET pno 0" (that fails if wpa_s->pno == 0).

Fix this race condition by reverting the wpa_s->pno = 0 addition from
the EVENT_SCHED_SCAN_STOPPED handler.

Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
This commit is contained in:
Hu Wang 2016-04-06 11:14:34 +03:00 committed by Jouni Malinen
parent 85c0f01dd8
commit 3560b32ca3

View file

@ -3959,7 +3959,6 @@ void wpa_supplicant_event(void *ctx, enum wpa_event_type event,
data->driver_gtk_rekey.replay_ctr);
break;
case EVENT_SCHED_SCAN_STOPPED:
wpa_s->pno = 0;
wpa_s->sched_scanning = 0;
resched = wpa_s->scanning && wpas_scan_scheduled(wpa_s);
wpa_supplicant_notify_scanning(wpa_s, 0);