On Mon, 2017-09-11 at 11:49 +0200, Benjamin Beichler wrote: > I don't know what is the problem with the details. The only flag, > which is a bit to verbose is MAC80211_HWSIM_TX_RC_DUP_DATA, which we > may omit. All others describe directly terms used in the IEEE 802.11 > standard. Also the representation, that a rate is an MCS-index is > quite good. If you take look here http://mcsindex.com/ , the bitrate > would be not sufficient to get the exact coding and fec rate, > therefore you would also need additional flags. You are right > regarding legacy rates, which are in an encoded table. I tried to > decouple internal and external API, but currently there is no big > difference. Yeah, I was just concerned that maybe this API was too tightly coupled to mac80211, but I guess it should be fine. > Nonetheless the whole hwsim API is highly specialized and only usable > with the linux kernel. Of course the Userland API should be more or > less stable, but the backward compatibility is not touched by this > change. As I already said, this is nearly a fix for hwsim, since > currently it's impossible to differentiate between legacy and MCS- > rates, although they could appear in a single tx_rates array. I think > currently minstrel does not mix HT and legacy rates for data frames, > but AFAIK Management/Action frames are always sent with legacy rates, > so there are mixed already. Ok. johannes
