[PATCH] Disable high bitrates for WPA negotiations
wiley at chromium.org
Fri Jan 18 15:02:00 EST 2013
On Fri, Jan 18, 2013 at 10:05 AM, Ben Greear <greearb at candelatech.com>wrote:
> 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 <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
>> This is intended to facilitate staying at low bitrates all the way
>> through DHCP negotiations and other one time initial connection
>> steps. Some setup processes, like WPA negotiation, can time out
>> the system rate control algorithm has a chance to wind down to
>> 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.
>> Ben Greear <greearb at candelatech.com <mailto:greearb at candelatech.**com<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.
> Ben Greear <greearb at candelatech.com>
> Candela Technologies Inc http://www.candelatech.com
I think that the HT_OVERRIDES logic plays pretty well with this patch.
That logic disables rates by clearing bits in the supported MCS rates set,
while keeping the mask at a default of all enabled. This patch disables
rates by clearing bits in the mask, while not touching the set of supported
rates. 11n is disabled completely by clearing some bits in a capabilities
field, rather than clearing the mask. Have I missed anything?
On the other hand, it's true that the patch stomps on the 11b rate
disabling. I'll handle that.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the HostAP