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

Johannes Berg johannes
Tue Mar 10 13:35:52 PDT 2015

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

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

(*) 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.  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.


More information about the Hostap mailing list