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

[Ben Greear]

On 10/12/2015 09:30 AM, Jouni Malinen wrote:
> On Tue, Oct 06, 2015 at 11:30:56AM -0700, Ben Greear wrote:
>> On 10/06/2015 11:08 AM, Jouni Malinen wrote:
>>> 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/
>
>> 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.
>
> Please let me know once the relevant cfg80211 and/or mac80211 changes
> are in upstream. Whenever submitting hostapd or wpa_supplicant changes
> that depends on pending kernel changes, it would be good to note that
> clearly with the submission.

I'll let you know, and try to do a better job of letting you know
the kernel dependencies in the future.

>> 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.
>
> I'm not sure I understand your use case. I can see use for being able to
> make a VHT or HT capable device looks like 802.11a/g-only, so that part
> was clear. However, I was expecting the driver_param to do that for all
> operations and not just TX rate or some of the Probe Request frame
> contents.

That is my goal as well.  But, various kernel stack and driver limitations
were exposed in my testing.  I think my current code mostly gets the
rate IEs right, at least..but possibly I am still missing some things.

And, Johanne's feedback is that I need to do it a bit differently anyway.

I think basically I need to allow setting the ratemask that determines IEs
with a different API than normal rate-ctrl logic so that one can still set
rate-ctrl to '6Mbps' but not suddenly break probe requests because supported
rates are not included.

My current thinking is to duplicate the code I already added to
hostap so that I can set the tx-rate mask AND also set the advertised-tx-rates mask.
This will in turn require a new kernel API to allow setting advertised-tx-rates.
These advertised rates would affect IEs and such.  The tx-rate mask would just
affect the tx rate control logic, not IEs.

> If you want some independent configuration parameters, I'd suggest
> discussing that with detailed design or at least describing the expected
> behavior clearly in the commit message. I don't really want to make this
> overly complex, though, so I would need to the use case better to be
> able to support this..
>
> All APs are supposed to reject association if the station does not
> support all of the basic rates. That's a requirement in the standard..
> Setting fixed TX rate is different from making the device drop its VHT
> or HT capabilities. I'm myself more interested in disabling all signs of
> VHT and HT capability, but if you have a use case for fixing TX rate
> without affecting HT/VHT capabilities, I guess that could be doable. I'm
> not convinced that driver_param is the way to go for that, though.

I agree the driver_param was a bit of a hack.  I do need the logic there
very early, so if not driver_param, then I guess just adding a new
driver API call with better typed arguments is the way to go?

And, from what I remember, hostap APs and the 4.2 kernel will associate
stations that do not support all of the basic rates.  I will double-check
this when I re-do the patches to support tx-rate vs advertised-tx-rates.

Thanks,
Ben

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