[PATCH] nl80211: Allow configuring allowable legacy rate mask.

[Ben Greear]

On 10/06/2015 11:08 AM, Jouni Malinen wrote:
> On Tue, Sep 15, 2015 at 08:04:45PM -0400, greearb at candelatech.com wrote:
>> With this, we should be able to disable un-wanted rates
>> early in the association process, before 'iw' could
>> have a chance to make any settings.
>
> I cleaned up this patch and the following 3 patchset a bit and the
> latest snapshot from my work branch is here:
> http://w1.fi/p/nl80211-rates/
>
> This needs some more testing. See patch 5/5 for mac80211_hwsim test
> cases that would need more work to use tshark to check the TX rate and
> supported rates elements; something similar is needed for P2P cases
> (disable 11b) to check for regressions.
>
> One unexpected part I saw was in how this works with association or to
> be more exact, how this does not work at all with association.. Or well,
> the actual TX rate of the frame does change, but supported rates
> elements did not. Was that on purpose? It is certainly quite confusing
> to the user, i.e., I would have expected this to be a global rate mask
> that would apply for all operations on the interface.
>
> I could not get ht_disable=1 vht_disable=1 to work. Was that supposed to
> remove HT Capabilities from Probe Request frames? Please note that I had
> to remove VHT rate set from the 2.4 GHz band to prevent cfg80211 from
> rejecting the full command as invalid. Anyway, the HT capabilities show
> up on 2.4 GHz band even when using ht_disable=1 driver parameter.

I also had to make some changes to the linux kernel to make this work properly,
and for ath10k, down in the ath10k driver and firmware as well.  Upstream ath10k firmware probably
will never add the needed support, but my firmware & kernel does appear to work with this properly
now.

Kernel patches are here, I think everything is in the top 18 patches
...you could ignore the ath10k part, and notice I had
a few fixup patches..these would need cleanup before being acceptable upstream:

http://dmz2.candelatech.com/git/gitweb.cgi?p=linux-4.2.dev.y/.git;a=shortlog

I'd be perfectly fine with you submitting any of that upstream, and I'll
post them myself as soon as I find time to clean it up if no one beats me
to it.

In general, this concept may need some more improvement as well.  Maybe
a way to configure the rates in the probe/assoc requests independently of fixing
transmit rates.  I'm not too sure either way on that, but some APs will forbid
association if you don't support all of the basic rateset, so it would be impossible
to use my kernel patches at the hostap patches to fully set a fixed rate of 6Mbps
in that case.  Maybe that is a feature, maybe a bug...I guess it depends on the
use-case.

Thanks,
Ben

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