[PATCH] Fix scanning state when sched_scan is stopped explicitly

[Dmitry Shmidt]

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 - code in scan function will postpone scan for 1 sec:
        if (wpa_s->scanning) {
                /*
                 * If we are already in scanning state, we shall reschedule the
                 * the incoming scan request.
                 */
                wpa_dbg(wpa_s, MSG_DEBUG, "Already scanning -
Reschedule the incoming scan req");
                wpa_supplicant_req_scan(wpa_s, 1, 0);
                return;
        }

So unless you see some problem with this patch, I would recommend to take it
to avoid 1 sec delay after PNO termination.

>
>> > I would assume there was a reason for postponing, but then again, I now
>> > remember that there were open questions on a related area.. I think
>> > there was a request to revert commit
>> > cf70d2981df1be7005fb90c2532e737ab39bc119 and handle some of the changes
>> > in mac80211 to make operations synchronous. I guess we should get open
>> > item resolved as well.. I'm not completely sure whether these two
>> > changes have any dependencies to each other, though.
>>
>> I think Raja's change is related to "coordination" between sched scan
>> by wpa_supplicant
>> and explicit one.
>
> This revert request has not gone anywhere either.. Would someone still
> remember what the issue here is and whether there is still need to
> either revert that commit cf70d2981df1be7005fb90c2532e737ab39bc119
> ('wpa_supplicant: Schedule PNO on completion of ongoing sched_scan') or
> fix something in it?
>
> It would be nice to see a debug log showing the issue since I don't have
> very convenient test setup for sched_scan.
>
> --
> Jouni Malinen                                            PGP id EFC895FA
> _______________________________________________
> HostAP mailing list
> HostAP at lists.shmoo.com
> http://lists.shmoo.com/mailman/listinfo/hostap