From: Michal Kazior <michal@plume.com>
Date: Fri, 12 Feb 2021 13:27:53 +0000 (+0000)
Subject: DPP2: Defer chirp scan if other scan is queued up
X-Git-Tag: hostap_2_10~587
X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=581df2d5243817c5d21547e80bdf9e54505bdf33;p=thirdparty%2Fhostap.git

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 <michal@plume.com>
---

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;