[PATCH] Disable high bitrates for WPA negotiations

[Felix Fietkau]

On 2013-01-23 8:40 PM, Christopher Wiley wrote:
> On Mon, Jan 21, 2013 at 4:10 AM, Felix Fietkau <nbd at openwrt.org
> <mailto:nbd at openwrt.org>> wrote:
> 
>     On 2013-01-17 8:56 PM, Christopher Wiley wrote:
>     > Temporarily disable "high" bitrates during association with a BSS.
>     >
>     > Users of wpa_supplicant can set disable_high_bitrates=1 in their
>     > interface config, which causes the driver to disable high bitrates on
>     > the interface during associations.  The user can then call over
>     DBus via
>     > EnableHighBitrates() to re-enable high bitrates at their discretion.
>     >
>     > This is intended to facilitate staying at low bitrates all the way
>     > through DHCP negotiations and other one time initial connection setup
>     > steps.  Some setup processes, like WPA negotiation, can time out
>     before
>     > the system rate control algorithm has a chance to wind down to sane
>     > rates.
>     >
>     > Signed-hostap: Christoper Wiley <wiley at chromium.org
>     <mailto:wiley at chromium.org>>
>     What driver / rate control algorithm are you using this workaround for?
>     Wouldn't it be better to fix the rate control module instead? Having a
>     rate control module start with high data rates and no proper fallback
>     this early seems like a bug or design flaw to me that should be
>     addressed properly instead of worked around with a patch like this.
> 
>     - Felix
> 
>  
> This was happening on an ath9k module using
> the ath9k_btcoex_rate_control algorithm on a 9462 part specifically.  It
> is true that this is not a real fix for the underlying problem (which
> will need to be in the driver).  This patch just converts the total
> breakage of not being able to connect at all to a brief period of poor
> connectivity after high rates are enabled as the rate control algorithm
> winds down.  However, I think it is valuable to allow distributions to
> work around rate control bugs in the various drivers they have to use on
> their respective platforms.
I'm not really convinced that it is a good idea to carry such
workarounds just in case other drivers might be broken as well.

I also think it would be a *really* bad idea for distributions to just
enable a hack like this by default, or even suggest it to users.
While it may indeed succeed in working around a particular kind of bug
in a stupid rate control module, it might as well trigger a different
kind of bug in a different module.

I strongly believe that adding complexity and bloat to codebases for
unnecessary workarounds is bad in the long run and should be avoided if
possible.

How about just changing the ath9k rate control to initialize its tables
in a way that it will start with lower rates and work its way up.
Shouldn't be too hard, the module itself is not very complex.

- Felix