Patchwork [001/002,MAC80211] Retry probe request few times

login
register
mail settings
Submitter Maxim Levitsky
Date July 31, 2009, 4:14 p.m.
Message ID <1249056896.20593.3.camel@maxim-laptop>
Download mbox | patch
Permalink /patch/38530/
State Not Applicable, archived
Headers show

Comments

Maxim Levitsky - July 31, 2009, 4:14 p.m.
>From 0bf5749f2878f9245b8fb1b64456386374205225 Mon Sep 17 00:00:00 2001
From: Maxim Levitsky <maximlevitsky@gmail.com>
Date: Fri, 31 Jul 2009 18:54:12 +0300
Subject: [PATCH] [MAC80211] Retry probe request few times

Retry 5 times  (chosen arbitary ), before assuming
that station is out of range.

Fixes frequent disassociations while connected to weak,
and sometimes even strong access points.

Signed-off-by: Maxim Levitky <maximlevitsky@gmail.com>
---
 net/mac80211/ieee80211_i.h |    1 +
 net/mac80211/mlme.c        |   42 ++++++++++++++++++++++++++++++------------
 2 files changed, 31 insertions(+), 12 deletions(-)
Johannes Berg - July 31, 2009, 4:21 p.m.
On Fri, 2009-07-31 at 19:14 +0300, Maxim Levitsky wrote:
> >From 0bf5749f2878f9245b8fb1b64456386374205225 Mon Sep 17 00:00:00 2001
> From: Maxim Levitsky <maximlevitsky@gmail.com>
> Date: Fri, 31 Jul 2009 18:54:12 +0300
> Subject: [PATCH] [MAC80211] Retry probe request few times
> 
> Retry 5 times  (chosen arbitary ), before assuming
> that station is out of range.
> 
> Fixes frequent disassociations while connected to weak,
> and sometimes even strong access points.

Looks good, thanks.

Acked-by: Johannes Berg <johannes@sipsolutions.net>

