On Thu, Oct 27, 2016 at 03:18:28PM +0300, Andrei Otcheretianski wrote: > In case that stop sched command is sent after the completion of > scheduled scan and before the processing of the > EVENT_SCHED_SCAN_STOPPED event, stopping the scheduled scan would > fail, in such a case do not set the sched_scan_stop_req flag. So this patch is for wpas_stop_pno().. What about wpa_supplicant_cancel_sched_scan() which is also calling wpa_supplicant_stop_sched_scan() and setting wpa_s->sched_scan_stop_req = 1 regardless of what wpa_supplicant_stop_sched_scan() returns? > diff --git a/wpa_supplicant/scan.c b/wpa_supplicant/scan.c > @@ -2550,7 +2550,14 @@ int wpas_stop_pno(struct wpa_supplicant *wpa_s) > return 0; > > ret = wpa_supplicant_stop_sched_scan(wpa_s); > - wpa_s->sched_scan_stop_req = 1; > + > + /* In case that stop sched command is sent after the completion of > + * sched scan and before processing the EVENT_SCHED_SCAN_STOPPED event, > + * stopping the scheduled scan would fail. > + * In such a case do not set the flag > + */ > + if (!ret) > + wpa_s->sched_scan_stop_req = 1; > > wpa_s->pno = 0; So this is already protected with !wpa_s->pno above this context. I'm not sure I fully understood the sequence in which this could be hit. Would you happen to have a debug log showing a case where this change is needed here? -- Jouni Malinen PGP id EFC895FA _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
