diff mbox

wpa_supplicant: cancel sched scan on all interfaces

Message ID 1383484921-2653-1-git-send-email-ilan.peer@intel.com
State Changes Requested
Headers show

Commit Message

Peer, Ilan Nov. 3, 2013, 1:22 p.m. UTC
From: David Spinadel <david.spinadel@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.

Signed-hostap: David Spinadel <david.spinadel@intel.com>

---
 wpa_supplicant/scan.c |   29 ++++++++++++++++++++++++++++-
 1 file changed, 28 insertions(+), 1 deletion(-)

Comments

Jouni Malinen Nov. 5, 2013, 8:33 a.m. UTC | #1
On Sun, Nov 03, 2013 at 03:22:01PM +0200, Ilan Peer wrote:
> From: David Spinadel <david.spinadel@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?
Arend van Spriel Nov. 5, 2013, 9:37 a.m. UTC | #2
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@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?

"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.

Regards,
Arend
--8<------------------------------------------------------------------
  * @NL80211_CMD_START_SCHED_SCAN: start a scheduled scan at certain
  *	intervals, as specified by %NL80211_ATTR_SCHED_SCAN_INTERVAL.
  *	Like with normal scans, if SSIDs (%NL80211_ATTR_SCAN_SSIDS)
  *	are passed, they are used in the probe requests.  For
  *	broadcast, a broadcast SSID must be passed (ie. an empty
  *	string).  If no SSID is passed, no probe requests are sent and
  *	a passive scan is performed.  %NL80211_ATTR_SCAN_FREQUENCIES,
  *	if passed, define which channels should be scanned; if not
  *	passed, all channels allowed for the current regulatory domain
  *	are used.  Extra IEs can also be passed from the userspace by
  *	using the %NL80211_ATTR_IE attribute.
  * @NL80211_CMD_STOP_SCHED_SCAN: stop a scheduled scan.  Returns -ENOENT
  *	if scheduled scan is not running.
  * @NL80211_CMD_SCHED_SCAN_RESULTS: indicates that there are scheduled scan
  *	results available.
  * @NL80211_CMD_SCHED_SCAN_STOPPED: indicates that the scheduled scan has
  *	stopped.  The driver may issue this event at any time during a
  *	scheduled scan.  One reason for stopping the scan is if the hardware
  *	does not support starting an association or a normal scan while running
  *	a scheduled scan.  This event is also sent when the
  *	%NL80211_CMD_STOP_SCHED_SCAN command is received or when the interface
  *	is brought down while a scheduled scan was running.
Peer, Ilan Nov. 5, 2013, 11:24 a.m. UTC | #3
> -----Original Message-----
> From: hostap-bounces@lists.shmoo.com [mailto:hostap-
> bounces@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@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@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.
diff mbox

Patch

diff --git a/wpa_supplicant/scan.c b/wpa_supplicant/scan.c
index cfac768..0549656 100644
--- a/wpa_supplicant/scan.c
+++ b/wpa_supplicant/scan.c
@@ -1230,16 +1230,43 @@  void wpa_supplicant_cancel_delayed_sched_scan(struct wpa_supplicant *wpa_s)
  * wpa_supplicant_cancel_sched_scan - Stop running scheduled scans
  * @wpa_s: Pointer to wpa_supplicant data
  *
- * This function is used to stop a periodic scheduled scan.
+ * This function is used to stop a periodic scheduled scan on all interfaces
+ * that share the same radio.
  */
 void wpa_supplicant_cancel_sched_scan(struct wpa_supplicant *wpa_s)
 {
+	struct wpa_supplicant *iface;
+	const char *rn, *rn2;
+
 	if (!wpa_s->sched_scanning)
 		return;
 
 	wpa_dbg(wpa_s, MSG_DEBUG, "Cancelling sched scan");
 	eloop_cancel_timeout(wpa_supplicant_sched_scan_timeout, wpa_s, NULL);
 	wpa_supplicant_stop_sched_scan(wpa_s);
+
+	/* Cancel scheduled scan on other interfaces */
+	if (!wpa_s->driver->get_radio_name)
+		return;
+
+	rn = wpa_s->driver->get_radio_name(wpa_s->drv_priv);
+
+	if (!rn || rn[0] == '\0')
+		return;
+
+	for (iface = wpa_s->global->ifaces; iface; iface = iface->next) {
+		if (iface == wpa_s || !iface->driver->get_radio_name)
+			continue;
+
+		rn2 = iface->driver->get_radio_name(iface->drv_priv);
+		if (!rn2 || os_strcmp(rn, rn2) != 0)
+			continue;
+
+		eloop_cancel_timeout(wpa_supplicant_sched_scan_timeout, iface,
+				     NULL);
+		wpa_supplicant_stop_sched_scan(iface);
+	}
+
 }