As part of adding 11n awareness to various parts of net80211 (TDMA,
802.11s code, implementing AMSDU, 11n+fast-frames support, TX rate
control) the PHY table code needs to be taught about said rates.
Unfortunately the PHY code as it stands only knows about non-11n
stuff. To add to the pain, the basic rate bit (0x80) is the same as
the MCS rate bit (0x80). They're supposed to not be used in
overlapping contexts but in some places (notable ni->tx_rate, for
example!) they are. In this code, the rate code -> table index code
makes the unfortunate mistake of also indexing things with the basic
rate bit set, which messes up MCS rates.
The "real" solution is to make the basic rate and mcs rate bits either
much higher bits, or to turn the rate representation into a struct
with the rate code / speed and PHY bits (eg, BASIC, MCS, etc). That's
a big change that touches a _lot_ of code so I'm not yet willing to go
and do all that work. It's likely I'm going to have to for 802.11ac
support however. Sniffle.
The "real real" solution is to not use this rate table index thing
outside of a very specific set of instances. I can unfortunately see a
million little race conditions here where the driver holds onto a rate
table index whilst doing something, whilst some other part of the code
decides to wholesale change said rate table underneath it. it's
terrifying; I may end up having to do a further pass and kill this
whole "use the rate table index" thing outside of contexts that I can
protect things with locks.
So, here's what I've done:
* Make the current PHY and rate table lookup routines non-11n only. If
the BASIC bit is set (0x80) then it panics.
* Add the 11n rates into the PHY tables
* Add some accessor methods to do the ratecode->rateindex lookup
rather than manually going grubbing around in ieee80211com.
* Modify callers of the ratecode->rateindex routines to strip the
basic bit if it's set. They all assume it's legacy at this point, so
I've tested this on ath (where it should be a no-op) and iwn (where it
does use the PHY table and rate control code.) So far, so good. I
haven't sat down and fully debugged whether populating the 11n rate
table with 11n rates is causing confusion in the iwn code - the iwn
code does some magic crap somewhere to "pretend" the rates are non-11n
when they indeed are, so the rate control code can do it's thing. i'd
obviously like to kill _that_.
The patch is here:
Please give it a whirl. It's only really going to show up if your
device uses the net80211 rate control code. As it patches ral and iwn,
I'm doubly interested in those devices.
I'd like to commit this in a couple of days and start working on
undoing the brain damage in iwn so the rate control modules can
actually do 11n rate table lookups.
firstname.lastname@example.org mailing list
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"