On Tue, 2025-09-09 at 19:19 -0400, Jeff Isaacs wrote: > Ok yeah I should have included a bit more info to begin with. First, I will > defend my assertion, then I will give more details on the motivation behind > this patch. :) I'll point out first that this area is actually rather complex because nobody is actually implementing QoS as written in the spec, but rather WMM as documented by the relevant WFA spec, and then assumes it satisfies the QoS requirements in the 802.11 spec (e.g. for HT/... STAs) > [snip] Sure, a 6G STA is a QoS STA. That doesn't mean a 6G AP STA is exempt from actually announcing the QoS parameters. > So the current logic in mac80211 to downgrade to legacy in absence of > the WMM IE is flawed when the beacon is captured on 6 GHz, because > any STA operating in 6 GHz must be at least implement HE and all of its > required features. It isn't: we internally first downgrade to legacy (because all of HT and higher require QoS/WMM) and then don't connect because HE is required and we cannot connect as a non-HE STA on 6 GHz. > One more supporting item from the spec. > > 802.11-2020 §10.2.3.2 - > "The QoS AP shall announce the EDCA parameters in selected Beacon > frames and in all Probe Response and (Re)Association Response frames > by the inclusion of the EDCA Parameter Set element using the information > from the MIB entries in dot11EDCATable. If no such element has been > received (e.g., prior to association in an infrastructure BSS), a non-AP > QoS STA shall use the default values for the parameters." > > So it is explicitly stated that it is possible that a beacon frame can be > received from a QoS AP without the EDCA parameters included. And > since a non-AP STA cannot initiate a probe request with a wildcard for > the SSID in 6 GHz, it has no choice but to use the default parameter > values outlined in the spec until the QoS AP instructs otherwise. Here in some way the difference between WMM and QoS becomes relevant, but even if we read this as WMM==QoS, I'm not sure I agree. I suppose this is an interpretation matter, but "[t]he QoS AP shall" already _requires_ the QoS AP to include that element. Any deviation from that makes it non-compliant, and there's not much of an assumption on STA behaviour from that point on. The example in the "If not such element has been received [...]" sentence to me at least implies that these are not meant to be cases where the AP misbehaves if it doesn't include it (which is already established by the first sentence), but is meant for the cases where there's no QoS AP that controlled the parameters, "e.g., prior to association in an infrastructure BSS", or also perhaps when associating to a non-QoS infrastructure BSS, or similar cases. > Now for my motivation for introducing this patch. I have observed that the > WMM element is not present in beacon frames in the 6 GHz spectrum on > the Ruckus R770 when multiple BSSs are packed together using the > MBSSID feature. The WMM IE is included in the top-level profile, but not > in the non-Tx profiles defined within the MBSSID element. This is a pretty common AP bug around element inheritance [1]. They assume that it's inherited from the transmitting BSS, which is not true. Actually, this is precisely _because_ of the difference between WMM and QoS. If it were QoS elements, it _would_ be inherited, because all elements are inherited unless overwritten in the specific profile. Since it's WMM carried in a vendor element, any other vendor element overrides the inheritance. Therefore, either _none_ or _all_ (intended) vendor elements including WMM must be included in each non-transmitting profile. [1] Sometimes in MBSSID non-transmitting profiles, sometimes in multi- link profiles, sometimes maybe even both. > I am in contact > with support, but the initial response I got from Ruckus is that this is > intentional. They're wrong, and even the language you quoted above makes that crystal clear, as does the WMM spec [2]. We've (indirectly) actually discussed this with Ruckus, and they have in fact acknowledged that this is a bug in the AP and that they will fix it. [2] though that never talks about MBSSID (I think) so you have to read a whole bunch of cross-spec text wrt. inheritance etc. > And well it makes sense I guess. If the spec defines default values, and > the whole point behind MBSSID is to save airtime for data transmission, > then why repeat the same unchanged default QoS values for every BSS. No, see all the discussion above. The default values (in the BSS case) are for when you're connecting to a non-QoS AP and pre-association use cases etc. > I also figured that they had to go through a lot to get the WiFi 7 > certification. If this is truly an error, I would be surprised if I'm > the first to notice it, given that the R770 shipped out beginning in 2023 :) They cannot pass certification with this bug, but it's possible that either they started including more vendor elements since, or changed the configuration in other ways, or the specific MBSSID configuration isn't tested in the certification, etc. But this _is_ validated as part of the certification, if the scenario arises. > So I dug through the spec, and ended up with this chain of reasoning for > why the WMM IE is not required in 6 GHz. ... but it's still wrong since it's a clear *shall* requirement. I hope I've been able to convey that. Right now, as annoying that may be for you, I'm inclined to not change anything here since multiple AP vendors confronted with this issue have agreed that it's their issue and will be fixed. If we work around it now, they have no incentive to fix their implementation. We have a bit of market power here to push in the right direction, rather than piling on workarounds on our side. However, if in fact it later turns out that there are unfixable APs out there, then given the reasoning I outlined above for how your argumentation is wrong, I think the only plausible workaround would be to (erroneously!) inherit the vendor WMM element from the transmitting BSS, rather than making assumptions about it. We'd also have to do this for change tracking which makes it all the more complex, and certainly wouldn't want to apply it in strict mode. johannes
