Signed-off-by: Paul Stewart <[email protected]>
Signed-off-by: Felix Fietkau <[email protected]>
---
net/mac80211/mlme.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 36b7ea3..7e24c3e 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -2051,6 +2051,7 @@ void ieee80211_sta_restart(struct ieee80211_sub_if_data *sdata)
add_timer(&ifmgd->timer);
if (test_and_clear_bit(TMR_RUNNING_CHANSW, &ifmgd->timers_running))
add_timer(&ifmgd->chswitch_timer);
+ ieee80211_sta_reset_beacon_monitor(sdata);
}
#endif
--
1.7.3.2
On 2010-11-19 10:55 PM, Felix Fietkau wrote:
> Waiting for 500 ms after sending a probe request seems a bit excessive,
> especially when doing 5 attempts. If the connection is bad enough to make
> multiple requests time out, then user space should try to quickly find a
> new AP.
Hmm, don't merge this patch yet, it can cause background scans to
trigger reconnects.
- Felix
On Sat, Nov 20, 2010 at 8:09 AM, Felix Fietkau <[email protected]> wrote:
> On 2010-11-19 10:55 PM, Felix Fietkau wrote:
>> Waiting for 500 ms after sending a probe request seems a bit excessive,
>> especially when doing 5 attempts. If the connection is bad enough to make
>> multiple requests time out, then user space should try to quickly find a
>> new AP.
This might improve fail over roaming to a small extent but as per the
commit id d1c5091f23fed5195271e2849f89017d3a126521 it was mentioned
this might affect robustness against 'slow AP's'
> Hmm, don't merge this patch yet, it can cause background scans to
> trigger reconnects.
>
I am not sure how this affects background scan.bgscan will be enabled
even before the beacon loss and it is based on RSSI(please correct me
if I am wrong).
> - Felix
> --
> 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
>
On 11/19/2010 01:55 PM, Felix Fietkau wrote:
> Waiting for 500 ms after sending a probe request seems a bit excessive,
> especially when doing 5 attempts. If the connection is bad enough to make
> multiple requests time out, then user space should try to quickly find a
> new AP.
>
> Signed-off-by: Paul Stewart<[email protected]>
> Signed-off-by: Felix Fietkau<[email protected]>
> ---
> net/mac80211/mlme.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
> index ae99c0b..a64bb92 100644
> --- a/net/mac80211/mlme.c
> +++ b/net/mac80211/mlme.c
> @@ -51,7 +51,7 @@
> * a probe request because of beacon loss or for
> * checking the connection still works.
> */
> -#define IEEE80211_PROBE_WAIT (HZ / 2)
> +#define IEEE80211_PROBE_WAIT (HZ / 5)
Maybe make this a sysfs (or procfs) tunable?
Ben
--
Ben Greear <[email protected]>
Candela Technologies Inc http://www.candelatech.com
Check the connection by probing the AP (either using nullfunc or a
probe request). If nullfunc probing is supported and the assoc is no
longer valid, the AP will send a disassoc/deauth immediately.
Signed-off-by: Felix Fietkau <[email protected]>
---
net/mac80211/mlme.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -2068,6 +2068,7 @@ void ieee80211_sta_restart(struct ieee80211_sub_if_data *sdata)
if (test_and_clear_bit(TMR_RUNNING_CHANSW, &ifmgd->timers_running))
add_timer(&ifmgd->chswitch_timer);
ieee80211_sta_reset_beacon_monitor(sdata);
+ ieee80211_restart_sta_timer(sdata);
}
#endif
On 2010-11-22 7:49 AM, Mohammed Shafi wrote:
> On Sat, Nov 20, 2010 at 8:09 AM, Felix Fietkau <[email protected]> wrote:
>> On 2010-11-19 10:55 PM, Felix Fietkau wrote:
>>> Waiting for 500 ms after sending a probe request seems a bit excessive,
>>> especially when doing 5 attempts. If the connection is bad enough to make
>>> multiple requests time out, then user space should try to quickly find a
>>> new AP.
> This might improve fail over roaming to a small extent but as per the
> commit id d1c5091f23fed5195271e2849f89017d3a126521 it was mentioned
> this might affect robustness against 'slow AP's'
>
>> Hmm, don't merge this patch yet, it can cause background scans to
>> trigger reconnects.
>>
> I am not sure how this affects background scan.bgscan will be enabled
> even before the beacon loss and it is based on RSSI(please correct me
> if I am wrong).
I'm not sure either, this showed up in my tests. I'm pretty sure that
this change is not the root cause, but I don't want to see it merged
until the cause is figured out. My guess is that it's related to the
issues with the nullfunc probe request patch that Paul pointed out.
I'll do some more testing after I've fixed that one.
- Felix
Waiting for 500 ms after sending a probe request seems a bit excessive,
especially when doing 5 attempts. If the connection is bad enough to make
multiple requests time out, then user space should try to quickly find a
new AP.
Signed-off-by: Paul Stewart <[email protected]>
Signed-off-by: Felix Fietkau <[email protected]>
---
net/mac80211/mlme.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index ae99c0b..a64bb92 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -51,7 +51,7 @@
* a probe request because of beacon loss or for
* checking the connection still works.
*/
-#define IEEE80211_PROBE_WAIT (HZ / 2)
+#define IEEE80211_PROBE_WAIT (HZ / 5)
/*
* Weight given to the latest Beacon frame when calculating average signal
--
1.7.3.2
Send a nullfunc packet on resume as a fast probe of whether we're still
associated to the AP. If the association expired, the AP will send a
disassoc/deauth, allowing the station to reconnect immediately.
Signed-off-by: Nathan Williams <[email protected]>
Signed-off-by: Felix Fietkau <[email protected]>
---
net/mac80211/mlme.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index f2b414b..ae99c0b 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -2060,6 +2060,7 @@ void ieee80211_sta_restart(struct ieee80211_sub_if_data *sdata)
if (test_and_clear_bit(TMR_RUNNING_CHANSW, &ifmgd->timers_running))
add_timer(&ifmgd->chswitch_timer);
ieee80211_sta_reset_beacon_monitor(sdata);
+ ieee80211_send_nullfunc(sdata->local, sdata, 0);
}
#endif
--
1.7.3.2
Instead of using a fixed 2 second timeout, calculate beacon loss interval
from the advertised beacon interval and a frame count. With this beacon
loss happens after N (default 7) consecutive frames are missed which
for a typical setup (100TU beacon interval) is ~700ms (or ~1/3 previous).
Signed-off-by: Sam Leffler <[email protected]>
Signed-off-by: Felix Fietkau <[email protected]>
---
net/mac80211/ieee80211_i.h | 1 +
net/mac80211/mlme.c | 16 ++++++++++++----
2 files changed, 13 insertions(+), 4 deletions(-)
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index 7bb9a62..5bc0745 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -349,6 +349,7 @@ struct ieee80211_if_managed {
struct work_struct chswitch_work;
struct work_struct beacon_connection_loss_work;
+ unsigned long beacon_timeout;
unsigned long probe_timeout;
int probe_send_count;
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 7e24c3e..f2b414b 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -32,10 +32,15 @@
#define IEEE80211_MAX_PROBE_TRIES 5
/*
- * beacon loss detection timeout
- * XXX: should depend on beacon interval
+ * Beacon loss timeout is calculated as N frames times the
+ * advertised beacon interval. This may need to be somewhat
+ * higher than what hardware might detect to account for
+ * delays in the host processing frames. But since we also
+ * probe on beacon miss before declaring the connection lost
+ * default to what we want.
*/
-#define IEEE80211_BEACON_LOSS_TIME (2 * HZ)
+#define IEEE80211_BEACON_LOSS_COUNT 7
+
/*
* Time the connection can be idle before we probe
* it to see if we can still talk to the AP.
@@ -122,7 +127,7 @@ void ieee80211_sta_reset_beacon_monitor(struct ieee80211_sub_if_data *sdata)
return;
mod_timer(&sdata->u.mgd.bcn_mon_timer,
- round_jiffies_up(jiffies + IEEE80211_BEACON_LOSS_TIME));
+ round_jiffies_up(jiffies + sdata->u.mgd.beacon_timeout));
}
void ieee80211_sta_reset_conn_monitor(struct ieee80211_sub_if_data *sdata)
@@ -872,6 +877,9 @@ static void ieee80211_set_associated(struct ieee80211_sub_if_data *sdata,
bss_info_changed |= ieee80211_handle_bss_capability(sdata,
cbss->capability, bss->has_erp_value, bss->erp_value);
+ sdata->u.mgd.beacon_timeout = usecs_to_jiffies(ieee80211_tu_to_usec(
+ IEEE80211_BEACON_LOSS_COUNT * bss_conf->beacon_int));
+
sdata->u.mgd.associated = cbss;
memcpy(sdata->u.mgd.bssid, cbss->bssid, ETH_ALEN);
--
1.7.3.2
On Mon, Nov 22, 2010 at 03:41:23PM +0100, Felix Fietkau wrote:
> On 2010-11-22 7:49 AM, Mohammed Shafi wrote:
> > On Sat, Nov 20, 2010 at 8:09 AM, Felix Fietkau <[email protected]> wrote:
> >> On 2010-11-19 10:55 PM, Felix Fietkau wrote:
> >>> Waiting for 500 ms after sending a probe request seems a bit excessive,
> >>> especially when doing 5 attempts. If the connection is bad enough to make
> >>> multiple requests time out, then user space should try to quickly find a
> >>> new AP.
> > This might improve fail over roaming to a small extent but as per the
> > commit id d1c5091f23fed5195271e2849f89017d3a126521 it was mentioned
> > this might affect robustness against 'slow AP's'
> >
> >> Hmm, don't merge this patch yet, it can cause background scans to
> >> trigger reconnects.
> >>
> > I am not sure how this affects background scan.bgscan will be enabled
> > even before the beacon loss and it is based on RSSI(please correct me
> > if I am wrong).
> I'm not sure either, this showed up in my tests. I'm pretty sure that
> this change is not the root cause, but I don't want to see it merged
> until the cause is figured out. My guess is that it's related to the
> issues with the nullfunc probe request patch that Paul pointed out.
> I'll do some more testing after I've fixed that one.
I'm dropping this from my queue -- please repost if you decide it
is warranted.
John
--
John W. Linville Someday the world will need a hero, and you
[email protected] might be all we have. Be ready.