[PATCH] Disable high bitrates for WPA negotiations

[Christopher Wiley]

On Wed, Jan 23, 2013 at 12:08 PM, Felix Fietkau <nbd at openwrt.org> wrote:

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

I don't really think this is such a zero-sum game.  We're hardening
wpa_supplicant against a class of hard to reproduce errors and using an
existing kernel interface in a straightforward way.

If we're going to speculate about hypothetical bugs in other modules, we
should also speculate about bugs in other rate control modules.  This
particular sort of rate control bug is difficult because it is a hard to
reproduce corner case that snags an otherwise acceptable optimization: be
optimistic about rates and count on backoff to correct for errors.  I don't
really think its a bad idea for distributions to work around a driver bug
that has been known (even just on this list) for over a year.  That this
has gone on this long says a lot about the subtlety of this kind of bug.

I can't say I'm familiar with how rate control is done, but suppose I did
want to go in and write up a patch.  What files and functions would I start
looking at and poking to make an appropriate change?

Christopher Wiley
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.shmoo.com/pipermail/hostap/attachments/20130129/717d4f53/attachment.htm