[PATCH] wpa_supplicant: cancel sched scan on all interfaces

[Peer, Ilan]

> -----Original Message-----
> From: hostap-bounces at lists.shmoo.com [mailto:hostap-
> bounces at lists.shmoo.com] On Behalf Of Arend van Spriel
> Sent: Tuesday, November 05, 2013 11:37
> To: Jouni Malinen; Spinadel, David
> Cc: Johannes Berg; hostap at lists.shmoo.com
> Subject: Re: [PATCH] wpa_supplicant: cancel sched scan on all interfaces
> 
> On 11/05/2013 09:33 AM, Jouni Malinen wrote:
> > On Sun, Nov 03, 2013 at 03:22:01PM +0200, Ilan Peer wrote:
> >> From: David Spinadel <david.spinadel at intel.com>
> >>
> >> Cancel sched scan on all interfaces (that share the same radio) to
> >> enable scanning on one interfaces when there is a scheduled scan on
> >> another interface.
> >
> > Could you please clarify why this is needed and why is
> > wpa_supplicant_cancel_sched_scan() the correct place to do this? Is
> > this to address constraints in a specific driver or is this type of
> > constraint on the sched_scan operation defined somewhere? Does
> > sched_scan even work properly if issued concurrently on multiple
> > interfaces sharing the same radio?
> 

Although this is a limitation of our driver, we made this change to align with flows in the wpa_supplicant that stop scheduled scan before starting a regular scan such a control interface scan, p2p_find() etc. In these cases, we understood that it is not desired to have scheduled scan running while running the other scan operation, and since cancelling the scheduled scan only on the current interface is not sufficient, we made the change to cancel it on all other interfaces as well. 

In addition, since cfg80211 enforces only a single active scheduled scan, a flow such as pno_start() needs to cancel the scheduled scan on all interfaces, otherwise cfg80211 might fail the scheduled scan request on the current interface.

> "Our" scheduled scan can only be started when there is no normal scan
> active (regardless the interface). Once it is started a normal scan can be
> issued concurrently. The scheduled scan API does not have much constraints
> although it does describe the scenario where scheduled scan is stopped due
> to a normal scan request. So leave it to the driver to decide (Pasted nl80211.h
> content for reference) instead of wpa_s.
> 

As Arend suggested, we can go with the approach that the driver is responsible for resolving the conflicts between concurrent scheduled scan and normal scan, but this will probably require changes in the drivers and removing the code in the wpa_supplicant that stop scheduled scan before starting a scan flow.

Another option is to have the driver publish capabilities and the wpa_supplicant to act according to the capabilities.

Regards,

Ilan.