Hi,
As a result of the thread "Pondering: how to improve mac80211 roaming ..."
I thought a bit more about that topic. Here is a quick suggestion for a first
version:
* Enhance mac80211 software scan to interrupt the current scan and switch
back to the operating channel every once in a while (only if at least one STA
interface is associated) => background scan.
* Enhance mac80211 to check the signal quality frequently (or any other
indicator like beacon misses) and decide when the signal quality is too low.
Indicate that to the user space.
* wpa_supplicant (or any other user space application) gets notified about
the low signal quality and triggers a scan in order to find a better AP.
wpa_supplicant already chooses the AP with the best signal strength.
The reason behind not triggering the scan directly from mac80211 is that the
supplicant (or any other user space application) might know more about the
current environment and could for example trigger a scan restricted to specific
channels (in the future) which should speed up the scan. Hence let the user
space decide what to do with a low signal.
However the detection of when the signal quality is low should still be done in
mac80211 or the driver as some cards seem to have the needed functionality
implemented in firmware (e.g. missed beacon interrupt).
I'll send some proof-of-concept patches in a few minutes which implement
background scanning in software and the user space indication. I've tested them
a bit already and they work quite well with an iwl4965.
Helmut
> If you're concerned about polling or something, we could fix
> that by sending periodic quality events (which would rock!
> then I don't have to poll in NM) on a standardized basis with a
> sliding scale of frequency based on the signal strength
> reported by the card like so:
Ah, I wrote me previous e-mail before I read the rest of your
mail. A thing one, errm, I, shouldn't do :-)
The event that Helmut's code could send could be containing the
current quality. For now, it could be just sent in case of "lost
AP" condition, but we, errm, you, could later submit a patch
that would periodically send this event according to your
suggested schedule or something more cleverer (e.g. only send it
when it significantly changes from the last-sent value, there's
no need to have periodicity here).
A flag would could then define other things beside the quality,
e.g. a FLAG_LOST_AP or FLAG_LOST_BEACON or whatever fit's into
the nl80211 model (which I'm don't know in detail).
Basic implementation of software background scanning functionality.
The patch basically enhances the scanning state machine by two further
states (SCAN_DEFER, SCAN_OPERATION). In state SCAN_DEFER the driver is advised
to switch back to the operating channel while SCAN_OPERATION tells the access
point about being back from power saving and restarts the tx queue. Just before
SCAN_SET_CHANNEL sets the next channel to scan it notifies the access point
about going to power save state and stops the tx queue.
However one (still unresolved) issue is that the code does not wait for the
appropriate ACK from the access point after notifying the new power state.
Any thoughts or comments?
Signed-off-by: Helmut Schaa <[email protected]>
---
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index c05f70c..91eac0b 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -647,11 +647,11 @@ struct ieee80211_local {
/* Scanning and BSS list */
- bool sw_scanning, hw_scanning;
+ bool sw_scanning, hw_scanning, bg_scanning;
int scan_channel_idx;
enum ieee80211_band scan_band;
- enum { SCAN_SET_CHANNEL, SCAN_SEND_PROBE } scan_state;
+ enum { SCAN_SET_CHANNEL, SCAN_SEND_PROBE, SCAN_DEFER, SCAN_OPERATION } scan_state;
unsigned long last_scan_completed;
struct delayed_work scan_work;
struct ieee80211_sub_if_data *scan_sdata;
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index 92d898b..49b5c29 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -414,7 +414,7 @@ ieee80211_rx_h_passive_scan(struct ieee80211_rx_data *rx)
return RX_QUEUED;
}
- if (unlikely(rx->flags & IEEE80211_RX_IN_SCAN)) {
+ if (unlikely(rx->flags & IEEE80211_RX_IN_SCAN && !local->bg_scanning)) {
/* scanning finished during invoking of handlers */
I802_DEBUG_INC(local->rx_handlers_drop_passive_scan);
return RX_DROP_UNUSABLE;
diff --git a/net/mac80211/scan.c b/net/mac80211/scan.c
index 8e6685e..4a9cdfe 100644
--- a/net/mac80211/scan.c
+++ b/net/mac80211/scan.c
@@ -29,6 +29,7 @@
#define IEEE80211_PROBE_DELAY (HZ / 33)
#define IEEE80211_CHANNEL_TIME (HZ / 33)
#define IEEE80211_PASSIVE_CHANNEL_TIME (HZ / 5)
+#define IEEE80211_BG_SCAN_INTERRUPT (HZ / 4)
void ieee80211_rx_bss_list_init(struct ieee80211_local *local)
{
@@ -455,6 +456,7 @@ void ieee80211_scan_completed(struct ieee80211_hw *hw)
}
local->sw_scanning = false;
+ local->bg_scanning = false;
if (ieee80211_hw_config(local))
printk(KERN_DEBUG "%s: failed to restore operational "
"channel after scan\n", wiphy_name(local->hw.wiphy));
@@ -510,6 +512,37 @@ void ieee80211_scan_work(struct work_struct *work)
switch (local->scan_state) {
case SCAN_SET_CHANNEL:
+ if (local->bg_scanning) {
+ /*
+ * background scan is in progress, notify all associated
+ * access points about us leaving the channel and
+ * update the filter flags
+ */
+ local->sw_scanning = 1;
+
+ rcu_read_lock();
+ list_for_each_entry_rcu(sdata, &local->interfaces, list) {
+ if (sdata->vif.type == NL80211_IFTYPE_STATION &&
+ (sdata->u.sta.flags & IEEE80211_STA_ASSOCIATED)) {
+ ieee80211_send_nullfunc(local, sdata, 1);
+ netif_tx_stop_all_queues(sdata->dev);
+ }
+ }
+ rcu_read_unlock();
+
+ /* TODO: start scan as soon as all nullfunc frames are ACKed */
+ msleep(1);
+
+ netif_tx_lock_bh(local->mdev);
+ local->filter_flags |= FIF_BCN_PRBRESP_PROMISC;
+ local->ops->configure_filter(local_to_hw(local),
+ FIF_BCN_PRBRESP_PROMISC,
+ &local->filter_flags,
+ local->mdev->mc_count,
+ local->mdev->mc_list);
+ netif_tx_unlock_bh(local->mdev);
+ }
+
/*
* Get current scan band. scan_band may be IEEE80211_NUM_BANDS
* after we successfully scanned the last channel of the last
@@ -574,7 +607,10 @@ void ieee80211_scan_work(struct work_struct *work)
break;
case SCAN_SEND_PROBE:
next_delay = IEEE80211_PASSIVE_CHANNEL_TIME;
- local->scan_state = SCAN_SET_CHANNEL;
+ if (!local->bg_scanning)
+ local->scan_state = SCAN_SET_CHANNEL;
+ else
+ local->scan_state = SCAN_DEFER;
if (local->scan_channel->flags & IEEE80211_CHAN_PASSIVE_SCAN)
break;
@@ -582,6 +618,50 @@ void ieee80211_scan_work(struct work_struct *work)
local->scan_ssid_len);
next_delay = IEEE80211_CHANNEL_TIME;
break;
+ case SCAN_DEFER:
+ local->scan_state = SCAN_OPERATION;
+ /* interrupt the current scan */
+ local->sw_scanning = 0;
+
+ /* switch back to the operating channel */
+ if (ieee80211_hw_config(local))
+ printk(KERN_DEBUG "%s: failed to restore operational "
+ "channel after scan\n", sdata->dev->name);
+
+ /* reconfigure filter flags*/
+ netif_tx_lock_bh(local->mdev);
+ local->filter_flags &= ~FIF_BCN_PRBRESP_PROMISC;
+ local->ops->configure_filter(local_to_hw(local),
+ FIF_BCN_PRBRESP_PROMISC,
+ &local->filter_flags,
+ local->mdev->mc_count,
+ local->mdev->mc_list);
+
+ netif_tx_unlock_bh(local->mdev);
+
+ /* wait for the channel switch */
+ next_delay = usecs_to_jiffies(local->hw.channel_change_time);
+ break;
+
+ case SCAN_OPERATION:
+ rcu_read_lock();
+ list_for_each_entry_rcu(sdata, &local->interfaces, list) {
+ /* Tell AP we're back */
+ if (sdata->vif.type == NL80211_IFTYPE_STATION &&
+ sdata->u.sta.flags & IEEE80211_STA_ASSOCIATED) {
+ ieee80211_send_nullfunc(local, sdata, 0);
+ netif_tx_wake_all_queues(sdata->dev);
+ }
+ }
+ rcu_read_unlock();
+
+ /* TODO: start scan as soon as all nullfunc frames are ACKed */
+ msleep(1);
+
+ next_delay = IEEE80211_BG_SCAN_INTERRUPT;
+ local->scan_state = SCAN_SET_CHANNEL;
+
+ break;
}
queue_delayed_work(local->hw.workqueue, &local->scan_work,
@@ -615,7 +695,7 @@ int ieee80211_start_scan(struct ieee80211_sub_if_data *scan_sdata,
* ResultCode: SUCCESS, INVALID_PARAMETERS
*/
- if (local->sw_scanning || local->hw_scanning) {
+ if (local->sw_scanning || local->hw_scanning || local->bg_scanning) {
if (local->scan_sdata == scan_sdata)
return 0;
return -EBUSY;
@@ -636,18 +716,28 @@ int ieee80211_start_scan(struct ieee80211_sub_if_data *scan_sdata,
local->sw_scanning = true;
+ /*
+ * if at least one station interface is associated start a background scan
+ * instead of a common software scan
+ */
rcu_read_lock();
list_for_each_entry_rcu(sdata, &local->interfaces, list) {
if (sdata->vif.type == NL80211_IFTYPE_STATION) {
if (sdata->u.sta.flags & IEEE80211_STA_ASSOCIATED) {
- netif_tx_stop_all_queues(sdata->dev);
- ieee80211_send_nullfunc(local, sdata, 1);
+ /*
+ * no need to stop station interaces here, that will be done in
+ * the scan handler
+ */
+ local->bg_scanning = true;
}
} else
netif_tx_stop_all_queues(sdata->dev);
}
rcu_read_unlock();
+ if (!local->bg_scanning)
+ local->sw_scanning = true;
+
if (ssid) {
local->scan_ssid_len = ssid_len;
memcpy(local->scan_ssid, ssid, ssid_len);
@@ -658,14 +748,16 @@ int ieee80211_start_scan(struct ieee80211_sub_if_data *scan_sdata,
local->scan_band = IEEE80211_BAND_2GHZ;
local->scan_sdata = scan_sdata;
- netif_addr_lock_bh(local->mdev);
- local->filter_flags |= FIF_BCN_PRBRESP_PROMISC;
- local->ops->configure_filter(local_to_hw(local),
- FIF_BCN_PRBRESP_PROMISC,
- &local->filter_flags,
- local->mdev->mc_count,
- local->mdev->mc_list);
- netif_addr_unlock_bh(local->mdev);
+ if (!local->bg_scanning) {
+ netif_addr_lock_bh(local->mdev);
+ local->filter_flags |= FIF_BCN_PRBRESP_PROMISC;
+ local->ops->configure_filter(local_to_hw(local),
+ FIF_BCN_PRBRESP_PROMISC,
+ &local->filter_flags,
+ local->mdev->mc_count,
+ local->mdev->mc_list);
+ netif_addr_unlock_bh(local->mdev);
+ }
/* TODO: start scan as soon as all nullfunc frames are ACKed */
queue_delayed_work(local->hw.workqueue, &local->scan_work,
diff --git a/net/mac80211/wext.c b/net/mac80211/wext.c
index 7e0d53a..fd7783a 100644
--- a/net/mac80211/wext.c
+++ b/net/mac80211/wext.c
@@ -566,7 +566,7 @@ static int ieee80211_ioctl_giwscan(struct net_device *dev,
sdata = IEEE80211_DEV_TO_SUB_IF(dev);
- if (local->sw_scanning || local->hw_scanning)
+ if (local->sw_scanning || local->hw_scanning || local->bg_scanning)
return -EAGAIN;
res = ieee80211_scan_results(local, info, extra, data->length);
> So why does this need a new event? Can't wpa_supplicant
> monitor the signal quality (or level/noise if the driver
> doesn't provide "quality") and do what it needs to do without
> any changes to the kernel at all?
It could, but to do this, wpa_supplicant (or whatever) would have
to periodically get awake, send the query command to mac80211
and get the result.
With an event, it just sits sleeping until some interesting event
arrives. Nicer programming idiom, AFAIK.
Am Montag, 15. September 2008 schrieb Dan Williams:
> On Mon, 2008-09-15 at 16:34 +0200, Helmut Schaa wrote:
> > Am Montag, 15. September 2008 16:07:31 schrieb Dan Williams:
> > > On Mon, 2008-09-15 at 14:35 +0200, Helmut Schaa wrote:
> > > > This patch adds a new wext event that notifies the user space about a low
> > > > signal quality. The currently used indicator is as follows: If three
> > > > successive beacons are received with a signal quality lower then 40%
> > > > user space gets informed.
> > > >
> > > > Any ideas about which indicators should be used? Comments?
> > >
> > > So why does this need a new event? Can't wpa_supplicant monitor the
> > > signal quality (or level/noise if the driver doesn't provide "quality")
> > > and do what it needs to do without any changes to the kernel at all?
> >
> > I thought about that as well but I'm not sure if the signal quality/strength
> > is a well enough indicator.
>
> Beacon misses should be a factor in quality, just like failed
> decryptions or excessive retries. Any of these are indications that the
> "link" sucks and you might want to try finding a better AP. Beacon
> misses are just one piece of the whole quality thing.
Right.
> > For example if we want to consider the number of missed beacons the current
> > IWEVQUAL event is not enough to expose this information.
> > Additionally some devices can report missed beacons. Maybe even the quality
> > values reported by the drivers are not comparable at all (although they are
> > normalized to be between 0 and 100). Hence my intention was that mac80211 and
> > the driver might know better which indicators matter.
>
> So if the values aren't comparable, we _make_ them comparable. The
> drivers can certainly tell mac80211 which things they are capable of
> reporting for quality and the stack can figure them in to the final
> "quality" measurement. However, I do agree that having separate
> indicators for the different factors is a good thing. Thus something
> like what Holger suggests would be better from my perspective than an
> ethereal concept like a "roaming threshold". Maybe just a poor choice
> of terms?
Ok, I'll sum that up. Moving the policy into user space is a good thing if the
quality values are comparable. Once mac80211 recognices a noticable quality
change we could use IWEVQUAL to notify user space about it. Furthermore (if
desired) the signal could be extended to not only report a value between 0
and 100 but could also contain flags indicating lost beacons, excessive retries
etc.
Helmut
On Tuesday 16 September 2008 10:25:10 Kalle Valo wrote:
>> My main problem is that adding a beacon threshold to mac80211
>> isn't a
> Still I don't see a problem here, all the mac80211 drivers
> should already now report similar signal strenght to the
> mac80211 in comparable level.
And we could later allow something similar to "iwconfig ethX sens
Y" to modify the the threshold (or whatever else we use, even
some arbitrary calculated quality value). The possibility to
modify this would allow the user to define how eager mac80211 is
when it comes to roaming.
I actually believe that we shouldn't use Quality as roaming
decision base. From what I know, Quality also counts in
re-transmissions, transfer speed (1 MBit/s is worse then 54
MBit/s) and whatever else. Therefore you can calculate quality
only for the current conection.
But when you scan, you only see signal strength and/or SNR of the
APs in sight. You won't know their quality of those APs.
But you could compare your current signal strength and/or SNR to
the signal strength/SNR of the APs in sight.
That would mean that you can use the Quality still for a
decision "Should I do a background scan or not?". But you cannot
use it for a decision "Should I switch to this AP or not?".
And so I wonder why I should use quality in the first place if it
brings me only so far ...
Kalle Valo wrote:
> Helmut Schaa <[email protected]> writes:
>
>>> This doesn't play well at all with hardware assisted scan as far as I
>>> can tell.
>>
>> Correct. The patch only adapts software scan code. The hardware
>> assisted scan is not touched at all but should also not be affected
>> in an odd way.
>
> I would guess that some firmwares support similar scanning in
> hardware. In the future we might add support for background scanning
> in hardware with a flag in hw_scan(), or something like that.
I don't want to see this implemented without taking into account hw scan
offload from the start.
johannes
Am Montag, 15. September 2008 15:59:20 schrieb Dan Williams:
> On Mon, 2008-09-15 at 14:16 +0200, Helmut Schaa wrote:
> > Hi,
> >
> > As a result of the thread "Pondering: how to improve mac80211 roaming
> > ..." I thought a bit more about that topic. Here is a quick suggestion
> > for a first version:
> >
> > * Enhance mac80211 software scan to interrupt the current scan and switch
> > back to the operating channel every once in a while (only if at least
> > one STA interface is associated) => background scan.
> >
> > * Enhance mac80211 to check the signal quality frequently (or any other
> > indicator like beacon misses) and decide when the signal quality is too
> > low. Indicate that to the user space.
> >
> > * wpa_supplicant (or any other user space application) gets notified
> > about the low signal quality and triggers a scan in order to find a
> > better AP. wpa_supplicant already chooses the AP with the best signal
> > strength.
>
> I'm pretty sure it doesn't. The code in wpa_supplicant_select_bss()
> doesn't have any logic to detect signal strength, nor does any driver
> report signal strength to the supplicant. Drivers set the level (well,
> only wext/nl80211, ndis, iphone/osx, and bsd) but I'm pretty sure
> nothing in the supplicant uses it.
Once the supplicant receives the actual scan results it orders them by
security, rate, signal level and finally quality (see
src/drivers/scan_helpers.c, wpa_scan_sort_results). Hence if multiple APs
have the same SSID the one with the best signal level (or quality) will
be the first in the scan results and wpa_supplicant just selects the first
matching AP. Works fine here ;)
> Maybe now is the time to switch that on. That needs to be coupled with
> some additions to cfg80211 to turn firmware/driver roaming on and off,
> along with a capability bit somewhere to indicate that the
> driver/firmware support turning roaming on/off.
True. Which cards that can do roaming in driver/firmware?
Helmut
Am Dienstag, 16. September 2008 10:50:41 schrieb Holger Schurig:
> That would mean that you can use the Quality still for a
> decision "Should I do a background scan or not?". But you cannot
> use it for a decision "Should I switch to this AP or not?".
Agreed. After the scan was triggered (based on whatever indicators) the
decision is up to the supplicant once the scan results arrive. AFAIK it
currently uses max_rate, signal_level and signal_quality (beside the security
flags when multiple networks are defined).
Helmut
Dan Williams <[email protected]> writes:
> Thus something like what Holger suggests would be better from my
> perspective than an ethereal concept like a "roaming threshold".
> Maybe just a poor choice of terms?
I'm sorry but I don't follow you. What ethereal concept are you
talking about here?
To me ethereal was just a sniffer. Does the word mean something else
as well?
--
Kalle Valo
> No need to extend wext here.
Absolutely, that's why I wrote "something similar to". The effect
is important for me, not the way to achive the effect.
On Tue, 2008-09-16 at 11:07 +0300, Kalle Valo wrote:
> From my point of view WE is not on life support (yet) but instead very
> widely used. As an example, I still haven't seen any cfg80211/nl80211
> user space tools in debian unstable. (Please correct me if I'm wrong.)
> There has been a lot of talk about cfg80211/nl80211 but unfortunately
> the migration progress has been very slow.
>
> I definitely want to see this background scan support in Wireless
> Extensions as well, otherwise it might prevent the real use of the
> feature.
However, the more feature we keep stuffing into WEXT the less incentive
is there to actually do something about cfg80211. I'm with Luis here,
the fact that there are no tools anywhere is because those tools aren't
really very useful yet, not because it's not possible to get the tools
in.
johannes
On Mon, 2008-09-15 at 16:18 +0200, Helmut Schaa wrote:
> Am Montag, 15. September 2008 15:59:20 schrieb Dan Williams:
> > On Mon, 2008-09-15 at 14:16 +0200, Helmut Schaa wrote:
> > > Hi,
> > >
> > > As a result of the thread "Pondering: how to improve mac80211 roaming
> > > ..." I thought a bit more about that topic. Here is a quick suggestion
> > > for a first version:
> > >
> > > * Enhance mac80211 software scan to interrupt the current scan and switch
> > > back to the operating channel every once in a while (only if at least
> > > one STA interface is associated) => background scan.
> > >
> > > * Enhance mac80211 to check the signal quality frequently (or any other
> > > indicator like beacon misses) and decide when the signal quality is too
> > > low. Indicate that to the user space.
> > >
> > > * wpa_supplicant (or any other user space application) gets notified
> > > about the low signal quality and triggers a scan in order to find a
> > > better AP. wpa_supplicant already chooses the AP with the best signal
> > > strength.
> >
> > I'm pretty sure it doesn't. The code in wpa_supplicant_select_bss()
> > doesn't have any logic to detect signal strength, nor does any driver
> > report signal strength to the supplicant. Drivers set the level (well,
> > only wext/nl80211, ndis, iphone/osx, and bsd) but I'm pretty sure
> > nothing in the supplicant uses it.
>
> Once the supplicant receives the actual scan results it orders them by
> security, rate, signal level and finally quality (see
> src/drivers/scan_helpers.c, wpa_scan_sort_results). Hence if multiple APs
> have the same SSID the one with the best signal level (or quality) will
> be the first in the scan results and wpa_supplicant just selects the first
> matching AP. Works fine here ;)
Ah, ok. Hadn't caught that part.
> > Maybe now is the time to switch that on. That needs to be coupled with
> > some additions to cfg80211 to turn firmware/driver roaming on and off,
> > along with a capability bit somewhere to indicate that the
> > driver/firmware support turning roaming on/off.
>
> True. Which cards that can do roaming in driver/firmware?
Most fullmac ones. airo, atmel, orinoco, libertas, ipw2100/2200/2915,
etc.
Dan
Am Dienstag, 16. September 2008 03:21:17 schrieb Luis R. Rodriguez:
> On Mon, Sep 15, 2008 at 9:45 AM, Helmut Schaa <[email protected]> wrote:
> > Ok, I'll sum that up. Moving the policy into user space is a good thing
> > if the quality values are comparable. Once mac80211 recognices a
> > noticable quality change we could use IWEVQUAL to notify user space about
> > it. Furthermore (if desired) the signal could be extended to not only
> > report a value between 0 and 100 but could also contain flags indicating
> > lost beacons, excessive retries etc.
>
> If you are going to add a new sort of notification can you please use
> nl80211? No need to keep wireless extensions on life support.
Sure. Nevertheless I'd like to use the already existing IWEVQUAL (without
modifications) too. Hence the supplicant's wext-driver could use the plain
quality value to decide when it is time to trigger a scan while the
nl80211-driver could use more indicators.
Arguments for or against moving the decision to user space (by notifying the
supplicant only about signal quality changes without rating the values)?
Thanks,
Helmut
Am Montag, 15. September 2008 16:07:31 schrieb Dan Williams:
> On Mon, 2008-09-15 at 14:35 +0200, Helmut Schaa wrote:
> > This patch adds a new wext event that notifies the user space about a low
> > signal quality. The currently used indicator is as follows: If three
> > successive beacons are received with a signal quality lower then 40%
> > user space gets informed.
> >
> > Any ideas about which indicators should be used? Comments?
>
> So why does this need a new event? Can't wpa_supplicant monitor the
> signal quality (or level/noise if the driver doesn't provide "quality")
> and do what it needs to do without any changes to the kernel at all?
I thought about that as well but I'm not sure if the signal quality/strength
is a well enough indicator.
For example if we want to consider the number of missed beacons the current
IWEVQUAL event is not enough to expose this information.
Additionally some devices can report missed beacons. Maybe even the quality
values reported by the drivers are not comparable at all (although they are
normalized to be between 0 and 100). Hence my intention was that mac80211 and
the driver might know better which indicators matter.
Helmut
Helmut Schaa <[email protected]> writes:
> Ok, I'll sum that up. Moving the policy into user space is a good
> thing if the quality values are comparable. Once mac80211 recognices
> a noticable quality change we could use IWEVQUAL to notify user
> space about it. Furthermore (if desired) the signal could be
> extended to not only report a value between 0 and 100 but could also
> contain flags indicating lost beacons, excessive retries etc.
I guess that would work.
--
Kalle Valo
Am Montag, 15. September 2008 16:32:00 schrieb Michael Buesch:
> On Monday 15 September 2008 14:29:46 Helmut Schaa wrote:
> > - if (unlikely(rx->flags & IEEE80211_RX_IN_SCAN)) {
> > + if (unlikely(rx->flags & IEEE80211_RX_IN_SCAN && !local->bg_scanning))
> > {
>
> Does & have precedence over && or the other way around?
AFAIK & has precedence ;)
> I don't know and I don't want to. Please use parens ;)
Anyway parentheses make it definitively more readable.
On Mon, 2008-09-15 at 14:16 +0200, Helmut Schaa wrote:
> Hi,
>
> As a result of the thread "Pondering: how to improve mac80211 roaming ..."
> I thought a bit more about that topic. Here is a quick suggestion for a first
> version:
>
> * Enhance mac80211 software scan to interrupt the current scan and switch
> back to the operating channel every once in a while (only if at least one STA
> interface is associated) => background scan.
>
> * Enhance mac80211 to check the signal quality frequently (or any other
> indicator like beacon misses) and decide when the signal quality is too low.
> Indicate that to the user space.
>
> * wpa_supplicant (or any other user space application) gets notified about
> the low signal quality and triggers a scan in order to find a better AP.
> wpa_supplicant already chooses the AP with the best signal strength.
I'm pretty sure it doesn't. The code in wpa_supplicant_select_bss()
doesn't have any logic to detect signal strength, nor does any driver
report signal strength to the supplicant. Drivers set the level (well,
only wext/nl80211, ndis, iphone/osx, and bsd) but I'm pretty sure
nothing in the supplicant uses it.
Maybe now is the time to switch that on. That needs to be coupled with
some additions to cfg80211 to turn firmware/driver roaming on and off,
along with a capability bit somewhere to indicate that the
driver/firmware support turning roaming on/off.
Dan
> The reason behind not triggering the scan directly from mac80211 is that the
> supplicant (or any other user space application) might know more about the
> current environment and could for example trigger a scan restricted to specific
> channels (in the future) which should speed up the scan. Hence let the user
> space decide what to do with a low signal.
>
> However the detection of when the signal quality is low should still be done in
> mac80211 or the driver as some cards seem to have the needed functionality
> implemented in firmware (e.g. missed beacon interrupt).
>
> I'll send some proof-of-concept patches in a few minutes which implement
> background scanning in software and the user space indication. I've tested them
> a bit already and they work quite well with an iwl4965.
>
> Helmut
> --
> 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
Here is the appropriate wpa_supplicant patch for reference.
It simply triggers a new scan once a "low signal notification" was received.
diff -ur wpa_supplicant-0.6.4/src/common/wireless_copy.h wpa_supplicant-0.6.4_2//src/common/wireless_copy.h
--- wpa_supplicant-0.6.4/src/common/wireless_copy.h 2008-08-10 19:33:12.000000000 +0200
+++ wpa_supplicant-0.6.4_2//src/common/wireless_copy.h 2008-09-15 11:38:14.000000000 +0200
@@ -396,6 +396,8 @@
* pre-authentication
* (struct iw_pmkid_cand) */
+#define IWEVROAM 0x8C0A /* roaming threshold exceeded */
+
#define IWEVFIRST 0x8C00
#define IW_EVENT_IDX(cmd) ((cmd) - IWEVFIRST)
diff -ur wpa_supplicant-0.6.4/src/drivers/driver.h wpa_supplicant-0.6.4_2//src/drivers/driver.h
--- wpa_supplicant-0.6.4/src/drivers/driver.h 2008-08-10 19:33:12.000000000 +0200
+++ wpa_supplicant-0.6.4_2//src/drivers/driver.h 2008-09-15 11:30:50.000000000 +0200
@@ -1052,7 +1052,13 @@
* FT authentication sequence from the AP. The FT IEs are included in
* the extra information in union wpa_event_data::ft_ies.
*/
- EVENT_FT_RESPONSE
+ EVENT_FT_RESPONSE,
+
+ /**
+ * EVENT_ROAMING_THRESHOLD - Roaming threshold exceeded
+ */
+ EVENT_ROAMING_THRESHOLD
+
} wpa_event_type;
diff -ur wpa_supplicant-0.6.4/src/drivers/driver_wext.c wpa_supplicant-0.6.4_2//src/drivers/driver_wext.c
--- wpa_supplicant-0.6.4/src/drivers/driver_wext.c 2008-08-10 19:33:12.000000000 +0200
+++ wpa_supplicant-0.6.4_2//src/drivers/driver_wext.c 2008-09-15 11:40:50.000000000 +0200
@@ -497,8 +497,7 @@
return 0;
}
-
-
+
static int wpa_driver_wext_event_wireless_pmkidcand(
struct wpa_driver_wext_data *drv, const char *ev, size_t len)
{
@@ -684,6 +683,9 @@
wpa_driver_wext_event_wireless_pmkidcand(
drv, custom, iwe->u.data.length);
break;
+ case IWEVROAM:
+ wpa_supplicant_event(ctx, EVENT_ROAMING_THRESHOLD, NULL);
+ break;
}
pos += iwe->len;
diff -ur wpa_supplicant-0.6.4/wpa_supplicant/events.c wpa_supplicant-0.6.4_2//wpa_supplicant/events.c
--- wpa_supplicant-0.6.4/wpa_supplicant/events.c 2008-08-10 19:33:12.000000000 +0200
+++ wpa_supplicant-0.6.4_2//wpa_supplicant/events.c 2008-09-15 12:14:13.000000000 +0200
@@ -613,6 +613,10 @@
}
#endif /* CONFIG_NO_SCAN_PROCESSING */
+static void wpa_supplicant_event_roaming_threshold(struct wpa_supplicant *wpa_s)
+{
+ wpa_supplicant_req_scan(wpa_s, 0, 0);
+}
static void wpa_supplicant_event_associnfo(struct wpa_supplicant *wpa_s,
union wpa_event_data *data)
@@ -955,6 +959,9 @@
wpa_supplicant_event_ft_response(wpa_s, data);
break;
#endif /* CONFIG_IEEE80211R */
+ case EVENT_ROAMING_THRESHOLD:
+ wpa_supplicant_event_roaming_threshold(wpa_s);
+ break;
default:
wpa_printf(MSG_INFO, "Unknown event %d", event);
break;
On Tue, Sep 16, 2008 at 11:55:38AM +0300, Kalle Valo wrote:
> Johannes Berg <[email protected]> writes:
>
> > On Tue, 2008-09-16 at 11:07 +0300, Kalle Valo wrote:
> >
> >> I definitely want to see this background scan support in Wireless
> >> Extensions as well, otherwise it might prevent the real use of the
> >> feature.
> >
> > However, the more feature we keep stuffing into WEXT the less incentive
> > is there to actually do something about cfg80211. I'm with Luis here,
> > the fact that there are no tools anywhere is because those tools aren't
> > really very useful yet, not because it's not possible to get the tools
> > in.
>
> I understand yours and Luis' points. But I still think that we should
> push cfg80211 acceptance first with the argument of more reliable
> method of configure 80211 devices, and only later start adding
> cfg80211-only features.
cfg80211-only features may be a great reason for people to move to
the new tools. Considering how fragile WEXT has proven to be, I am
not at all in favor of continuing to extend it.
John
--
John W. Linville Linux should be at the core
[email protected] of your literate lifestyle.
On Mon, 2008-09-15 at 14:35 +0200, Helmut Schaa wrote:
> This patch adds a new wext event that notifies the user space about a low
> signal quality. The currently used indicator is as follows: If three
> successive beacons are received with a signal quality lower then 40%
> user space gets informed.
>
> Any ideas about which indicators should be used? Comments?
So why does this need a new event? Can't wpa_supplicant monitor the
signal quality (or level/noise if the driver doesn't provide "quality")
and do what it needs to do without any changes to the kernel at all?
That's what any userspace process already does. If you're concerned
about polling or something, we could fix that by sending periodic
quality events (which would rock! then I don't have to poll in NM) on a
standardized basis with a sliding scale of frequency based on the signal
strength reported by the card like so:
1 - 10%: every 2 seconds
11 - 20%: every 3 seconds
21 - 30%: every 4 seconds
31 - 100%: every 5 seconds
Stuff can still poll if it really really wants to. I'm concerned about
adding arbitrary "roaming thresholds" to the stack, since that can
certainly mean different things to different programs. It's not
necessarily a system-wide value, and adding it as another tweakable
seems unnecessary.
We've already got IWEVQUAL, why don't we use it?
Dan
> Signed-off-by: Helmut Schaa <[email protected]>
> ---
> diff --git a/include/linux/wireless.h b/include/linux/wireless.h
> index d7958f9..6229aa2 100644
> --- a/include/linux/wireless.h
> +++ b/include/linux/wireless.h
> @@ -294,6 +294,7 @@
> #define SIOCSIWPOWER 0x8B2C /* set Power Management settings */
> #define SIOCGIWPOWER 0x8B2D /* get Power Management settings */
>
> +
> /* WPA : Generic IEEE 802.11 informatiom element (e.g., for WPA/RSN/WMM).
> * This ioctl uses struct iw_point and data buffer that includes IE id and len
> * fields. More than one IE may be included in the request. Setting the generic
> @@ -389,6 +390,8 @@
> * pre-authentication
> * (struct iw_pmkid_cand) */
>
> +#define IWEVROAM 0x8C0A /* roaming threshold exceeded */
> +
> #define IWEVFIRST 0x8C00
> #define IW_EVENT_IDX(cmd) ((cmd) - IWEVFIRST)
>
> diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
> index 3912fba..c05f70c 100644
> --- a/net/mac80211/ieee80211_i.h
> +++ b/net/mac80211/ieee80211_i.h
> @@ -351,6 +351,7 @@ struct ieee80211_if_sta {
> u32 supp_rates_bits[IEEE80211_NUM_BANDS];
>
> int wmm_last_param_set;
> + unsigned int roam_threshold_count;
> };
>
> struct ieee80211_if_mesh {
> diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
> index 2e55208..e67fe56 100644
> --- a/net/mac80211/mlme.c
> +++ b/net/mac80211/mlme.c
> @@ -45,6 +45,7 @@
>
> #define IEEE80211_IBSS_MAX_STA_ENTRIES 128
>
> +#define IEEE80211_ROAMING_QUALITY_THRESHOLD 40
>
> /* utils */
> static int ecw2cw(int ecw)
> @@ -1659,6 +1660,27 @@ static void ieee80211_rx_mgmt_probe_resp(struct ieee80211_sub_if_data *sdata,
> }
> }
>
> +static void ieee80211_rx_check_threshold(struct ieee80211_sub_if_data *sdata,
> + int freq)
> +{
> + union iwreq_data wrqu;
> + struct ieee80211_bss *bss;
> + struct ieee80211_if_sta *ifsta = &sdata->u.sta;
> + bss = ieee80211_rx_bss_get(sdata->local, ifsta->bssid, freq,
> + ifsta->ssid, ifsta->ssid_len);
> +
> + if (bss->qual < IEEE80211_ROAMING_QUALITY_THRESHOLD) {
> + if (++(ifsta->roam_threshold_count) > 3) {
> + printk(KERN_DEBUG "%s roaming theshold exceeded\n",
> + sdata->dev->name);
> + memset(&wrqu, 0, sizeof(wrqu));
> + wireless_send_event(sdata->dev, IWEVROAM, &wrqu, NULL);
> + }
> + } else
> + ifsta->roam_threshold_count = 0;
> +
> + ieee80211_rx_bss_put(sdata->local, bss);
> +}
>
> static void ieee80211_rx_mgmt_beacon(struct ieee80211_sub_if_data *sdata,
> struct ieee80211_mgmt *mgmt,
> @@ -1711,6 +1733,7 @@ static void ieee80211_rx_mgmt_beacon(struct ieee80211_sub_if_data *sdata,
> &bss_info);
> }
>
> + ieee80211_rx_check_threshold(sdata, rx_status->freq);
> ieee80211_bss_info_change_notify(sdata, changed);
> }
>
> diff --git a/net/wireless/wext.c b/net/wireless/wext.c
> index d98ffb7..c2feebb 100644
> --- a/net/wireless/wext.c
> +++ b/net/wireless/wext.c
> @@ -387,6 +387,9 @@ static const struct iw_ioctl_description standard_event[] = {
> .token_size = 1,
> .max_tokens = sizeof(struct iw_pmkid_cand),
> },
> + [IWEVROAM - IWEVFIRST] = {
> + .header_type = IW_HEADER_TYPE_ADDR,
> + },
> };
> static const unsigned standard_event_num = ARRAY_SIZE(standard_event);
>
> --
> 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
Dan Williams <[email protected]> writes:
> On Mon, 2008-09-15 at 17:10 +0200, Holger Schurig wrote:
>> > So why does this need a new event? Can't wpa_supplicant
>> > monitor the signal quality (or level/noise if the driver
>> > doesn't provide "quality") and do what it needs to do without
>> > any changes to the kernel at all?
>>
>> It could, but to do this, wpa_supplicant (or whatever) would have
>> to periodically get awake, send the query command to mac80211
>> and get the result.
>>
>> With an event, it just sits sleeping until some interesting event
>> arrives. Nicer programming idiom, AFAIK.
I agree, this is the kind of design we should strive for.
> Except that everything that listens to WEXT events gets woken up every
> time an event comes in anyway. So any card doing background scanning
> will wake up the supplicant too
No, in good condition there won't be scanning going on and hence
nothing will wake up supplicant. And with good hardware design (with
beacon filtering) not even the CPU is woken up. But you are proposing
means that the suplicant (and hence the CPU) would be waken all the
time, despite the signal condition. Not good.
> I honestly think that every few seconds is OK here.
No, it really isn't ok. There are CPUs, like TI's OMAP 3430, where CPU
wake up takes a relatively long time and is expensive from power
consumption point of view. Useless periodic timers are a bad idea.
> My main problem is that adding a beacon threshold to mac80211 isn't a
> great idea because it's not a standard value and it's not something
> really applicable to mac80211; it's policy which is different for
> different programs, and the way you've implemented it here it's global
> for the interface.
Still I don't see a problem here, all the mac80211 drivers should
already now report similar signal strenght to the mac80211 in
comparable level. And I doubt that there's that much need for the
applications to adjust the roaming thershold itself. I would assume it
would be more like enable and disable, if not even that.
Of course it would be nice to be able to configure the threshold from
user space, but I find that as an extra feature. We should try get
good default values by testing.
--
Kalle Valo
On Tue, Sep 16, 2008 at 11:43 AM, Kalle Valo <[email protected]> wrote:
> Helmut Schaa <[email protected]> writes:
>
>>> This doesn't play well at all with hardware assisted scan as far as I
>>> can tell.
>>
>> Correct. The patch only adapts software scan code. The hardware
>> assisted scan is not touched at all but should also not be affected
>> in an odd way.
>
> I would guess that some firmwares support similar scanning in
> hardware. In the future we might add support for background scanning
> in hardware with a flag in hw_scan(), or something like that.
In iwwlifi we can trigger scan anytime during association so this is
not an issue.
The common point for sw and hw is when to trigger scanning and what
are scanning parameters.
The objective is that this affect performance, therefore the scan can
be triggered on
1. On limited number of channels
a. After first scan we know which channels are active or activated
(passive channels with traffic)
b. We can scan only channels with possible roaming candidates
(same SSID or list of possible SSIDs)
2. Group scanning
Issue scanning in small group of channels and returning back to the
serving channel. The size of group
is affected by current traffic rate and quality. Size of group
effects off channel time (#channels * dwell time)
Thanks
Tomas
Helmut Schaa <[email protected]> writes:
>> This doesn't play well at all with hardware assisted scan as far as I
>> can tell.
>
> Correct. The patch only adapts software scan code. The hardware
> assisted scan is not touched at all but should also not be affected
> in an odd way.
I would guess that some firmwares support similar scanning in
hardware. In the future we might add support for background scanning
in hardware with a flag in hw_scan(), or something like that.
--
Kalle Valo
On Mon, 2008-09-15 at 16:34 +0200, Helmut Schaa wrote:
> Am Montag, 15. September 2008 16:07:31 schrieb Dan Williams:
> > On Mon, 2008-09-15 at 14:35 +0200, Helmut Schaa wrote:
> > > This patch adds a new wext event that notifies the user space about a low
> > > signal quality. The currently used indicator is as follows: If three
> > > successive beacons are received with a signal quality lower then 40%
> > > user space gets informed.
> > >
> > > Any ideas about which indicators should be used? Comments?
> >
> > So why does this need a new event? Can't wpa_supplicant monitor the
> > signal quality (or level/noise if the driver doesn't provide "quality")
> > and do what it needs to do without any changes to the kernel at all?
>
> I thought about that as well but I'm not sure if the signal quality/strength
> is a well enough indicator.
Beacon misses should be a factor in quality, just like failed
decryptions or excessive retries. Any of these are indications that the
"link" sucks and you might want to try finding a better AP. Beacon
misses are just one piece of the whole quality thing.
> For example if we want to consider the number of missed beacons the current
> IWEVQUAL event is not enough to expose this information.
> Additionally some devices can report missed beacons. Maybe even the quality
> values reported by the drivers are not comparable at all (although they are
> normalized to be between 0 and 100). Hence my intention was that mac80211 and
> the driver might know better which indicators matter.
So if the values aren't comparable, we _make_ them comparable. The
drivers can certainly tell mac80211 which things they are capable of
reporting for quality and the stack can figure them in to the final
"quality" measurement. However, I do agree that having separate
indicators for the different factors is a good thing. Thus something
like what Holger suggests would be better from my perspective than an
ethereal concept like a "roaming threshold". Maybe just a poor choice
of terms?
Dan
Luis R. Rodriguez <[email protected]> writes:
> On Mon, Sep 15, 2008 at 9:45 AM, Helmut Schaa <[email protected]> wrote:
>
>> Ok, I'll sum that up. Moving the policy into user space is a good
>> thing if the quality values are comparable. Once mac80211
>> recognices a noticable quality change we could use IWEVQUAL to
>> notify user space about it. Furthermore (if desired) the signal
>> could be extended to not only report a value between 0 and 100 but
>> could also contain flags indicating lost beacons, excessive retries
>> etc.
>
> If you are going to add a new sort of notification can you please use
> nl80211? No need to keep wireless extensions on life support.
>From my point of view WE is not on life support (yet) but instead very
widely used. As an example, I still haven't seen any cfg80211/nl80211
user space tools in debian unstable. (Please correct me if I'm wrong.)
There has been a lot of talk about cfg80211/nl80211 but unfortunately
the migration progress has been very slow.
I definitely want to see this background scan support in Wireless
Extensions as well, otherwise it might prevent the real use of the
feature.
--
Kalle Valo
On Tue, 2008-09-16 at 11:20 +0200, Helmut Schaa wrote:
> Ok, would you accept a hardware flag that indicates if a card is able to
> do background scanning? And if the flag is not set we could just use a
> software background scan as fallback?
No, I'd think that it the scan offload is incapable of doing background
scanning then it's useless and shouldn't be used.
johannes
"Helmut Schaa" <[email protected]> writes:
> Hi,
Hello,
very good that you have been working on this. Like we discussed
earlier, this in an area where we need to improve mac80211.
Due to travelling (ad: Maemo Summit at Berlin) I don't have time to
test your patches this week, but hopefully next week. Few comments
first:
> * Enhance mac80211 to check the signal quality frequently (or any other
> indicator like beacon misses) and decide when the signal quality is too low.
> Indicate that to the user space.
>
> * wpa_supplicant (or any other user space application) gets notified about
> the low signal quality and triggers a scan in order to find a better AP.
> wpa_supplicant already chooses the AP with the best signal strength.
I think we should have two signals with different states. One for
informing that low signal condition has started and another one for
telling that low signal condition has ended (ie. the device has good
signal to the AP).
In the low signal state wpa_supplicant would then periodically scan
for better APs.
> The reason behind not triggering the scan directly from mac80211 is
> that the supplicant (or any other user space application) might know
> more about the current environment and could for example trigger a
> scan restricted to specific channels (in the future) which should
> speed up the scan. Hence let the user space decide what to do with a
> low signal.
Exactly.
> However the detection of when the signal quality is low should still
> be done in mac80211 or the driver as some cards seem to have the
> needed functionality implemented in firmware (e.g. missed beacon
> interrupt).
I agree.
--
Kalle Valo
Am Dienstag, 16. September 2008 11:10:10 schrieb Johannes Berg:
> Kalle Valo wrote:
> > Helmut Schaa <[email protected]> writes:
> >>> This doesn't play well at all with hardware assisted scan as far as I
> >>> can tell.
> >>
> >> Correct. The patch only adapts software scan code. The hardware
> >> assisted scan is not touched at all but should also not be affected
> >> in an odd way.
> >
> > I would guess that some firmwares support similar scanning in
> > hardware. In the future we might add support for background scanning
> > in hardware with a flag in hw_scan(), or something like that.
>
> I don't want to see this implemented without taking into account hw scan
> offload from the start.
Ok, would you accept a hardware flag that indicates if a card is able to
do background scanning? And if the flag is not set we could just use a
software background scan as fallback?
Helmut
Dan Williams <[email protected]> writes:
> On Mon, 2008-09-15 at 14:35 +0200, Helmut Schaa wrote:
>> This patch adds a new wext event that notifies the user space about a low
>> signal quality. The currently used indicator is as follows: If three
>> successive beacons are received with a signal quality lower then 40%
>> user space gets informed.
>>
>> Any ideas about which indicators should be used? Comments?
>
> So why does this need a new event? Can't wpa_supplicant monitor the
> signal quality (or level/noise if the driver doesn't provide "quality")
> and do what it needs to do without any changes to the kernel at all?
Because that's polling. 10 years ago polling might be acceptable, but
not anymore. We need to improve our power consumption and to do that
we have to avoid waking up CPU (and rest of the system) as much as
possible.
> That's what any userspace process already does. If you're concerned
> about polling or something, we could fix that by sending periodic
> quality events
Periodic events are as worse as polling, still the CPU is waken up
unnecessarily.
> I'm concerned about adding arbitrary "roaming thresholds" to the
> stack, since that can certainly mean different things to different
> programs. It's not necessarily a system-wide value, and adding it as
> another tweakable seems unnecessary.
I don't see a problem here. We have to have a threshold somewhere and,
in my opinion, mac80211 is the best place to have it. That way it's
easier in the future when we want to improve the roaming logic because
mac80211 has the best information available to make the decision of
bad coverage to the AP.
> We've already got IWEVQUAL, why don't we use it?
Maybe, if we can provide all the necessary information to user space.
Remember that this is not all about signal level, I'm sure we will
want to use other parameters as well.
But what's so bad of adding a new event to WE? This is clearly a new
feature in WE and I don't see why we have to start overloading old
events.
--
Kalle Valo
Johannes Berg <[email protected]> writes:
> On Tue, 2008-09-16 at 11:07 +0300, Kalle Valo wrote:
>
>> I definitely want to see this background scan support in Wireless
>> Extensions as well, otherwise it might prevent the real use of the
>> feature.
>
> However, the more feature we keep stuffing into WEXT the less incentive
> is there to actually do something about cfg80211. I'm with Luis here,
> the fact that there are no tools anywhere is because those tools aren't
> really very useful yet, not because it's not possible to get the tools
> in.
I understand yours and Luis' points. But I still think that we should
push cfg80211 acceptance first with the argument of more reliable
method of configure 80211 devices, and only later start adding
cfg80211-only features.
--
Kalle Valo
On Mon, Sep 15, 2008 at 9:45 AM, Helmut Schaa <[email protected]> wrote:
> Ok, I'll sum that up. Moving the policy into user space is a good thing if the
> quality values are comparable. Once mac80211 recognices a noticable quality
> change we could use IWEVQUAL to notify user space about it. Furthermore (if
> desired) the signal could be extended to not only report a value between 0
> and 100 but could also contain flags indicating lost beacons, excessive retries
> etc.
If you are going to add a new sort of notification can you please use
nl80211? No need to keep wireless extensions on life support.
Luis
This patch adds a new wext event that notifies the user space about a low
signal quality. The currently used indicator is as follows: If three
successive beacons are received with a signal quality lower then 40%
user space gets informed.
Any ideas about which indicators should be used? Comments?
Signed-off-by: Helmut Schaa <[email protected]>
---
diff --git a/include/linux/wireless.h b/include/linux/wireless.h
index d7958f9..6229aa2 100644
--- a/include/linux/wireless.h
+++ b/include/linux/wireless.h
@@ -294,6 +294,7 @@
#define SIOCSIWPOWER 0x8B2C /* set Power Management settings */
#define SIOCGIWPOWER 0x8B2D /* get Power Management settings */
+
/* WPA : Generic IEEE 802.11 informatiom element (e.g., for WPA/RSN/WMM).
* This ioctl uses struct iw_point and data buffer that includes IE id and len
* fields. More than one IE may be included in the request. Setting the generic
@@ -389,6 +390,8 @@
* pre-authentication
* (struct iw_pmkid_cand) */
+#define IWEVROAM 0x8C0A /* roaming threshold exceeded */
+
#define IWEVFIRST 0x8C00
#define IW_EVENT_IDX(cmd) ((cmd) - IWEVFIRST)
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index 3912fba..c05f70c 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -351,6 +351,7 @@ struct ieee80211_if_sta {
u32 supp_rates_bits[IEEE80211_NUM_BANDS];
int wmm_last_param_set;
+ unsigned int roam_threshold_count;
};
struct ieee80211_if_mesh {
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 2e55208..e67fe56 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -45,6 +45,7 @@
#define IEEE80211_IBSS_MAX_STA_ENTRIES 128
+#define IEEE80211_ROAMING_QUALITY_THRESHOLD 40
/* utils */
static int ecw2cw(int ecw)
@@ -1659,6 +1660,27 @@ static void ieee80211_rx_mgmt_probe_resp(struct ieee80211_sub_if_data *sdata,
}
}
+static void ieee80211_rx_check_threshold(struct ieee80211_sub_if_data *sdata,
+ int freq)
+{
+ union iwreq_data wrqu;
+ struct ieee80211_bss *bss;
+ struct ieee80211_if_sta *ifsta = &sdata->u.sta;
+ bss = ieee80211_rx_bss_get(sdata->local, ifsta->bssid, freq,
+ ifsta->ssid, ifsta->ssid_len);
+
+ if (bss->qual < IEEE80211_ROAMING_QUALITY_THRESHOLD) {
+ if (++(ifsta->roam_threshold_count) > 3) {
+ printk(KERN_DEBUG "%s roaming theshold exceeded\n",
+ sdata->dev->name);
+ memset(&wrqu, 0, sizeof(wrqu));
+ wireless_send_event(sdata->dev, IWEVROAM, &wrqu, NULL);
+ }
+ } else
+ ifsta->roam_threshold_count = 0;
+
+ ieee80211_rx_bss_put(sdata->local, bss);
+}
static void ieee80211_rx_mgmt_beacon(struct ieee80211_sub_if_data *sdata,
struct ieee80211_mgmt *mgmt,
@@ -1711,6 +1733,7 @@ static void ieee80211_rx_mgmt_beacon(struct ieee80211_sub_if_data *sdata,
&bss_info);
}
+ ieee80211_rx_check_threshold(sdata, rx_status->freq);
ieee80211_bss_info_change_notify(sdata, changed);
}
diff --git a/net/wireless/wext.c b/net/wireless/wext.c
index d98ffb7..c2feebb 100644
--- a/net/wireless/wext.c
+++ b/net/wireless/wext.c
@@ -387,6 +387,9 @@ static const struct iw_ioctl_description standard_event[] = {
.token_size = 1,
.max_tokens = sizeof(struct iw_pmkid_cand),
},
+ [IWEVROAM - IWEVFIRST] = {
+ .header_type = IW_HEADER_TYPE_ADDR,
+ },
};
static const unsigned standard_event_num = ARRAY_SIZE(standard_event);
Am Dienstag, 16. September 2008 10:50:41 schrieb Holger Schurig:
> On Tuesday 16 September 2008 10:25:10 Kalle Valo wrote:
> >> My main problem is that adding a beacon threshold to mac80211
> >> isn't a
> >
> > Still I don't see a problem here, all the mac80211 drivers
> > should already now report similar signal strenght to the
> > mac80211 in comparable level.
>
> And we could later allow something similar to "iwconfig ethX sens
> Y" to modify the the threshold (or whatever else we use, even
> some arbitrary calculated quality value). The possibility to
> modify this would allow the user to define how eager mac80211 is
> when it comes to roaming.
That would be nice, yes. If the user knows that only one AP is around and
roaming will never be successful he should have the possibility to turn
background scanning/roaming off. However implementing that for nl80211 should
suffice. No need to extend wext here.
Helmut
Am Montag, 15. September 2008 schrieb Johannes Berg:
> On Mon, 2008-09-15 at 14:29 +0200, Helmut Schaa wrote:
> > Basic implementation of software background scanning functionality.
> >
> > The patch basically enhances the scanning state machine by two further
> > states (SCAN_DEFER, SCAN_OPERATION). In state SCAN_DEFER the driver is advised
> > to switch back to the operating channel while SCAN_OPERATION tells the access
> > point about being back from power saving and restarts the tx queue. Just before
> > SCAN_SET_CHANNEL sets the next channel to scan it notifies the access point
> > about going to power save state and stops the tx queue.
> >
> > However one (still unresolved) issue is that the code does not wait for the
> > appropriate ACK from the access point after notifying the new power state.
> >
> > Any thoughts or comments?
>
> This doesn't play well at all with hardware assisted scan as far as I
> can tell.
Correct. The patch only adapts software scan code. The hardware assisted scan
is not touched at all but should also not be affected in an odd way.
Helmut
On Mon, 2008-09-15 at 17:10 +0200, Holger Schurig wrote:
> > So why does this need a new event? Can't wpa_supplicant
> > monitor the signal quality (or level/noise if the driver
> > doesn't provide "quality") and do what it needs to do without
> > any changes to the kernel at all?
>
> It could, but to do this, wpa_supplicant (or whatever) would have
> to periodically get awake, send the query command to mac80211
> and get the result.
>
> With an event, it just sits sleeping until some interesting event
> arrives. Nicer programming idiom, AFAIK.
Except that everything that listens to WEXT events gets woken up every
time an event comes in anyway. So any card doing background scanning
will wake up the supplicant too; I honestly think that every few seconds
is OK here. BTW, make sure you rate-limit the background scanning
events from mac80211 in your patches to every few seconds (I picked 4
for ipw2200) otherwise it floods events and wakes up everything all the
time.
My main problem is that adding a beacon threshold to mac80211 isn't a
great idea because it's not a standard value and it's not something
really applicable to mac80211; it's policy which is different for
different programs, and the way you've implemented it here it's global
for the interface.
Dan
On Monday 15 September 2008 14:29:46 Helmut Schaa wrote:
> - if (unlikely(rx->flags & IEEE80211_RX_IN_SCAN)) {
> + if (unlikely(rx->flags & IEEE80211_RX_IN_SCAN && !local->bg_scanning)) {
Does & have precedence over && or the other way around?
I don't know and I don't want to. Please use parens ;)
--
Greetings Michael.
On Mon, 2008-09-15 at 14:29 +0200, Helmut Schaa wrote:
> Basic implementation of software background scanning functionality.
>
> The patch basically enhances the scanning state machine by two further
> states (SCAN_DEFER, SCAN_OPERATION). In state SCAN_DEFER the driver is advised
> to switch back to the operating channel while SCAN_OPERATION tells the access
> point about being back from power saving and restarts the tx queue. Just before
> SCAN_SET_CHANNEL sets the next channel to scan it notifies the access point
> about going to power save state and stops the tx queue.
>
> However one (still unresolved) issue is that the code does not wait for the
> appropriate ACK from the access point after notifying the new power state.
>
> Any thoughts or comments?
This doesn't play well at all with hardware assisted scan as far as I
can tell.
johannes