At one point, you could set a single rate using 'iw' and ath10k would convert that to a special firmware API that fixed all data traffic to a particular rate set. (Management frames and broadcast will not be affected by setting the rates when using ath10k).
But, with the commit below, a command like this will fail: #iw dev vap206 set bitrates legacy-5 ht-mcs-5 0 vht-mcs-5 command failed: Invalid argument (-22) But, it actually *does* successfully set the rate in the driver first, which is confusing at best. So, I think we should relax this check, at least for ath10k. commit e8e4f5280ddd0a7b43a795f90a0758e3c99df6a6 Author: Johannes Berg <[email protected]> Date: Wed Mar 8 11:12:10 2017 +0100 mac80211: reject/clear user rate mask if not usable If the user rate mask results in no (basic) rates being usable, clear it. Also, if we're already operating when it's set, reject it instead. Technically, selecting basic rates as the criterion is a bit too restrictive, but calculating the usable rates over all stations (e.g. in AP mode) is harder, and all stations must support the basic rates. Similarly, in client mode, the basic rates will be used anyway for control frames. This fixes the "no supported rates (...) in rate_mask ..." warning that occurs on TX when you've selected a rate mask that's not compatible with the connection (e.g. an AP that enables only the rates 36, 48, 54 and you've selected only 6, 9, 12.) Reported-by: Kirtika Ruchandani <[email protected]> Signed-off-by: Johannes Berg <[email protected]> Thanks, Ben -- Ben Greear <[email protected]> Candela Technologies Inc http://www.candelatech.com _______________________________________________ ath10k mailing list [email protected] http://lists.infradead.org/mailman/listinfo/ath10k
