All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] mac80211:  Make some mlme timers module paramaters.
@ 2011-02-04 23:30 greearb
  2011-02-14 12:12 ` Johannes Berg
  0 siblings, 1 reply; 4+ messages in thread
From: greearb @ 2011-02-04 23:30 UTC (permalink / raw)
  To: linux-wireless; +Cc: Ben Greear

From: Ben Greear <greearb@candelatech.com>

This allows users to tune the connection-loss algorithms
to be more or less lenient.  In particular, larger
null-func retries helps when using lots of virtual
stations on a loaded network.

Signed-off-by: Ben Greear <greearb@candelatech.com>
---
:100644 100644 e059b3a... f77adf1... M	net/mac80211/mlme.c
 net/mac80211/mlme.c |   34 +++++++++++++++++++++++-----------
 1 files changed, 23 insertions(+), 11 deletions(-)

diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index e059b3a..f77adf1 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -28,8 +28,15 @@
 #include "rate.h"
 #include "led.h"
 
-#define IEEE80211_MAX_NULLFUNC_TRIES 2
-#define IEEE80211_MAX_PROBE_TRIES 5
+static int max_nullfunc_tries = 2;
+module_param(max_nullfunc_tries, int, 0644);
+MODULE_PARM_DESC(max_nullfunc_tries,
+		 "Maximum nullfunc tx tries before disconnecting (reason 4).");
+
+static int max_probe_tries = 5;
+module_param(max_probe_tries, int, 0644);
+MODULE_PARM_DESC(max_probe_tries,
+		 "Maximum probe tries before disconnecting (reason 4).");
 
 /*
  * Beacon loss timeout is calculated as N frames times the
@@ -51,7 +58,11 @@
  * a probe request because of beacon loss or for
  * checking the connection still works.
  */
-#define IEEE80211_PROBE_WAIT		(HZ / 2)
+static int probe_wait_ms = 500;
+module_param(probe_wait_ms, int, 0644);
+MODULE_PARM_DESC(probe_wait_ms,
+		 "Maximum time(ms) to wait for probe response"
+		 " before disconnecting (reason 4).");
 
 /*
  * Weight given to the latest Beacon frame when calculating average signal
@@ -1116,7 +1127,7 @@ static void ieee80211_mgd_probe_ap_send(struct ieee80211_sub_if_data *sdata)
 	struct ieee80211_if_managed *ifmgd = &sdata->u.mgd;
 	const u8 *ssid;
 	u8 *dst = ifmgd->associated->bssid;
-	u8 unicast_limit = max(1, IEEE80211_MAX_PROBE_TRIES - 3);
+	u8 unicast_limit = max(1, max_probe_tries - 3);
 
 	/*
 	 * Try sending broadcast probe requests for the last three
@@ -1142,7 +1153,7 @@ static void ieee80211_mgd_probe_ap_send(struct ieee80211_sub_if_data *sdata)
 	}
 
 	ifmgd->probe_send_count++;
-	ifmgd->probe_timeout = jiffies + IEEE80211_PROBE_WAIT;
+	ifmgd->probe_timeout = jiffies + msecs_to_jiffies(probe_wait_ms);
 	run_again(ifmgd, ifmgd->probe_timeout);
 }
 
@@ -1243,7 +1254,8 @@ static void __ieee80211_connection_loss(struct ieee80211_sub_if_data *sdata)
 
 	memcpy(bssid, ifmgd->associated->bssid, ETH_ALEN);
 
-	printk(KERN_DEBUG "Connection to AP %pM lost.\n", bssid);
+	printk(KERN_DEBUG "%s: Connection to AP %pM lost.\n",
+	       sdata->name, bssid);
 
 	ieee80211_set_disassoc(sdata, true, true);
 	mutex_unlock(&ifmgd->mtx);
@@ -1988,9 +2000,9 @@ void ieee80211_sta_work(struct ieee80211_sub_if_data *sdata)
 		memcpy(bssid, ifmgd->associated->bssid, ETH_ALEN);
 
 		if (local->hw.flags & IEEE80211_HW_REPORTS_TX_ACK_STATUS)
-			max_tries = IEEE80211_MAX_NULLFUNC_TRIES;
+			max_tries = max_nullfunc_tries;
 		else
-			max_tries = IEEE80211_MAX_PROBE_TRIES;
+			max_tries = max_probe_tries;
 
 		/* ACK received for nullfunc probing frame */
 		if (!ifmgd->probe_send_count)
@@ -2022,7 +2034,7 @@ void ieee80211_sta_work(struct ieee80211_sub_if_data *sdata)
 				    "%s: Failed to send nullfunc to AP %pM"
 				    " after %dms, disconnecting.\n",
 				    sdata->name,
-				    bssid, (1000 * IEEE80211_PROBE_WAIT)/HZ);
+				    bssid, probe_wait_ms);
 #endif
 			ieee80211_sta_connection_lost(sdata, bssid);
 		} else if (ifmgd->probe_send_count < max_tries) {
@@ -2031,7 +2043,7 @@ void ieee80211_sta_work(struct ieee80211_sub_if_data *sdata)
 				    "%s: No probe response from AP %pM"
 				    " after %dms, try %d/%i\n",
 				    sdata->name,
-				    bssid, (1000 * IEEE80211_PROBE_WAIT)/HZ,
+				    bssid, probe_wait_ms,
 				    ifmgd->probe_send_count, max_tries);
 #endif
 			ieee80211_mgd_probe_ap_send(sdata);
@@ -2044,7 +2056,7 @@ void ieee80211_sta_work(struct ieee80211_sub_if_data *sdata)
 				    "%s: No probe response from AP %pM"
 				    " after %dms, disconnecting.\n",
 				    sdata->name,
-				    bssid, (1000 * IEEE80211_PROBE_WAIT)/HZ);
+				    bssid, probe_wait_ms);
 
 			ieee80211_sta_connection_lost(sdata, bssid);
 		}
-- 
1.7.2.3


^ permalink raw reply related	[flat|nested] 4+ messages in thread

* Re: [PATCH] mac80211:  Make some mlme timers module paramaters.
  2011-02-04 23:30 [PATCH] mac80211: Make some mlme timers module paramaters greearb
@ 2011-02-14 12:12 ` Johannes Berg
  2011-02-14 15:34   ` Ben Greear
  0 siblings, 1 reply; 4+ messages in thread
From: Johannes Berg @ 2011-02-14 12:12 UTC (permalink / raw)
  To: greearb; +Cc: linux-wireless, John Linville

On Fri, 2011-02-04 at 15:30 -0800, greearb@candelatech.com wrote:
> From: Ben Greear <greearb@candelatech.com>
> 
> This allows users to tune the connection-loss algorithms
> to be more or less lenient.  In particular, larger
> null-func retries helps when using lots of virtual
> stations on a loaded network.

I see this has been merged, but I really think it should be reverted. It
doesn't really fix anything, and it makes the behaviour less
predictable. Also, even on a loaded network the nullfunc frames should
be transmitted quickly as they go out on VO. I'm thinking the fact that
it doesn't will also affect other things -- like the bufferbloat
discussion -- and fixing the problem would be a much better idea.

johannes

> Signed-off-by: Ben Greear <greearb@candelatech.com>
> ---
> :100644 100644 e059b3a... f77adf1... M	net/mac80211/mlme.c
>  net/mac80211/mlme.c |   34 +++++++++++++++++++++++-----------
>  1 files changed, 23 insertions(+), 11 deletions(-)
> 
> diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
> index e059b3a..f77adf1 100644
> --- a/net/mac80211/mlme.c
> +++ b/net/mac80211/mlme.c
> @@ -28,8 +28,15 @@
>  #include "rate.h"
>  #include "led.h"
>  
> -#define IEEE80211_MAX_NULLFUNC_TRIES 2
> -#define IEEE80211_MAX_PROBE_TRIES 5
> +static int max_nullfunc_tries = 2;
> +module_param(max_nullfunc_tries, int, 0644);
> +MODULE_PARM_DESC(max_nullfunc_tries,
> +		 "Maximum nullfunc tx tries before disconnecting (reason 4).");
> +
> +static int max_probe_tries = 5;
> +module_param(max_probe_tries, int, 0644);
> +MODULE_PARM_DESC(max_probe_tries,
> +		 "Maximum probe tries before disconnecting (reason 4).");
>  
>  /*
>   * Beacon loss timeout is calculated as N frames times the
> @@ -51,7 +58,11 @@
>   * a probe request because of beacon loss or for
>   * checking the connection still works.
>   */
> -#define IEEE80211_PROBE_WAIT		(HZ / 2)
> +static int probe_wait_ms = 500;
> +module_param(probe_wait_ms, int, 0644);
> +MODULE_PARM_DESC(probe_wait_ms,
> +		 "Maximum time(ms) to wait for probe response"
> +		 " before disconnecting (reason 4).");
>  
>  /*
>   * Weight given to the latest Beacon frame when calculating average signal
> @@ -1116,7 +1127,7 @@ static void ieee80211_mgd_probe_ap_send(struct ieee80211_sub_if_data *sdata)
>  	struct ieee80211_if_managed *ifmgd = &sdata->u.mgd;
>  	const u8 *ssid;
>  	u8 *dst = ifmgd->associated->bssid;
> -	u8 unicast_limit = max(1, IEEE80211_MAX_PROBE_TRIES - 3);
> +	u8 unicast_limit = max(1, max_probe_tries - 3);
>  
>  	/*
>  	 * Try sending broadcast probe requests for the last three
> @@ -1142,7 +1153,7 @@ static void ieee80211_mgd_probe_ap_send(struct ieee80211_sub_if_data *sdata)
>  	}
>  
>  	ifmgd->probe_send_count++;
> -	ifmgd->probe_timeout = jiffies + IEEE80211_PROBE_WAIT;
> +	ifmgd->probe_timeout = jiffies + msecs_to_jiffies(probe_wait_ms);
>  	run_again(ifmgd, ifmgd->probe_timeout);
>  }
>  
> @@ -1243,7 +1254,8 @@ static void __ieee80211_connection_loss(struct ieee80211_sub_if_data *sdata)
>  
>  	memcpy(bssid, ifmgd->associated->bssid, ETH_ALEN);
>  
> -	printk(KERN_DEBUG "Connection to AP %pM lost.\n", bssid);
> +	printk(KERN_DEBUG "%s: Connection to AP %pM lost.\n",
> +	       sdata->name, bssid);
>  
>  	ieee80211_set_disassoc(sdata, true, true);
>  	mutex_unlock(&ifmgd->mtx);
> @@ -1988,9 +2000,9 @@ void ieee80211_sta_work(struct ieee80211_sub_if_data *sdata)
>  		memcpy(bssid, ifmgd->associated->bssid, ETH_ALEN);
>  
>  		if (local->hw.flags & IEEE80211_HW_REPORTS_TX_ACK_STATUS)
> -			max_tries = IEEE80211_MAX_NULLFUNC_TRIES;
> +			max_tries = max_nullfunc_tries;
>  		else
> -			max_tries = IEEE80211_MAX_PROBE_TRIES;
> +			max_tries = max_probe_tries;
>  
>  		/* ACK received for nullfunc probing frame */
>  		if (!ifmgd->probe_send_count)
> @@ -2022,7 +2034,7 @@ void ieee80211_sta_work(struct ieee80211_sub_if_data *sdata)
>  				    "%s: Failed to send nullfunc to AP %pM"
>  				    " after %dms, disconnecting.\n",
>  				    sdata->name,
> -				    bssid, (1000 * IEEE80211_PROBE_WAIT)/HZ);
> +				    bssid, probe_wait_ms);
>  #endif
>  			ieee80211_sta_connection_lost(sdata, bssid);
>  		} else if (ifmgd->probe_send_count < max_tries) {
> @@ -2031,7 +2043,7 @@ void ieee80211_sta_work(struct ieee80211_sub_if_data *sdata)
>  				    "%s: No probe response from AP %pM"
>  				    " after %dms, try %d/%i\n",
>  				    sdata->name,
> -				    bssid, (1000 * IEEE80211_PROBE_WAIT)/HZ,
> +				    bssid, probe_wait_ms,
>  				    ifmgd->probe_send_count, max_tries);
>  #endif
>  			ieee80211_mgd_probe_ap_send(sdata);
> @@ -2044,7 +2056,7 @@ void ieee80211_sta_work(struct ieee80211_sub_if_data *sdata)
>  				    "%s: No probe response from AP %pM"
>  				    " after %dms, disconnecting.\n",
>  				    sdata->name,
> -				    bssid, (1000 * IEEE80211_PROBE_WAIT)/HZ);
> +				    bssid, probe_wait_ms);
>  
>  			ieee80211_sta_connection_lost(sdata, bssid);
>  		}



^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] mac80211:  Make some mlme timers module paramaters.
  2011-02-14 12:12 ` Johannes Berg