> Signed-off-by: Maxim Levitky <maximlevitsky@gmail.com>
> ---
>  net/mac80211/ieee80211_i.h |    1 +
>  net/mac80211/mlme.c        |   42 ++++++++++++++++++++++++++++++------------
>  2 files changed, 31 insertions(+), 12 deletions(-)
> 
> diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
> index aec6853..bca7b60 100644
> --- a/net/mac80211/ieee80211_i.h
> +++ b/net/mac80211/ieee80211_i.h
> @@ -280,6 +280,7 @@ struct ieee80211_if_managed {
>  	struct work_struct beacon_loss_work;
>  
>  	unsigned long probe_timeout;
> +	int probe_send_count;
>  
>  	struct mutex mtx;
>  	struct ieee80211_bss *associated;
> diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
> index ee83125..1d8640a 100644
> --- a/net/mac80211/mlme.c
> +++ b/net/mac80211/mlme.c
> @@ -31,6 +31,7 @@
>  #define IEEE80211_AUTH_MAX_TRIES 3
>  #define IEEE80211_ASSOC_TIMEOUT (HZ / 5)
>  #define IEEE80211_ASSOC_MAX_TRIES 3
> +#define IEEE80211_MAX_PROBE_TRIES 5
>  
>  /*
>   * beacon loss detection timeout
> @@ -1156,11 +1157,24 @@ void ieee80211_sta_rx_notify(struct ieee80211_sub_if_data *sdata,
>  		  round_jiffies_up(jiffies + IEEE80211_CONNECTION_IDLE_TIME));
>  }
>  
> +static void ieee80211_mgd_probe_ap_send(struct ieee80211_sub_if_data *sdata)
> +{
> +	struct ieee80211_if_managed *ifmgd = &sdata->u.mgd;
> +	const u8 *ssid;
> +
> +	ssid = ieee80211_bss_get_ie(&ifmgd->associated->cbss, WLAN_EID_SSID);
> +	ieee80211_send_probe_req(sdata, ifmgd->associated->cbss.bssid,
> +				 ssid + 2, ssid[1], NULL, 0);
> +
> +	ifmgd->probe_send_count++;
> +	ifmgd->probe_timeout = jiffies + IEEE80211_PROBE_WAIT;
> +	run_again(ifmgd, ifmgd->probe_timeout);
> +}
> +
>  static void ieee80211_mgd_probe_ap(struct ieee80211_sub_if_data *sdata,
>  				   bool beacon)
>  {
>  	struct ieee80211_if_managed *ifmgd = &sdata->u.mgd;
> -	const u8 *ssid;
>  	bool already = false;
>  
>  	if (!netif_running(sdata->dev))
> @@ -1203,18 +1217,12 @@ static void ieee80211_mgd_probe_ap(struct ieee80211_sub_if_data *sdata,
>  	if (already)
>  		goto out;
>  
> -	ifmgd->probe_timeout = jiffies + IEEE80211_PROBE_WAIT;
> -
>  	mutex_lock(&sdata->local->iflist_mtx);
>  	ieee80211_recalc_ps(sdata->local, -1);
>  	mutex_unlock(&sdata->local->iflist_mtx);
>  
> -	ssid = ieee80211_bss_get_ie(&ifmgd->associated->cbss, WLAN_EID_SSID);
> -	ieee80211_send_probe_req(sdata, ifmgd->associated->cbss.bssid,
> -				 ssid + 2, ssid[1], NULL, 0);
> -
> -	run_again(ifmgd, ifmgd->probe_timeout);
> -
> +	ifmgd->probe_send_count = 0;
> +	ieee80211_mgd_probe_ap_send(sdata);
>   out:
>  	mutex_unlock(&ifmgd->mtx);
>  }
> @@ -2072,17 +2080,27 @@ static void ieee80211_sta_work(struct work_struct *work)
>  	if (ifmgd->flags & (IEEE80211_STA_BEACON_POLL |
>  			    IEEE80211_STA_CONNECTION_POLL) &&
>  	    ifmgd->associated) {
> +		u8 bssid[ETH_ALEN];
> +
> +		memcpy(bssid, ifmgd->associated->cbss.bssid, ETH_ALEN);
>  		if (time_is_after_jiffies(ifmgd->probe_timeout))
>  			run_again(ifmgd, ifmgd->probe_timeout);
> -		else {
> -			u8 bssid[ETH_ALEN];
> +
> +		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,
> +				(1000 * IEEE80211_PROBE_WAIT)/HZ,
> +				ifmgd->probe_send_count);
> +#endif
> +			ieee80211_mgd_probe_ap_send(sdata);
> +		} else {
>  			/*
>  			 * We actually lost the connection ... or did we?
>  			 * Let's make sure!
>  			 */
>  			ifmgd->flags &= ~(IEEE80211_STA_CONNECTION_POLL |
>  					  IEEE80211_STA_BEACON_POLL);
> -			memcpy(bssid, ifmgd->associated->cbss.bssid, ETH_ALEN);
>  			printk(KERN_DEBUG "No probe response from AP %pM"
>  				" after %dms, disconnecting.\n",
>  				bssid, (1000 * IEEE80211_PROBE_WAIT)/HZ);
Marcel Holtmann - Aug. 5, 2009, 2:22 a.m.
Hi Maxim,

> From: Maxim Levitsky <maximlevitsky@gmail.com>
> Date: Fri, 31 Jul 2009 18:54:12 +0300
> Subject: [PATCH] [MAC80211] Retry probe request few times
> 
> Retry 5 times  (chosen arbitary ), before assuming
> that station is out of range.

so today I got the disconnect :(

[54632.657912] No probe response from AP 00:1c:f0:xx:xx:xx after 500ms, try 1
[54633.154560] No probe response from AP 00:1c:f0:xx:xx:xx after 500ms, try 2
[54873.231210] No probe response from AP 00:1c:f0:xx:xx:xx after 500ms, try 1
[55113.467840] No probe response from AP 00:1c:f0:xx:xx:xx after 500ms, try 1
[55113.964510] No probe response from AP 00:1c:f0:xx:xx:xx after 500ms, try 2
[55114.464516] No probe response from AP 00:1c:f0:xx:xx:xx after 500ms, try 3
[55114.967868] No probe response from AP 00:1c:f0:xx:xx:xx after 500ms, try 4
[55115.464511] No probe response from AP 00:1c:f0:xx:xx:xx after 500ms, disconnecting.

Should we increase the value to 8 or something? Or just accept that
sometimes we get a disconnect?

Regards

Marcel


--
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
Maxim Levitsky - Aug. 5, 2009, 5:29 a.m.
On Tue, 2009-08-04 at 19:22 -0700, Marcel Holtmann wrote:
> Hi Maxim,
> 
> > From: Maxim Levitsky <maximlevitsky@gmail.com>
> > Date: Fri, 31 Jul 2009 18:54:12 +0300
> > Subject: [PATCH] [MAC80211] Retry probe request few times
> > 
> > Retry 5 times  (chosen arbitary ), before assuming
> > that station is out of range.
> 
> so today I got the disconnect :(
> 
> [54632.657912] No probe response from AP 00:1c:f0:xx:xx:xx after 500ms, try 1
> [54633.154560] No probe response from AP 00:1c:f0:xx:xx:xx after 500ms, try 2
> [54873.231210] No probe response from AP 00:1c:f0:xx:xx:xx after 500ms, try 1
> [55113.467840] No probe response from AP 00:1c:f0:xx:xx:xx after 500ms, try 1
> [55113.964510] No probe response from AP 00:1c:f0:xx:xx:xx after 500ms, try 2
> [55114.464516] No probe response from AP 00:1c:f0:xx:xx:xx after 500ms, try 3
> [55114.967868] No probe response from AP 00:1c:f0:xx:xx:xx after 500ms, try 4
> [55115.464511] No probe response from AP 00:1c:f0:xx:xx:xx after 500ms, disconnecting.
> 
> Should we increase the value to 8 or something? Or just accept that
> sometimes we get a disconnect?
> 
I think a disconnect or two aren't a problem, they are always handled
automatically, and can be caused by natural events.

Even without these patches (I have WPA2, and disconnects were every 4
five seconds), and still it was possible to use network.

One disconnect in a day is really nothing to worry about (I have seen
such here as well)

You can increase try count, probably won't hurt much (each try is 0.5
seconds, so even 10 tries gives total of 5 seconds, before disconnect on
a really unaccessible AP, anyway)

Best regards,
	Maxim Levitsky

--
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
Johannes Berg - Aug. 5, 2009, 5:33 a.m.
On Wed, 2009-08-05 at 08:29 +0300, Maxim Levitsky wrote:

> > [54632.657912] No probe response from AP 00:1c:f0:xx:xx:xx after 500ms, try 1
> > [54633.154560] No probe response from AP 00:1c:f0:xx:xx:xx after 500ms, try 2
> > [54873.231210] No probe response from AP 00:1c:f0:xx:xx:xx after 500ms, try 1
> > [55113.467840] No probe response from AP 00:1c:f0:xx:xx:xx after 500ms, try 1
> > [55113.964510] No probe response from AP 00:1c:f0:xx:xx:xx after 500ms, try 2
> > [55114.464516] No probe response from AP 00:1c:f0:xx:xx:xx after 500ms, try 3
> > [55114.967868] No probe response from AP 00:1c:f0:xx:xx:xx after 500ms, try 4
> > [55115.464511] No probe response from AP 00:1c:f0:xx:xx:xx after 500ms, disconnecting.
> > 
> > Should we increase the value to 8 or something? Or just accept that
> > sometimes we get a disconnect?
> > 
> I think a disconnect or two aren't a problem, they are always handled
> automatically, and can be caused by natural events.
> 
> Even without these patches (I have WPA2, and disconnects were every 4
> five seconds), and still it was possible to use network.
> 
> One disconnect in a day is really nothing to worry about (I have seen
> such here as well)
> 
> You can increase try count, probably won't hurt much (each try is 0.5
> seconds, so even 10 tries gives total of 5 seconds, before disconnect on
> a really unaccessible AP, anyway)

Mind you, each try will end up sending a LOT of probe request frames,
iwlwifi sends like 12 frames for every try and never gets a response for
some reason, so I wouldn't really increase it much further since you'd
be spamming around a lot.

johannes
Gábor Stefanik - Aug. 5, 2009, 5:50 a.m.
On Wed, Aug 5, 2009 at 7:33 AM, Johannes Berg<johannes@sipsolutions.net> wrote:
> On Wed, 2009-08-05 at 08:29 +0300, Maxim Levitsky wrote:
>
>> > [54632.657912] No probe response from AP 00:1c:f0:xx:xx:xx after 500ms, try 1
>> > [54633.154560] No probe response from AP 00:1c:f0:xx:xx:xx after 500ms, try 2
>> > [54873.231210] No probe response from AP 00:1c:f0:xx:xx:xx after 500ms, try 1
>> > [55113.467840] No probe response from AP 00:1c:f0:xx:xx:xx after 500ms, try 1
>> > [55113.964510] No probe response from AP 00:1c:f0:xx:xx:xx after 500ms, try 2
>> > [55114.464516] No probe response from AP 00:1c:f0:xx:xx:xx after 500ms, try 3
>> > [55114.967868] No probe response from AP 00:1c:f0:xx:xx:xx after 500ms, try 4
>> > [55115.464511] No probe response from AP 00:1c:f0:xx:xx:xx after 500ms, disconnecting.
>> >
>> > Should we increase the value to 8 or something? Or just accept that
>> > sometimes we get a disconnect?
>> >
>> I think a disconnect or two aren't a problem, they are always handled
>> automatically, and can be caused by natural events.
>>
>> Even without these patches (I have WPA2, and disconnects were every 4
>> five seconds), and still it was possible to use network.
>>
>> One disconnect in a day is really nothing to worry about (I have seen
>> such here as well)
>>
>> You can increase try count, probably won't hurt much (each try is 0.5
>> seconds, so even 10 tries gives total of 5 seconds, before disconnect on
>> a really unaccessible AP, anyway)
>
> Mind you, each try will end up sending a LOT of probe request frames,
> iwlwifi sends like 12 frames for every try and never gets a response for
> some reason, so I wouldn't really increase it much further since you'd
> be spamming around a lot.
>
> johannes
>

