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>
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;