[PATCH 1/4] mac80211: restart beacon miss timer on system resume from suspend

[PATCH 1/4] mac80211: restart beacon miss timer on system resume from suspend

[Felix Fietkau]

Signed-off-by: Paul Stewart <pstew@google.com>
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
---
 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

[PATCH 2/4] mac80211: calculate beacon loss time accurately

[Felix Fietkau]

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 <sleffler@chromium.org>
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
---
 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

[PATCH 3/4] mac80211: probe the AP when resuming

[Felix Fietkau]

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 <njw@google.com>
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
---
 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

[PATCH 4/4] mac80211: reduce the probe response timeout after beacon loss

[Felix Fietkau]

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 <pstew@google.com>
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
---
 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

Re: [PATCH 4/4] mac80211: reduce the probe response timeout after beacon loss

[Ben Greear]

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<pstew@google.com>
> Signed-off-by: Felix Fietkau<nbd@openwrt.org>
> ---
>   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 <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: [PATCH 4/4] mac80211: reduce the probe response timeout after beacon loss

[Felix Fietkau]

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

Re: [PATCH 4/4] mac80211: reduce the probe response timeout after beacon loss

[Mohammed Shafi]

On Sat, Nov 20, 2010 at 8:09 AM, Felix Fietkau <nbd@openwrt.org> 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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: [PATCH 4/4] mac80211: reduce the probe response timeout after beacon loss

[Felix Fietkau]

On 2010-11-22 7:49 AM, Mohammed Shafi wrote:
> On Sat, Nov 20, 2010 at 8:09 AM, Felix Fietkau <nbd@openwrt.org> 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

[ath9k-devel] [PATCH 4/4] mac80211: reduce the probe response timeout after beacon loss

[Mohammed Shafi]

On Mon, Nov 22, 2010 at 8:38 PM, Mohammed Shafi
<shafi.wireless@gmail.com> wrote:
> On Mon, Nov 22, 2010 at 8:11 PM, Felix Fietkau <nbd@openwrt.org> wrote:
>> On 2010-11-22 7:49 AM, Mohammed Shafi wrote:
>>> On Sat, Nov 20, 2010 at 8:09 AM, Felix Fietkau <nbd@openwrt.org> 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.
>>
>
> Ok.
>> - Felix
>>
>

[PATCH v2 3/4] mac80211: probe the AP when resuming

[Felix Fietkau]

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 <nbd@openwrt.org>
---
 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
  

Re: [PATCH 4/4] mac80211: reduce the probe response timeout after beacon loss

[John W. Linville]

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 <nbd@openwrt.org> 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
linville@tuxdriver.com			might be all we have.  Be ready.