Fix race condition with PNO stop followed immediately by PNO start
authorHu Wang <huw@qti.qualcomm.com>
Wed, 6 Apr 2016 08:14:34 +0000 (11:14 +0300)
committerJouni Malinen <j@w1.fi>
Wed, 6 Apr 2016 08:14:34 +0000 (11:14 +0300)
commit3560b32ca34f0ac20e4883cd2a0ad21a20502dfc
tree31dd007a61b8533b44997de1a72b0dabde2f5305
parent85c0f01dd85768236afe56ad600d2221a7efd063
Fix race condition with PNO stop followed immediately by PNO start

Commit dd271857a5b501cd88143efe8ca0f0dce4519a91 ('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>
wpa_supplicant/events.c