@ 2011-02-14 15:34   ` Ben Greear
  2011-02-14 17:06     ` Sam Leffler
  0 siblings, 1 reply; 4+ messages in thread
From: Ben Greear @ 2011-02-14 15:34 UTC (permalink / raw)
  To: Johannes Berg; +Cc: linux-wireless, John Linville

On 02/14/2011 04:12 AM, Johannes Berg wrote:
> On Fri, 2011-02-04 at 15:30 -0800, greearb@candelatech.com wrote:
>> From: Ben Greear<greearb@candelatech.com>
>>
>> This allows users to tune the connection-loss algorithms
>> to be more or less lenient.  In particular, larger
>> null-func retries helps when using lots of virtual
>> stations on a loaded network.
>
> I see this has been merged, but I really think it should be reverted. It
> doesn't really fix anything, and it makes the behaviour less
> predictable. Also, even on a loaded network the nullfunc frames should
> be transmitted quickly as they go out on VO. I'm thinking the fact that
> it doesn't will also affect other things -- like the bufferbloat
> discussion -- and fixing the problem would be a much better idea.

The defaults stay the same, and allowing the values to be set a bit larger
lets 128 stations associate, where without this, they constantly fail the
null-func retries counter.

Imagine 128 stations all trying to associate and auth WPA at the
same time, and start DHCP and some IPv6 auto-negotiation
as soon as they are up...  That is quite a lot of packets
for a bunch of timing-sensitive operations.

