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

Jouni Malinen j at w1.fi
Mon Oct 12 12:30:39 EDT 2015


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.

> 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.
  
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.
 
-- 
Jouni Malinen                                            PGP id EFC895FA


More information about the HostAP mailing list