RFC: mac80211/ath9k: allow scanning single channel if other VIF is associated.
Subsystems (2)
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
Signature · 2 lines
Ben Greear <[email protected]> Candela Technologies Inc http://www.candelatech.com
drivers/net/wireless/ath/ath9k/main.c +5 -0
@@ -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 )
net/mac80211/ieee80211_i.h +2 -0
@@ -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;
net/mac80211/mlme.c +8 -6
@@ -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);
net/mac80211/rx.c +1 -1
@@ -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))) {
net/mac80211/scan.c +73 -27
162 lines not on this page · raw message
net/mac80211/work.c +11 -6
@@ -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; }
Quoted 3 lines · Ben Greear
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..
Signature · 1 line
Jouni Malinen PGP id EFC895FA
Quoted 9 lines · Jouni Malinen
Quoted 3 lines · Ben Greear
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.)
Quoted 5 lines
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?
Quoted 2 lines
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
Signature · 2 lines
Ben Greear <[email protected]> Candela Technologies Inc http://www.candelatech.com
Quoted 18 lines · Ben Greear
Quoted 9 lines · Jouni Malinen
Quoted 3 lines · Ben Greear
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.
Quoted 7 lines
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
Quoted 19 lines
Quoted 5 lines
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?
Quoted 2 lines
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
Quoted 22 lines · Dan Williams
Quoted 21 lines · Ben Greear
Quoted 9 lines · Jouni Malinen
Quoted 3 lines · Ben Greear
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.
Quoted 7 lines
Quoted 4 lines
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"...
Quoted 27 lines
Dan
Quoted 9 lines
Quoted 5 lines
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?
Quoted 10 lines
Quoted 2 lines
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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 22 lines · Dan Williams
Quoted 21 lines · Ben Greear
Quoted 9 lines · Jouni Malinen
Quoted 3 lines · Ben Greear
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.
Quoted 7 lines
Quoted 4 lines
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
Signature · 2 lines
Ben Greear <[email protected]> Candela Technologies Inc http://www.candelatech.com
Johannes Berg
maintainerQuoted 8 lines · Ben Greear
Quoted 4 lines
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 ...
Quoted 2 lines
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.
Quoted 2 lines
(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.
Quoted 8 lines
Quoted 5 lines
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
Quoted 7 lines · Johannes Berg
Quoted 5 lines · Ben Greear
Quoted 4 lines
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?
Quoted 5 lines
Quoted 3 lines
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.
Quoted 9 lines
Quoted 2 lines
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.
Quoted 2 lines
(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
Signature · 2 lines
Ben Greear <[email protected]> Candela Technologies Inc http://www.candelatech.com
Johannes Berg
maintainerQuoted 3 lines · Ben Greear
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?
Quoted 2 lines
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
Quoted 7 lines · Johannes Berg
Quoted 3 lines · Ben Greear
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).
Quoted 4 lines
Quoted 2 lines
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
Signature · 2 lines
Ben Greear <[email protected]> Candela Technologies Inc http://www.candelatech.com
Johannes Berg
maintainerQuoted 9 lines · Ben Greear
Quoted 5 lines
Quoted 3 lines
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
Quoted 6 lines · Johannes Berg
Quoted 4 lines · Ben Greear
Quoted 4 lines
Quoted 3 lines
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.
Quoted 8 lines
Quoted 5 lines
Quoted 1 line
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
Signature · 2 lines
Ben Greear <[email protected]> Candela Technologies Inc http://www.candelatech.com
Quoted 4 lines · Ben Greear
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.
Signature · 1 line
Jouni Malinen PGP id EFC895FA
Quoted 11 lines · Jouni Malinen
Quoted 4 lines · Ben Greear
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!) withinwpa_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
Quoted 12 lines
Sure, mac80211 could potentially do some of merging and reusing, too, but as far as
wpa_supplicantuse 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 13 lines · Luis R. Rodriguez
Quoted 11 lines · Jouni Malinen
Quoted 4 lines · Ben Greear
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!) withinwpa_supplicant.
Quoted 10 lines
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
Signature · 2 lines
Ben Greear <[email protected]> Candela Technologies Inc http://www.candelatech.com