[PATCH] Disable high bitrates for WPA negotiations

[Ben Greear]

On 01/18/2013 09:43 AM, Christopher Wiley wrote:
> On Thu, Jan 17, 2013 at 12:13 PM, Ben Greear <greearb at candelatech.com <mailto:greearb at candelatech.com>> wrote:
>
>     On 01/17/2013 11:56 AM, 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.
>
>
>     Maybe add a CLI command or similar to re-enable the high
>     rates for those not interested in using dbus?
>
>     Also, it looks like this steps on any previous available-rates
>     selection logic in supplicant?  It would be nice if this
>     code took the configured rate settings into account,
>     having the logic in this patch never enable rates
>     previously disabled.
>
>
>     Thanks,
>     Ben
>
>     --
>     Ben Greear <greearb at candelatech.com <mailto:greearb at candelatech.com>>
>     Candela Technologies Inc http://www.candelatech.com
>
>
> The CLI seems like a good idea.  I'll put up another CL that includes it.
>
> It is true that setting the bitrate mask ignores past masks.  What do you mean by previously disabled rates?  Are you referring to the bits disabling 802.11b rates?

It is possible to configure the available rates, including limiting the MCS rates to low values (including just MCS1).

It is also possible to disable /n rates entirely..I didn't read your code carefully enough to determine
if it conflicts with that or not.

I think your code should take the configured available rates/bands/protocols into account and never go outside those bounds,
and I don't think your previous patch quite did this.

Thanks,
Ben


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