How to disable /b and /a/g rates?

[Ben Greear]

On 03/10/2015 01:35 PM, Johannes Berg wrote:
> On Tue, 2015-03-10 at 13:19 -0700, Ben Greear wrote:
> 
>> I think I don't know enough about basic rates and supported rates,
>> and I am probably using the terms all wrong.
> 
> :)
> 
> For the purpose of this discussion, I think we can use these
> definitions:
> 
> supported rates = rates that the AP supports
> basic rates = subset thereof that all the clients must support
> mandatory rates = subset thereof (*) that all implementations must
> support
> 
> (*) if the AP is compliant anyway
> 
>> What I mean is that I was hoping that I could get the AP to use
>> HT rates as it's very slowest rate (ie, beacon at HT-MCS0 or something
>> like that).
> 
> Right, but that's actually orthogonal. That'd be more the question
> "which rate(s) do I actually use".

Ok.  In case it helps others, this hostapd config below seems to let hostapd
generate a proper beacon with no /b rates advertised or
supported on 2.4Ghz, but at least with ath10k, the beacon still goes out
at 1Mbps rate.

...
supported_rates=60 90 120 180 240 360 480 540
basic_rates=60, 120, 240
...


I think I found the main problem with what I am trying to
accomplish:

ath10k/mac.c only supports setting a single fixed rate,
(see ath10k_bitrate_mask_correct()).

So, even if hostapd was trying to clear out the /b rates, it
cannot work (and neither can iw).

I guess it's time to go poke at firmware and see if there
are any back-door hacks to disable just a subset of rates.

Thanks,
Ben


> 
>> Ok.  You think it would also be non-compliant to just disable
>> the /b rates on 2.4Ghz (and leave the /g rates as supported)?
> 
> Yes - see the list I posted earlier in this thread.
> 
>> /b (and all other devices) must already interoperate with non wifi
>> devices such as baby monitors and such, right?
>>
>> So, wouldn't that sort of work the same as an AP that was beaconing
>> with a modulation that the device couldn't understand?
> 
> Well, I guess that'd work to some extent, but I'd expect it to be far
> more efficient and reliable if the devices all know how much airtime
> they're using and can calculate the NAV.
> 
>> For that matter, the /b device is already not going to understand
>> the vast majority of the traffic even if the beacons them selves
>> are running at minimal rates?
> 
> ERP devices will understand the PLCP, so even if they cannot read the
> data that was transmitted they'll know there's a wifi frame on the air.
> HR/DSSS (Clause 17, what you call "/b") devices will not even understand
> that, but if their presence is detected then it may be required by
> others to send CTS-to-self or similar protection, IIRC.
> 
> johannes
> 


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