jeltz/hostap
1
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

DPP2: Defer chirp scan if other scan is queued up

Browse source 
The chirp scan could override the scan_res_handler. This could lead to
wpa_supplicant getting stuck in a scanning state while not scanning at
all until forced to, e.g., via an explicit SCAN control command.

The condition for trigerring this problem in my testing was when
(interface_count % 3) == 2. This introduced a two second delay before
actual scan was triggered after starting the wpa_supplicant instance up.
If DPP chirping was requested fast enough, in between the queueing and
triggering, it would punt the scan request, never to be resumed again.
Chirp scan handler wouldn't resume it leaving wpa_supplicant
inadvertently idle.

Signed-off-by: Michal Kazior <michal@plume.com>
This commit is contained in:
Michal Kazior 2021-02-12 13:27:53 +00:00 committed by Jouni Malinen
parent 1e537a2756
commit 581df2d524
1 changed files with 11 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

11
wpa_supplicant/dpp_supplicant.c
View file

@ -3628,6 +3628,17 @@ static void wpas_dpp_chirp_next(void *eloop_ctx, void *timeout_ctx)
if (wpa_s->dpp_chirp_freq == 0) { if (wpa_s->dpp_chirp_freq == 0) {
if (wpa_s->dpp_chirp_round % 4 == 0 && if (wpa_s->dpp_chirp_round % 4 == 0 &&
!wpa_s->dpp_chirp_scan_done) { !wpa_s->dpp_chirp_scan_done) {
if (wpas_scan_scheduled(wpa_s)) {
wpa_printf(MSG_DEBUG,
"DPP: Deferring chirp scan because another scan is planned already");
if (eloop_register_timeout(1, 0,
wpas_dpp_chirp_next,
wpa_s, NULL) < 0) {
wpas_dpp_chirp_stop(wpa_s);
return;
}
return;
}
wpa_printf(MSG_DEBUG, wpa_printf(MSG_DEBUG,
"DPP: Update channel list for chirping"); "DPP: Update channel list for chirping");
wpa_s->scan_req = MANUAL_SCAN_REQ; wpa_s->scan_req = MANUAL_SCAN_REQ;