My €0.02 (€ because I'm European :) ): Shouldn't probe requests be NO_ACK?
Johannes Berg - Aug. 5, 2009, 5:51 a.m.
On Wed, 2009-08-05 at 07:50 +0200, Gábor Stefanik wrote:

> My €0.02 (€ because I'm European :) ): Shouldn't probe requests be NO_ACK?

Of course not. What makes you think so?

johannes
Gábor Stefanik - Aug. 5, 2009, 5:53 a.m.
2009/8/5 Johannes Berg <johannes@sipsolutions.net>:
> On Wed, 2009-08-05 at 07:50 +0200, Gábor Stefanik wrote:
>
>> My €0.02 (€ because I'm European :) ): Shouldn't probe requests be NO_ACK?
>
> Of course not. What makes you think so?
>
> johannes
>
>

It just feels illogical to me that the AP essentially has to respond
to probes twice (it sends an ACK, then a probe response) - but if that
is what the 802.11 spec calls for, then its fine.
Johannes Berg - Aug. 5, 2009, 5:58 a.m.
On Wed, 2009-08-05 at 07:53 +0200, Gábor Stefanik wrote:

> It just feels illogical to me that the AP essentially has to respond
> to probes twice (it sends an ACK, then a probe response) - but if that
> is what the 802.11 spec calls for, then its fine.

You're just confused then. Think about it again, it's perfectly logical.

johannes
Marcel Holtmann - Aug. 5, 2009, 3:45 p.m.
Hi Maxim,

> > > From: Maxim Levitsky <maximlevitsky@gmail.com>
> > > Date: Fri, 31 Jul 2009 18:54:12 +0300
> > > Subject: [PATCH] [MAC80211] Retry probe request few times
> > > 
> > > Retry 5 times  (chosen arbitary ), before assuming
> > > that station is out of range.
> > 
> > so today I got the disconnect :(
> > 
> > [54632.657912] No probe response from AP 00:1c:f0:xx:xx:xx after 500ms, try 1
> > [54633.154560] No probe response from AP 00:1c:f0:xx:xx:xx after 500ms, try 2
> > [54873.231210] No probe response from AP 00:1c:f0:xx:xx:xx after 500ms, try 1
> > [55113.467840] No probe response from AP 00:1c:f0:xx:xx:xx after 500ms, try 1
> > [55113.964510] No probe response from AP 00:1c:f0:xx:xx:xx after 500ms, try 2
> > [55114.464516] No probe response from AP 00:1c:f0:xx:xx:xx after 500ms, try 3
> > [55114.967868] No probe response from AP 00:1c:f0:xx:xx:xx after 500ms, try 4
> > [55115.464511] No probe response from AP 00:1c:f0:xx:xx:xx after 500ms, disconnecting.
> > 
> > Should we increase the value to 8 or something? Or just accept that
> > sometimes we get a disconnect?
> > 
> I think a disconnect or two aren't a problem, they are always handled
> automatically, and can be caused by natural events.
> 
> Even without these patches (I have WPA2, and disconnects were every 4
> five seconds), and still it was possible to use network.

this assumption only works if you are not using NetworkManager or alike
where every new connect triggers DHCP again. If we wanna survive them,
then we have to teach them to handle the lease time more intelligent
which is kinda tricky. Might be worth doing anyway. I have to play with
it a little bit.

> One disconnect in a day is really nothing to worry about (I have seen
> such here as well)
> 
> You can increase try count, probably won't hurt much (each try is 0.5
> seconds, so even 10 tries gives total of 5 seconds, before disconnect on
> a really unaccessible AP, anyway)

Or just increase the try to 1 second. I still think there is something
odd going on with the iwlwifi driver here, but so far nobody saw
anything that is obviously wrong.

Regards

Marcel


--
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

Patch

diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index aec6853..bca7b60 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -280,6 +280,7 @@  struct ieee80211_if_managed {
 	struct work_struct beacon_loss_work;
 
 	unsigned long probe_timeout;
+	int probe_send_count;
 
 	struct mutex mtx;
 	struct ieee80211_bss *associated;
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index ee83125..1d8640a 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -31,6 +31,7 @@ 
 #define IEEE80211_AUTH_MAX_TRIES 3
 #define IEEE80211_ASSOC_TIMEOUT (HZ / 5)
 #define IEEE80211_ASSOC_MAX_TRIES 3
+#define IEEE80211_MAX_PROBE_TRIES 5
 
 /*
  * beacon loss detection timeout
@@ -1156,11 +1157,24 @@  void ieee80211_sta_rx_notify(struct ieee80211_sub_if_data *sdata,
 		  round_jiffies_up(jiffies + IEEE80211_CONNECTION_IDLE_TIME));
 }
 
+static void ieee80211_mgd_probe_ap_send(struct ieee80211_sub_if_data *sdata)
+{
+	struct ieee80211_if_managed *ifmgd = &sdata->u.mgd;
+	const u8 *ssid;
+
+	ssid = ieee80211_bss_get_ie(&ifmgd->associated->cbss, WLAN_EID_SSID);
+	ieee80211_send_probe_req(sdata, ifmgd->associated->cbss.bssid,
+				 ssid + 2, ssid[1], NULL, 0);
+
+	ifmgd->probe_send_count++;
+	ifmgd->probe_timeout = jiffies + IEEE80211_PROBE_WAIT;
+	run_again(ifmgd, ifmgd->probe_timeout);
+}
+
 static void ieee80211_mgd_probe_ap(struct ieee80211_sub_if_data *sdata,
 				   bool beacon)
 {
 	struct ieee80211_if_managed *ifmgd = &sdata->u.mgd;
-	const u8 *ssid;
 	bool already = false;
 
 	if (!netif_running(sdata->dev))
@@ -1203,18 +1217,12 @@  static void ieee80211_mgd_probe_ap(struct ieee80211_sub_if_data *sdata,
 	if (already)
 		goto out;
 
-	ifmgd->probe_timeout = jiffies + IEEE80211_PROBE_WAIT;
-
 	mutex_lock(&sdata->local->iflist_mtx);
 	ieee80211_recalc_ps(sdata->local, -1);
 	mutex_unlock(&sdata->local->iflist_mtx);
 
-	ssid = ieee80211_bss_get_ie(&ifmgd->associated->cbss, WLAN_EID_SSID);
-	ieee80211_send_probe_req(sdata, ifmgd->associated->cbss.bssid,
-				 ssid + 2, ssid[1], NULL, 0);
-
-	run_again(ifmgd, ifmgd->probe_timeout);
-
+	ifmgd->probe_send_count = 0;
+	ieee80211_mgd_probe_ap_send(sdata);
  out:
 	mutex_unlock(&ifmgd->mtx);
 }
@@ -2072,17 +2080,27 @@  static void ieee80211_sta_work(struct work_struct *work)
 	if (ifmgd->flags & (IEEE80211_STA_BEACON_POLL |
 			    IEEE80211_STA_CONNECTION_POLL) &&
 	    ifmgd->associated) {
+		u8 bssid[ETH_ALEN];
+
+		memcpy(bssid, ifmgd->associated->cbss.bssid, ETH_ALEN);
 		if (time_is_after_jiffies(ifmgd->probe_timeout))
 			run_again(ifmgd, ifmgd->probe_timeout);
-		else {
-			u8 bssid[ETH_ALEN];
+
+		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,
+				(1000 * IEEE80211_PROBE_WAIT)/HZ,
+				ifmgd->probe_send_count);
+#endif
+			ieee80211_mgd_probe_ap_send(sdata);
+		} else {
 			/*
 			 * We actually lost the connection ... or did we?
 			 * Let's make sure!
 			 */
 			ifmgd->flags &= ~(IEEE80211_STA_CONNECTION_POLL |
 					  IEEE80211_STA_BEACON_POLL);
-			memcpy(bssid, ifmgd->associated->cbss.bssid, ETH_ALEN);
 			printk(KERN_DEBUG "No probe response from AP %pM"
 				" after %dms, disconnecting.\n",
 				bssid, (1000 * IEEE80211_PROBE_WAIT)/HZ);