From 581df2d5243817c5d21547e80bdf9e54505bdf33 Mon Sep 17 00:00:00 2001 From: Michal Kazior Date: Fri, 12 Feb 2021 13:27:53 +0000 Subject: [PATCH] DPP2: Defer chirp scan if other scan is queued up 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 --- wpa_supplicant/dpp_supplicant.c | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/wpa_supplicant/dpp_supplicant.c b/wpa_supplicant/dpp_supplicant.c index 6a08ff866..b2443ae37 100644 --- a/wpa_supplicant/dpp_supplicant.c +++ b/wpa_supplicant/dpp_supplicant.c @@ -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_round % 4 == 0 && !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, "DPP: Update channel list for chirping"); wpa_s->scan_req = MANUAL_SCAN_REQ;