From: Michal Kazior <michal@xxxxxxxxx>
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, eg. via
explicit SCAN control command.
The condition for trigerring this problem in my
testing was when (interface_count % 3) == 2.
This introduced 2s delay before actual scan was
triggered after starting wpa_s 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_s
inadvertently idle.
Signed-off-by: Michal Kazior <michal@xxxxxxxxx>
---
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 910602e34..a34a4ea80 100644
--- a/wpa_supplicant/dpp_supplicant.c
+++ b/wpa_supplicant/dpp_supplicant.c
@@ -3608,6 +3608,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 alredy",
+ wpa_s->dpp_chirp_freq);
+ 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;
--
2.27.0
_______________________________________________
Hostap mailing list
Hostap@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/hostap
