[PATCH] CHROMIUMOS: mac80211: Increase retry attempts for nullfunc probes

[PATCH] CHROMIUMOS: mac80211: Increase retry attempts for nullfunc probes

[Gary Morain]

When a nullfunc probe fails for lack of an ACK, it is retried
almost immediately.  The current setting of 2 retries completes
in about 4 ms.  If an AP is off-channel scanning, this is not
enough time for the AP to return to the operating channel and
ACK the nullfunc.  As a result, the client disconnects when the
AP is still there and operating.

Signed-off-by: Gary Morain <gmorain@chromium.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 dbd4bd9..dd1d901 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -36,7 +36,7 @@
 #define IEEE80211_ASSOC_TIMEOUT (HZ / 5)
 #define IEEE80211_ASSOC_MAX_TRIES 3
 
-static int max_nullfunc_tries = 2;
+static int max_nullfunc_tries = 100;
 module_param(max_nullfunc_tries, int, 0644);
 MODULE_PARM_DESC(max_nullfunc_tries,
 		 "Maximum nullfunc tx tries before disconnecting (reason 4).");
-- 
1.7.7.3

Re: [PATCH] CHROMIUMOS: mac80211: Increase retry attempts for nullfunc probes

[Johannes Berg]

On Fri, 2012-05-18 at 13:49 -0700, Gary Morain wrote:
> When a nullfunc probe fails for lack of an ACK, it is retried
> almost immediately.  The current setting of 2 retries completes
> in about 4 ms.  If an AP is off-channel scanning, this is not
> enough time for the AP to return to the operating channel and
> ACK the nullfunc.  As a result, the client disconnects when the
> AP is still there and operating.

AP is off-channel, scanning? It can't be unless it's a GO and then you
have GO powersave, right?

> -static int max_nullfunc_tries = 2;
> +static int max_nullfunc_tries = 100;

100? That seems insanely high compared to the other one.

johannes

[PATCH] CHROMIUMOS: mac80211: Increase retry attempts for nullfunc probes

[Gary Morain]

[resending in plan text]

On Mon, May 21, 2012 at 12:26 PM, Johannes Berg <johannes@sipsolutions.net>
wrote:
>
> On Fri, 2012-05-18 at 13:49 -0700, Gary Morain wrote:
> > When a nullfunc probe fails for lack of an ACK, it is retried
> > almost immediately.  The current setting of 2 retries completes
> > in about 4 ms.  If an AP is off-channel scanning, this is not
> > enough time for the AP to return to the operating channel and
> > ACK the nullfunc.  As a result, the client disconnects when the
> > AP is still there and operating.
>
> AP is off-channel, scanning? It can't be unless it's a GO and then you
> have GO powersave, right?

Scenario:
1.  Client connects to a managed AP.
2.  Client goes off-channel to scan for APs.
3.  AP goes off-channel to scan for rogue APs.  The client misses any
signaling the AP may have sent.
4.  The client returns to its home channel before the AP does.
5.  The client immediately probes the AP with a nullfunc.
(ieee80211_mlme_notify_scan_completed()).
6.  The AP does not respond to the nullfunc because it is off-channel.
7.  The client retries the nullfunc, which also does not get an ACK, and the
client disconnects from the AP (ieee80211_sta_work).

It's worth noticing that the client never detects beacon loss because the AP
is not off-channel long enough to miss sending multiple beacons.


>
>
> > -static int max_nullfunc_tries = 2;
> > +static int max_nullfunc_tries = 100;
>
> 100? That seems insanely high compared to the other one.


100 retries take about 200 ms.  In my testing, the range of time that the AP
was off-channel after the client returned home ranged from 20 to 104 ms.  I
did a test with the retry set to 50, but it was too low some of the time.
 100 gives plenty of headroom.

>
>
> johannes
>

[PATCH] CHROMIUMOS: mac80211: Increase retry attempts for nullfunc probes

[Sujith Manoharan]

Gary Morain wrote:
> Scenario:
> 1.  Client connects to a managed AP.
> 2.  Client goes off-channel to scan for APs.
> 3.  AP goes off-channel to scan for rogue APs.  The client misses any
> signaling the AP may have sent.
> 4.  The client returns to its home channel before the AP does.
> 5.  The client immediately probes the AP with a nullfunc.
> (ieee80211_mlme_notify_scan_completed()).
> 6.  The AP does not respond to the nullfunc because it is off-channel.
> 7.  The client retries the nullfunc, which also does not get an ACK, and the
> client disconnects from the AP (ieee80211_sta_work).
> 
> It's worth noticing that the client never detects beacon loss because the AP
> is not off-channel long enough to miss sending multiple beacons.

If this is with ath9k, there is a much more fundamental issue - the HW beacon
timers are never re-programmed with the correct values, which can be done only
after a TSF sync.

The sequence is like this:

* ath9k associates to an AP
* A scan is started on the station side.
* The HW is reset as part of the scan.
* The scan completes.
* ath9k sets the BSSID and configures beacon timers - but,
  without waiting for the HW TSF sync, so the timers
  end up being programmed incorrectly.

This is with wireless-testing.

Sujith