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

[Johannes Berg]

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.  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