RFC: mac80211/ath9k: allow scanning single channel if other VIF is associated.

RFC: mac80211/ath9k: allow scanning single channel if other VIF is associated.

[Ben Greear]

[-- Attachment #1: Type: text/plain, Size: 495 bytes --]

This patch aims to decrease channel switching when there is at least one
interface associated.  This should help multiple station interfaces co-exist
on the same hardware, especially in WPA mode.

This patch is on top of the other 3 I posted recently, and even though I think
this patch is going in the right direction, I still cannot get two WPA interfaces
to complete authentication.

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


[-- Attachment #2: scan_one.patch --]
[-- Type: text/plain, Size: 9600 bytes --]

diff --git a/drivers/net/wireless/ath/ath9k/main.c b/drivers/net/wireless/ath/ath9k/main.c
index 1165f90..13673bb 100644
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -1605,7 +1605,12 @@ static int ath9k_config(struct ieee80211_hw *hw, u32 changed)
 		struct ieee80211_channel *curchan = hw->conf.channel;
 		int pos = curchan->hw_value;
 
+		/* If channels are the same, then don't actually do anything.
+		 */
+		if (sc->sc_ah->curchan == &sc->sc_ah->channels[pos])
+			goto skip_chan_change;
+		
 		aphy->chan_idx = pos;
 		aphy->chan_is_ht = conf_is_ht(conf);
 		if (hw->conf.flags & IEEE80211_CONF_OFFCHANNEL)
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index 4e635e2..631b094 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -790,6 +790,8 @@ struct ieee80211_local {
 	enum ieee80211_band hw_scan_band;
 	int scan_channel_idx;
 	int scan_ies_len;
+	int scanned_count; /* how many channels scanned so far in this scan */
+	bool scan_probe_once; /* if true, scan only the current channel. */
 
 	unsigned long leave_oper_channel_time;
 	enum mac80211_scan_state next_scan_state;
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 0cb822c..abb76ae 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -1845,10 +1845,11 @@ void ieee80211_sta_work(struct ieee80211_sub_if_data *sdata)
 
 		else if (ifmgd->probe_send_count < IEEE80211_MAX_PROBE_TRIES) {
 #ifdef CONFIG_MAC80211_VERBOSE_DEBUG
-			printk(KERN_DEBUG "No probe response from AP %pM"
-				" after %dms, try %d\n", bssid,
+			printk(KERN_DEBUG "%s: No probe response from AP %pM"
+				" after %dms, try %d  flags: 0x%x\n",
+				sdata->dev->name, bssid,
 				(1000 * IEEE80211_PROBE_WAIT)/HZ,
-				ifmgd->probe_send_count);
+				ifmgd->probe_send_count, ifmgd->flags);
 #endif
 			ieee80211_mgd_probe_ap_send(sdata);
 		} else {
@@ -1858,9 +1859,10 @@ void ieee80211_sta_work(struct ieee80211_sub_if_data *sdata)
 			 */
 			ifmgd->flags &= ~(IEEE80211_STA_CONNECTION_POLL |
 					  IEEE80211_STA_BEACON_POLL);
-			printk(KERN_DEBUG "No probe response from AP %pM"
-				" after %dms, disconnecting.\n",
-				bssid, (1000 * IEEE80211_PROBE_WAIT)/HZ);
+			printk(KERN_DEBUG "%s: No probe response from AP %pM"
+			       " after %dms, disconnecting, flags: 0x%x\n",
+			       sdata->dev->name, bssid,
+			       (1000 * IEEE80211_PROBE_WAIT)/HZ, ifmgd->flags);
 			ieee80211_set_disassoc(sdata, true);
 			mutex_unlock(&ifmgd->mtx);
 			mutex_lock(&local->mtx);
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index ac205a3..e8ea84d 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -2399,7 +2399,7 @@ static void ieee80211_rx_handlers(struct ieee80211_rx_data *rx,
 	do {				\
 		res = rxh(rx);		\
 		if (res != RX_CONTINUE)	\
-			goto rxh_next;  \
+			goto rxh_next;	\
 	} while (0);
 
 	while ((skb = __skb_dequeue(frames))) {
diff --git a/net/mac80211/scan.c b/net/mac80211/scan.c
index e20fb52..1c9f0a8 100644
--- a/net/mac80211/scan.c
+++ b/net/mac80211/scan.c
@@ -292,7 +292,9 @@ static void __ieee80211_scan_completed(struct ieee80211_hw *hw, bool aborted)
 	/* we only have to protect scan_req and hw/sw scan */
 	mutex_unlock(&local->mtx);
 
-	ieee80211_hw_config(local, IEEE80211_CONF_CHANGE_CHANNEL);
+	if (!local->scan_probe_once)
+		ieee80211_hw_config(local, IEEE80211_CONF_CHANGE_CHANNEL);
+
 	if (was_hw_scan)
 		goto done;
 
@@ -300,7 +302,8 @@ static void __ieee80211_scan_completed(struct ieee80211_hw *hw, bool aborted)
 
 	drv_sw_scan_complete(local);
 
-	ieee80211_offchannel_return(local, true);
+	if (!local->scan_probe_once)
+		ieee80211_offchannel_return(local, true);
 
  done:
 	mutex_lock(&local->mtx);
@@ -340,13 +343,43 @@ static int ieee80211_start_sw_scan(struct ieee80211_local *local)
 	 * nullfunc frames and probe requests will be dropped in
 	 * ieee80211_tx_h_check_assoc().
 	 */
-	drv_sw_scan_start(local);
+	int avifs = 0;
+	int svifs = 0;
+	struct ieee80211_sub_if_data *sdata;
+
+	mutex_lock(&local->iflist_mtx);
+	list_for_each_entry(sdata, &local->interfaces, list) {
+		if (!ieee80211_sdata_running(sdata))
+			continue;
 
-	ieee80211_offchannel_stop_beaconing(local);
+		if (sdata->vif.type != NL80211_IFTYPE_STATION
+		    || sdata->u.mgd.associated)
+			avifs++;
 
-	local->leave_oper_channel_time = 0;
+		if (sdata->vif.type == NL80211_IFTYPE_STATION)
+			svifs++;
+	}
+	mutex_unlock(&local->iflist_mtx);
+
+	/* If one sta is associated, we don't want another to start scanning,
+	 * as that will un-associate the first.
+	 * TODO:  This still leaves a race when a thundering herd of WPA
+	 * supplicants are all coming up at once.
+	 */
+	if ((avifs > 1) || ((avifs == 1) && (svifs > 1)))
+		local->scan_probe_once = true;
+	else
+		local->scan_probe_once = false;
+
+	drv_sw_scan_start(local);
+
+	if (!local->scan_probe_once) {
+		ieee80211_offchannel_stop_beaconing(local);
+		local->leave_oper_channel_time = 0;
+		local->scan_channel_idx = 0;
+	}
+	local->scanned_count = 0;
 	local->next_scan_state = SCAN_DECISION;
-	local->scan_channel_idx = 0;
 
 	drv_flush(local, false);
 
@@ -459,7 +492,8 @@ static int ieee80211_scan_state_decision(struct ieee80211_local *local,
 	struct ieee80211_channel *next_chan;
 
 	/* if no more bands/channels left, complete scan and advance to the idle state */
-	if (local->scan_channel_idx >= local->scan_req->n_channels) {
+	if ((local->scan_channel_idx >= local->scan_req->n_channels) ||
+	    (local->scanned_count && local->scan_probe_once)) {
 		__ieee80211_scan_completed(&local->hw, false);
 		return 1;
 	}
@@ -528,10 +562,13 @@ static int ieee80211_scan_state_decision(struct ieee80211_local *local,
 			local->next_scan_state = SCAN_SET_CHANNEL;
 	} else {
 		/*
-		 * we're on the operating channel currently, let's
-		 * leave that channel now to scan another one
+		 * we're on the operating channel currently, Leave that
+		 * channel if we are not probing the single channel.
 		 */
-		local->next_scan_state = SCAN_LEAVE_OPER_CHANNEL;
+		if (local->scan_probe_once)
+			local->next_scan_state = SCAN_SET_CHANNEL;
+		else
+			local->next_scan_state = SCAN_LEAVE_OPER_CHANNEL;
 	}
 
 	*next_delay = 0;
@@ -566,14 +603,15 @@ static void ieee80211_scan_state_enter_oper_channel(struct ieee80211_local *loca
 {
 	/* switch back to the operating channel */
 	local->scan_channel = NULL;
-	ieee80211_hw_config(local, IEEE80211_CONF_CHANGE_CHANNEL);
-
-	/*
-	 * Only re-enable station mode interface now; beaconing will be
-	 * re-enabled once the full scan has been completed.
-	 */
-	ieee80211_offchannel_return(local, false);
+	if (!local->scan_probe_once) {
+		ieee80211_hw_config(local, IEEE80211_CONF_CHANGE_CHANNEL);
 
+		/*
+		 * Only re-enable station mode interface now; beaconing will be
+		 * re-enabled once the full scan has been completed.
+		 */
+		ieee80211_offchannel_return(local, false);
+	}
 	__clear_bit(SCAN_OFF_CHANNEL, &local->scanning);
 
 	*next_delay = HZ / 5;
@@ -587,19 +625,25 @@ static void ieee80211_scan_state_set_channel(struct ieee80211_local *local,
 	struct ieee80211_channel *chan;
 
 	skip = 0;
-	chan = local->scan_req->channels[local->scan_channel_idx];
+	if (local->scan_probe_once) {
+		chan = local->oper_channel;
+		local->scan_channel = chan;
+	} else {
+		chan = local->scan_req->channels[local->scan_channel_idx];
+		local->scan_channel = chan;
 
-	local->scan_channel = chan;
-	if (ieee80211_hw_config(local, IEEE80211_CONF_CHANGE_CHANNEL))
-		skip = 1;
+		if (ieee80211_hw_config(local, IEEE80211_CONF_CHANGE_CHANNEL))
+			skip = 1;
 
-	/* advance state machine to next channel/band */
-	local->scan_channel_idx++;
+		/* advance state machine to next channel/band */
+		local->scan_channel_idx++;
 
-	if (skip) {
-		/* if we skip this channel return to the decision state */
-		local->next_scan_state = SCAN_DECISION;
-		return;
+		if (skip) {
+			/* if we skip this channel return to the decision
+			 * state */
+			local->next_scan_state = SCAN_DECISION;
+			return;
+		}
 	}
 
 	/*
@@ -615,6 +659,7 @@ static void ieee80211_scan_state_set_channel(struct ieee80211_local *local,
 	if (chan->flags & IEEE80211_CHAN_PASSIVE_SCAN ||
 	    !local->scan_req->n_ssids) {
 		*next_delay = IEEE80211_PASSIVE_CHANNEL_TIME;
+		local->scanned_count++;
 		local->next_scan_state = SCAN_DECISION;
 		return;
 	}
@@ -637,6 +682,7 @@ static void ieee80211_scan_state_send_probe(struct ieee80211_local *local,
 			local->scan_req->ssids[i].ssid_len,
 			local->scan_req->ie, local->scan_req->ie_len);
 
+	local->scanned_count++;
 	/*
 	 * After sending probe requests, wait for probe responses
 	 * on the channel.
diff --git a/net/mac80211/work.c b/net/mac80211/work.c
index ae344d1..1bfc1e0 100644
--- a/net/mac80211/work.c
+++ b/net/mac80211/work.c
@@ -910,12 +910,17 @@ static void ieee80211_work_work(struct work_struct *work)
 			 *	 happen to be on the same channel as
 			 *	 the requested channel
 			 */
-			ieee80211_offchannel_stop_beaconing(local);
-			ieee80211_offchannel_stop_station(local);
-
-			local->tmp_channel = wk->chan;
-			local->tmp_channel_type = wk->chan_type;
-			ieee80211_hw_config(local, 0);
+			if (!(wk->chan == local->scan_channel ||
+			      (wk->chan == local->oper_channel &&
+			       !local->scan_channel))) {
+				/* Only change channels if we need to */
+				ieee80211_offchannel_stop_beaconing(local);
+				ieee80211_offchannel_stop_station(local);
+
+				local->tmp_channel = wk->chan;
+				local->tmp_channel_type = wk->chan_type;
+				ieee80211_hw_config(local, 0);
+			}
 			started = true;
 			wk->timeout = jiffies;
 		}

Re: RFC: mac80211/ath9k: allow scanning single channel if other VIF is associated.

[Jouni Malinen]

On Mon, Sep 13, 2010 at 04:14:05PM -0700, Ben Greear wrote:
> This patch aims to decrease channel switching when there is at least one
> interface associated.  This should help multiple station interfaces co-exist
> on the same hardware, especially in WPA mode.

If I understood the change correctly, it would prevent running full
scans when in associated state. That does not sound reasonable behavior
and scanning should not cause an association to be lost. Did I miss
something or what exactly is this trying to do?

If you want to limit scans a single channel in some special use cases,
you should be able to do that in user space, too, at least for the
initial scan before connection. As a future optimization, we should
somehow be able to merge scan requests from multiple VIFs into a single
one, i.e., share the results from a single scan to multiple VIFs..


PS.

It would be easier to comment on the changes if you were to inline them
instead of attaching the file..

-- 
Jouni Malinen                                            PGP id EFC895FA

Re: RFC: mac80211/ath9k: allow scanning single channel if other VIF is associated.

[Ben Greear]

On 09/14/2010 08:03 PM, Jouni Malinen wrote:
> On Mon, Sep 13, 2010 at 04:14:05PM -0700, Ben Greear wrote:
>> This patch aims to decrease channel switching when there is at least one
>> interface associated.  This should help multiple station interfaces co-exist
>> on the same hardware, especially in WPA mode.
>
> If I understood the change correctly, it would prevent running full
> scans when in associated state. That does not sound reasonable behavior
> and scanning should not cause an association to be lost. Did I miss
> something or what exactly is this trying to do?

That's pretty much what I'm trying to do.  We had similar code in
our 2.6.31 kernel with ath5k. Imagine getting 50 virtual stations
started with WPA and all of them trying to scan all channels at once!
Most got timeouts, and one scanning would disrupt traffic on the others.
And, the hardware can only associate on a single channel anyway, so getting
scan results for other channels doesn't do a great deal of good.

With current ath9k, I see DMA timeouts and other nasty things (without
that patch applied) when trying to bring up two VIFs with WPA.

I think for the multi-VIF scenario, it should scan the single associated
channel by default, but it would be nice to allow full scans on demand.
(I would very much like to work with standard wpa_supplicant, but if hacking it
is the only way, then I can attempt that.)

> If you want to limit scans a single channel in some special use cases,
> you should be able to do that in user space, too, at least for the
> initial scan before connection. As a future optimization, we should
> somehow be able to merge scan requests from multiple VIFs into a single
> one, i.e., share the results from a single scan to multiple VIFs..

Merging would be nice.  Maybe store the results in the global hardware/phy
structs and just return that to user-space so long as it's relatively fresh?

> It would be easier to comment on the changes if you were to inline them
> instead of attaching the file..

Sorry about that..I'll inline it next time.  It will probably be white-space
damaged, but I can re-send any official patches using git.

Thanks,
Ben


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: RFC: mac80211/ath9k: allow scanning single channel if other VIF is associated.

[Dan Williams]

On Tue, 2010-09-14 at 22:30 -0700, Ben Greear wrote:
> On 09/14/2010 08:03 PM, Jouni Malinen wrote:
> > On Mon, Sep 13, 2010 at 04:14:05PM -0700, Ben Greear wrote:
> >> This patch aims to decrease channel switching when there is at least one
> >> interface associated.  This should help multiple station interfaces co-exist
> >> on the same hardware, especially in WPA mode.
> >
> > If I understood the change correctly, it would prevent running full
> > scans when in associated state. That does not sound reasonable behavior
> > and scanning should not cause an association to be lost. Did I miss
> > something or what exactly is this trying to do?
> 
> That's pretty much what I'm trying to do.  We had similar code in
> our 2.6.31 kernel with ath5k. Imagine getting 50 virtual stations
> started with WPA and all of them trying to scan all channels at once!
> Most got timeouts, and one scanning would disrupt traffic on the others.
> And, the hardware can only associate on a single channel anyway, so getting
> scan results for other channels doesn't do a great deal of good.
> 
> With current ath9k, I see DMA timeouts and other nasty things (without
> that patch applied) when trying to bring up two VIFs with WPA.
> 
> I think for the multi-VIF scenario, it should scan the single associated
> channel by default, but it would be nice to allow full scans on demand.
> (I would very much like to work with standard wpa_supplicant, but if hacking it
> is the only way, then I can attempt that.)

Allowing full scans on demand (ie when userspace requests it) is a must.
Even in multi-VIF mode.

Dan

> > If you want to limit scans a single channel in some special use cases,
> > you should be able to do that in user space, too, at least for the
> > initial scan before connection. As a future optimization, we should
> > somehow be able to merge scan requests from multiple VIFs into a single
> > one, i.e., share the results from a single scan to multiple VIFs..
> 
> Merging would be nice.  Maybe store the results in the global hardware/phy
> structs and just return that to user-space so long as it's relatively fresh?
> 
> > It would be easier to comment on the changes if you were to inline them
> > instead of attaching the file..
> 
> Sorry about that..I'll inline it next time.  It will probably be white-space
> damaged, but I can re-send any official patches using git.
> 
> Thanks,
> Ben
> 
> 

Re: RFC: mac80211/ath9k: allow scanning single channel if other VIF is associated.

[Dan Williams]

On Wed, 2010-09-15 at 00:46 -0500, Dan Williams wrote:
> On Tue, 2010-09-14 at 22:30 -0700, Ben Greear wrote:
> > On 09/14/2010 08:03 PM, Jouni Malinen wrote:
> > > On Mon, Sep 13, 2010 at 04:14:05PM -0700, Ben Greear wrote:
> > >> This patch aims to decrease channel switching when there is at least one
> > >> interface associated.  This should help multiple station interfaces co-exist
> > >> on the same hardware, especially in WPA mode.
> > >
> > > If I understood the change correctly, it would prevent running full
> > > scans when in associated state. That does not sound reasonable behavior
> > > and scanning should not cause an association to be lost. Did I miss
> > > something or what exactly is this trying to do?
> > 
> > That's pretty much what I'm trying to do.  We had similar code in
> > our 2.6.31 kernel with ath5k. Imagine getting 50 virtual stations
> > started with WPA and all of them trying to scan all channels at once!
> > Most got timeouts, and one scanning would disrupt traffic on the others.
> > And, the hardware can only associate on a single channel anyway, so getting
> > scan results for other channels doesn't do a great deal of good.
> > 
> > With current ath9k, I see DMA timeouts and other nasty things (without
> > that patch applied) when trying to bring up two VIFs with WPA.
> > 
> > I think for the multi-VIF scenario, it should scan the single associated
> > channel by default, but it would be nice to allow full scans on demand.
> > (I would very much like to work with standard wpa_supplicant, but if hacking it
> > is the only way, then I can attempt that.)
> 
> Allowing full scans on demand (ie when userspace requests it) is a must.
> Even in multi-VIF mode.

Obviously I mean "when associated"...

> Dan
> 
> > > If you want to limit scans a single channel in some special use cases,
> > > you should be able to do that in user space, too, at least for the
> > > initial scan before connection. As a future optimization, we should
> > > somehow be able to merge scan requests from multiple VIFs into a single
> > > one, i.e., share the results from a single scan to multiple VIFs..
> > 
> > Merging would be nice.  Maybe store the results in the global hardware/phy
> > structs and just return that to user-space so long as it's relatively fresh?
> > 
> > > It would be easier to comment on the changes if you were to inline them
> > > instead of attaching the file..
> > 
> > Sorry about that..I'll inline it next time.  It will probably be white-space
> > damaged, but I can re-send any official patches using git.
> > 
> > Thanks,
> > Ben
> > 
> > 
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: RFC: mac80211/ath9k: allow scanning single channel if other VIF is associated.

[Ben Greear]

On 09/14/2010 10:46 PM, Dan Williams wrote:
> On Tue, 2010-09-14 at 22:30 -0700, Ben Greear wrote:
>> On 09/14/2010 08:03 PM, Jouni Malinen wrote:
>>> On Mon, Sep 13, 2010 at 04:14:05PM -0700, Ben Greear wrote:
>>>> This patch aims to decrease channel switching when there is at least one
>>>> interface associated.  This should help multiple station interfaces co-exist
>>>> on the same hardware, especially in WPA mode.
>>>
>>> If I understood the change correctly, it would prevent running full
>>> scans when in associated state. That does not sound reasonable behavior
>>> and scanning should not cause an association to be lost. Did I miss
>>> something or what exactly is this trying to do?
>>
>> That's pretty much what I'm trying to do.  We had similar code in
>> our 2.6.31 kernel with ath5k. Imagine getting 50 virtual stations
>> started with WPA and all of them trying to scan all channels at once!
>> Most got timeouts, and one scanning would disrupt traffic on the others.
>> And, the hardware can only associate on a single channel anyway, so getting
>> scan results for other channels doesn't do a great deal of good.
>>
>> With current ath9k, I see DMA timeouts and other nasty things (without
>> that patch applied) when trying to bring up two VIFs with WPA.
>>
>> I think for the multi-VIF scenario, it should scan the single associated
>> channel by default, but it would be nice to allow full scans on demand.
>> (I would very much like to work with standard wpa_supplicant, but if hacking it
>> is the only way, then I can attempt that.)
>
> Allowing full scans on demand (ie when userspace requests it) is a must.
> Even in multi-VIF mode.

So, something like 'iw sta1 scan all' to force scanning all,
with 'iw sta1 scan' just returning results for associated channel
in multi-vif scenario?

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: RFC: mac80211/ath9k: allow scanning single channel if other VIF is associated.

[Johannes Berg]

On Tue, 2010-09-14 at 22:30 -0700, Ben Greear wrote:

> > If I understood the change correctly, it would prevent running full
> > scans when in associated state. That does not sound reasonable behavior
> > and scanning should not cause an association to be lost. Did I miss
> > something or what exactly is this trying to do?
> 
> That's pretty much what I'm trying to do.  We had similar code in
> our 2.6.31 kernel with ath5k. Imagine getting 50 virtual stations
> started with WPA and all of them trying to scan all channels at once!

They can't ... cfg80211 limits it to one scan at a time per hardware ...

> I think for the multi-VIF scenario, it should scan the single associated
> channel by default, but it would be nice to allow full scans on demand.

Go change your userspace then to request only the single channel scan.

> (I would very much like to work with standard wpa_supplicant, but if hacking it
> is the only way, then I can attempt that.)

Yes, I don't see how we can reasonably work around this in the kernel.

> > If you want to limit scans a single channel in some special use cases,
> > you should be able to do that in user space, too, at least for the
> > initial scan before connection. As a future optimization, we should
> > somehow be able to merge scan requests from multiple VIFs into a single
> > one, i.e., share the results from a single scan to multiple VIFs..
> 
> Merging would be nice.  Maybe store the results in the global hardware/phy
> structs and just return that to user-space so long as it's relatively fresh?

That's what we do, unless userspace requests a new scan.

johannes

Re: RFC: mac80211/ath9k: allow scanning single channel if other VIF is associated.

[Ben Greear]

On 09/15/2010 03:16 AM, Johannes Berg wrote:
> On Tue, 2010-09-14 at 22:30 -0700, Ben Greear wrote:
>
>>> If I understood the change correctly, it would prevent running full
>>> scans when in associated state. That does not sound reasonable behavior
>>> and scanning should not cause an association to be lost. Did I miss
>>> something or what exactly is this trying to do?
>>
>> That's pretty much what I'm trying to do.  We had similar code in
>> our 2.6.31 kernel with ath5k. Imagine getting 50 virtual stations
>> started with WPA and all of them trying to scan all channels at once!
>
> They can't ... cfg80211 limits it to one scan at a time per hardware ...

Right, but as soon as one finished, the next would start, and at least in .31,
that caused the first to un-associate, giving never-ending loop of interfaces
scanning and trying to associate.

>> I think for the multi-VIF scenario, it should scan the single associated
>> channel by default, but it would be nice to allow full scans on demand.
>
> Go change your userspace then to request only the single channel scan.
>
>> (I would very much like to work with standard wpa_supplicant, but if hacking it
>> is the only way, then I can attempt that.)
>
> Yes, I don't see how we can reasonably work around this in the kernel.

Ok, I'll see if I can add a 'scan-one-if-associated' flag for wpa-supplicant to
use.

Thanks,
Ben


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: RFC: mac80211/ath9k: allow scanning single channel if other VIF is associated.

[Johannes Berg]

On Wed, 2010-09-15 at 07:21 -0700, Ben Greear wrote:

> Right, but as soon as one finished, the next would start, and at least in .31,
> that caused the first to un-associate, giving never-ending loop of interfaces
> scanning and trying to associate.

There should be a grace period maybe?

> Ok, I'll see if I can add a 'scan-one-if-associated' flag for wpa-supplicant to
> use.

Just make it give the channel instead of adding new API.

johannes

Re: RFC: mac80211/ath9k: allow scanning single channel if other VIF is associated.

[Ben Greear]

On 09/15/2010 07:24 AM, Johannes Berg wrote:
> On Wed, 2010-09-15 at 07:21 -0700, Ben Greear wrote:
>
>> Right, but as soon as one finished, the next would start, and at least in .31,
>> that caused the first to un-associate, giving never-ending loop of interfaces
>> scanning and trying to associate.
>
> There should be a grace period maybe?

I don't think that really fixes anything, except make the race between
full scan and attempting for the first interface to associate harder to
hit (and that is only useful if the scan-one logic is enabled anyway).

>> Ok, I'll see if I can add a 'scan-one-if-associated' flag for wpa-supplicant to
>> use.
>
> Just make it give the channel instead of adding new API.

I think you still need an 'any', because whoever wrote the wpa_supplicant config file doesn't
necessarily know what channel the AP is on.  The first interface to do a full scan
can figure that out and associate....

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: RFC: mac80211/ath9k: allow scanning single channel if other VIF is associated.

[Johannes Berg]

On Wed, 2010-09-15 at 08:32 -0700, Ben Greear wrote:

> >> Right, but as soon as one finished, the next would start, and at least in .31,
> >> that caused the first to un-associate, giving never-ending loop of interfaces
> >> scanning and trying to associate.
> >
> > There should be a grace period maybe?
> 
> I don't think that really fixes anything, except make the race between
> full scan and attempting for the first interface to associate harder to
> hit (and that is only useful if the scan-one logic is enabled anyway).

I think you just need to update ... newer kernels shouldn't be allowing
a scan while trying to associate, I think.

johannes

Re: RFC: mac80211/ath9k: allow scanning single channel if other VIF is associated.

[Ben Greear]

On 09/15/2010 08:37 AM, Johannes Berg wrote:
> On Wed, 2010-09-15 at 08:32 -0700, Ben Greear wrote:
>
>>>> Right, but as soon as one finished, the next would start, and at least in .31,
>>>> that caused the first to un-associate, giving never-ending loop of interfaces
>>>> scanning and trying to associate.
>>>
>>> There should be a grace period maybe?
>>
>> I don't think that really fixes anything, except make the race between
>> full scan and attempting for the first interface to associate harder to
>> hit (and that is only useful if the scan-one logic is enabled anyway).
>
> I think you just need to update ... newer kernels shouldn't be allowing
> a scan while trying to associate, I think.

Grab top-of-tree wireless-testing and apply my rxfilt patch to ath9k, and you can create two VIFS
and attempt to run wpa_supplicant against them (I use one supplicant per
interface.)

Unless it was fixed last night, I doubt you will have any luck.

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: RFC: mac80211/ath9k: allow scanning single channel if other VIF is associated.

[Jouni Malinen]

On Tue, Sep 14, 2010 at 10:30:04PM -0700, Ben Greear wrote:
> I think for the multi-VIF scenario, it should scan the single associated
> channel by default, but it would be nice to allow full scans on demand.
> (I would very much like to work with standard wpa_supplicant, but if hacking it
> is the only way, then I can attempt that.)

"Standard wpa_supplicant" needs to become more aware of multiple users
of the same radio, so it is certainly fine to add changes there. For
example, a mechanism for noticing that interfaces are sharing a radio
would be useful. With that, it should also be possible to share the BSS
table and scan results (and requests!) within wpa_supplicant.

Sure, mac80211 could potentially do some of merging and reusing, too,
but as far as wpa_supplicant use cases (including hostapd and AP mode in
Wi-Fi P2P like use cases here) are concerned, mac80211 changes may not
be needed for handling the scanning part.

-- 
Jouni Malinen                                            PGP id EFC895FA

Re: RFC: mac80211/ath9k: allow scanning single channel if other VIF is associated.

[Luis R. Rodriguez]

On Wed, Sep 15, 2010 at 1:31 PM, Jouni Malinen <j@w1.fi> wrote:
> On Tue, Sep 14, 2010 at 10:30:04PM -0700, Ben Greear wrote:
>> I think for the multi-VIF scenario, it should scan the single associated
>> channel by default, but it would be nice to allow full scans on demand.
>> (I would very much like to work with standard wpa_supplicant, but if hacking it
>> is the only way, then I can attempt that.)
>
> "Standard wpa_supplicant" needs to become more aware of multiple users
> of the same radio, so it is certainly fine to add changes there. For
> example, a mechanism for noticing that interfaces are sharing a radio
> would be useful. With that, it should also be possible to share the BSS
> table and scan results (and requests!) within wpa_supplicant.

Depending on how this is implementing, sharing of the physical radio
may require some kernel synchronization between the different
interfaces using the same radio. It may also be possible to share the
same radio between an 802.11 device and a wimax device, for example.
Long ago we thought up of a frequency broker [1] but never really
wrote it as we have had no usage case for it yet. If we implement the
frequency broker we could also technically add a scheduler to sharing
the same radio between separate interfaces / technologies, this could
just be done in userspace as well, although I am not sure if the
timing considerations for doing it in userspace would suffice.

[1] http://wireless.kernel.org/en/developers/FrequencyBroker

  Luis

> Sure, mac80211 could potentially do some of merging and reusing, too,
> but as far as wpa_supplicant use cases (including hostapd and AP mode in
> Wi-Fi P2P like use cases here) are concerned, mac80211 changes may not
> be needed for handling the scanning part.
>
> --
> Jouni Malinen                                            PGP id EFC895FA
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: RFC: mac80211/ath9k: allow scanning single channel if other VIF is associated.

[Ben Greear]

On 09/15/2010 02:04 PM, Luis R. Rodriguez wrote:
> On Wed, Sep 15, 2010 at 1:31 PM, Jouni Malinen<j@w1.fi>  wrote:
>> On Tue, Sep 14, 2010 at 10:30:04PM -0700, Ben Greear wrote:
>>> I think for the multi-VIF scenario, it should scan the single associated
>>> channel by default, but it would be nice to allow full scans on demand.
>>> (I would very much like to work with standard wpa_supplicant, but if hacking it
>>> is the only way, then I can attempt that.)
>>
>> "Standard wpa_supplicant" needs to become more aware of multiple users
>> of the same radio, so it is certainly fine to add changes there. For
>> example, a mechanism for noticing that interfaces are sharing a radio
>> would be useful. With that, it should also be possible to share the BSS
>> table and scan results (and requests!) within wpa_supplicant.
>
> Depending on how this is implementing, sharing of the physical radio
> may require some kernel synchronization between the different
> interfaces using the same radio. It may also be possible to share the
> same radio between an 802.11 device and a wimax device, for example.
> Long ago we thought up of a frequency broker [1] but never really
> wrote it as we have had no usage case for it yet. If we implement the
> frequency broker we could also technically add a scheduler to sharing
> the same radio between separate interfaces / technologies, this could
> just be done in userspace as well, although I am not sure if the
> timing considerations for doing it in userspace would suffice.

At least for my use, I hope to be able to fully utilize the bandwidth for
a particular channel, and emulate as close as possible a bunch of wireless
devices sharing an AP or set of APs.  So, I don't want to be switching off the main
channel for any significant amount of time.  I think as long as you stick
to the main channel, there are no significant scheduling issues with
the hardware, but I could be wrong about that.

Also, I want to be able to run one supplicant per interface, so while
wpa_supplicant could become clever if it manages multiple devices, I
want them to be able to run independently as well.

As for figuring out what hardware a VIF belongs to, you can deduce this
by following links in sysfs to find it's phyX device.  It is a pain
when the phyX changes name due to module reload or something, but it can still
be dealt with.

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com