[ To be clear, I haven't asked for this debugfs knob, and as of now, there is no plan for Chrome OS to use $subject feature. Per some of Tony's descriptions, I suppose maybe this would be useful for certain debugging scenarios, but only that -- no intention of wiring this up "in production." IIUC, he CC'd me only because of the "measuring the TX power" portion of the commit message. ] On Fri, Mar 20, 2020 at 6:06 AM Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: > Brian can probably comment on this - I think ChromeOS (used to) use(s) > some kind of fixed rate at the beginning of the connection to force low > rates? But I also remember this interacting badly with some APs that > just don't want to enable low rates at all... Regarding how Chrome OS used NL80211_CMD_SET_TX_BITRATE_MASK: we used to use this during authentication, association, DHCP, etc., until we determined the connection was "established" -- the goal was to enforce low (and ostensibly "more reliable") bitrates initially, so we get the important stuff done, even in the presence of wacky rate control algorithms. I understand this was actually added years ago mainly because ath9k had poor rate control. Notably, this feature applies (or, is supposed to apply) to both management and data frames. As Johannes noted, masking off these rates caused problems of its own, especially when APs (esp., guided by (mis?)guided I.T. admins who think that low bitrates are evil) removed these low bitrates from their SupportedRates field. Apparently these APs may start to reject clients if they don't obey. Additionally, we found no evidence that forcing low bitrates like this was substantially helpful for anything other than older ath9k systems. So longer story shorter, Chrome OS does not use NL80211_CMD_SET_TX_BITRATE_MASK any more. One is free to improve/extend the NL80211_CMD_SET_TX_BITRATE_MASK command if desired, of course, but I think some of the earlier complaints are valid (and line up with some of the problems I note above): the use case for $subject does not necessarily involve setting rates for management frames -- only data. One could always add extra options to this command to reflect all the different ways this might get used, but I'm not sure if that's worth it, for a feature that has no non-debug use case. One could also argue that, if iwlwifi already has a debugfs knob (looks like rs_sta_dbgfs_scale_table_write()?), rtw88 should be able to have one too ;) Regards, Brian
