[PATCH] Fix scanning state when sched_scan is stopped explicitly

[Dmitry Shmidt]

On Mon, Mar 9, 2015 at 12:43 PM, Johannes Berg
<johannes at sipsolutions.net> wrote:
> On Mon, 2015-03-09 at 11:29 -0700, Dmitry Shmidt wrote:
>> On Sat, Mar 7, 2015 at 11:46 AM, Jouni Malinen <j at w1.fi> wrote:
>> > On Fri, Apr 11, 2014 at 09:51:14AM -0700, Dmitry Shmidt wrote:
>> >> On Fri, Apr 11, 2014 at 9:09 AM, Jouni Malinen <j at w1.fi> wrote:
>> >> > On Wed, Apr 09, 2014 at 03:48:07PM -0700, Dmitry Shmidt wrote:
>> >> >> --- a/wpa_supplicant/scan.c
>> >> >> +++ b/wpa_supplicant/scan.c
>> >> >> @@ -261,6 +261,9 @@ int wpa_supplicant_stop_sched_scan(struct wpa_supplicant *wpa_s)
>> >> >>               wpa_dbg(wpa_s, MSG_DEBUG, "stopping sched_scan failed!");
>> >> >>               /* TODO: what to do if stopping fails? */
>> >> >>               return -1;
>> >> >> +     } else {
>> >> >> +             wpa_s->sched_scanning = 0;
>> >> >> +             wpa_supplicant_notify_scanning(wpa_s, 0);
>> >
>> > I have this in my pending queue, but I'm not completely sure what to do
>> > about this.
>> >
>> > Is there still a case where this would be needed? If so, I guess I can
>> > apply this since I have not really had a chance to do any real
>> > sched_scan testing myself and no one has come up with additional
>> > justification for delaying the notification until the driver has
>> > actually completed stopping of sched_scan.
>>
>> When wifi manager explicitly stops PNO (by set pno 0), wpa_supplicant sends
>> stop_pno command to the driver. Theoretically it is "sync" call and
>> PNO is stopped
>> immediately. However, it takes time for event to propagate back:
>>   nl80211_stop_sched_scan() -> __cfg80211_stop_sched_scan() ->
>>   nl80211_send_sched_scan(rdev, dev, NL80211_CMD_SCHED_SCAN_STOPPED);
>> so when wpa_supplciant gets NL80211_CMD_SCHED_SCAN_STOPPED
>> that will be translated to EVENT_SCHED_SCAN_STOPPED to clear
>>   wpa_s->scanning
>> it will be too late
>
> Which driver are you using? ISTR fixing a number of issues in this area.

We are using Broadcom and Qualcomm drivers. However, I am not sure that
driver is relevant here - all the calls I described above are done by kernel
wireless stack and wpa_supplicant.

>
> johannes
>