I know my particular use is pretty strange, but surely I'm not
the only one that would like a good way to stress-test APs.

I can also imagine that other users might like their system even more
trigger happy..perhaps that would speed up roaming in some cases.
Or users on very poor/congested networks, flakey APs, etc.

The default values seem to be chosen arbitrarily to work for most
users most of the time.  I think it adds way more benefit to allow
these easily changed than any harm that comes from giving users
the option.

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] mac80211: Make some mlme timers module paramaters.
  2011-02-14 15:34   ` Ben Greear
@ 2011-02-14 17:06     ` Sam Leffler
  0 siblings, 0 replies; 4+ messages in thread
From: Sam Leffler @ 2011-02-14 17:06 UTC (permalink / raw)
  To: Ben Greear; +Cc: Johannes Berg, linux-wireless, John Linville

On Mon, Feb 14, 2011 at 7:34 AM, Ben Greear <greearb@candelatech.com> wrote:
> On 02/14/2011 04:12 AM, Johannes Berg wrote:
>>
>> On Fri, 2011-02-04 at 15:30 -0800, greearb@candelatech.com wrote:
>>>
>>> From: Ben Greear<greearb@candelatech.com>
>>>
>>> This allows users to tune the connection-loss algorithms
>>> to be more or less lenient.  In particular, larger
>>> null-func retries helps when using lots of virtual
>>> stations on a loaded network.
>>
>> I see this has been merged, but I really think it should be reverted. It
>> doesn't really fix anything, and it makes the behaviour less
>> predictable. Also, even on a loaded network the nullfunc frames should
>> be transmitted quickly as they go out on VO. I'm thinking the fact that
>> it doesn't will also affect other things -- like the bufferbloat
>> discussion -- and fixing the problem would be a much better idea.
>
> The defaults stay the same, and allowing the values to be set a bit larger
> lets 128 stations associate, where without this, they constantly fail the
> null-func retries counter.
>
> Imagine 128 stations all trying to associate and auth WPA at the
> same time, and start DHCP and some IPv6 auto-negotiation
> as soon as they are up...  That is quite a lot of packets
> for a bunch of timing-sensitive operations.
>
> I know my particular use is pretty strange, but surely I'm not
> the only one that would like a good way to stress-test APs.
>
> I can also imagine that other users might like their system even more
> trigger happy..perhaps that would speed up roaming in some cases.
> Or users on very poor/congested networks, flakey APs, etc.
>
> The default values seem to be chosen arbitrarily to work for most
> users most of the time.  I think it adds way more benefit to allow
> these easily changed than any harm that comes from giving users
> the option.

We default MAX_NULLFUNC_TRIES to 1.  By the time you disconnect you've
missed at least 7 consecutive beacon frames (nominally 700 TU) and the
1 NullData frame (nominal 7 tx attempts).  I have _rarely_ seen trying
multiple times succeed.  Increasing tries requires spacing them out
which significantly increases roaming time which is user visible.
Also in most cases the event generated may cause wpa_supplicant to
re-join the same AP after a scan (depends on whether your supplicant
code blacklist's the ap and/or you have other options).

Thus having the module parameter means I can set my desired parameters
w/o having local mods.

-Sam

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2011-02-14 17:06 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-02-04 23:30 [PATCH] mac80211: Make some mlme timers module paramaters greearb
2011-02-14 12:12 ` Johannes Berg
2011-02-14 15:34   ` Ben Greear
2011-02-14 17:06     ` Sam Leffler

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.