> On 20. Jun 2025, at 11.39, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: > > On Thu, 2025-06-19 at 19:35 +0530, Rameshkumar Sundaram wrote: >>> >>> Now that I look at it again though, it says for both beacon and probe - >>> _request_ to include it when dot11HEOptionImplemented and >>> dot11HE6GOptionImplemented are (both) true... We always though, with >>> some discussions with Cisco IIRC, that we should then always include it >>> even on the other bands for probe requests etc. > Not sure? I guess what I'm starting to think is that if the language is > all the same across all the frames and says to include it "when > dot11HEOptionImplemented and dot11HE6GOptionImplemented are true", but > the beacon clearly doesn't make sense - is that a bug in the spec for > the beacon, or does it mean your patch is actually correct also for the > client? > > Jouni, maybe you have some spec interpretation opinion? :) Unfortunately, this is yet another example of why dot11*Implemented variables are a bad idea.. No one knows whether these are really about something being capable of being enabled somehow and under what constraints vs. something being activated currently. It should be noted that before EHT (Wi-Fi 7) and the MLD concept, the STA was really only operating on a single channel and these capabilities of operating on a specific band are normally really applicable only when the single channel at that very point in time (e.g., when transmitting a frame on that channel) being within that band, For an AP, this is kind of clear, i.e., if the AP is operating on a 2.4 or 5 GHz channel, dot11HE6GOptionImplemented is actually false even if the device containing that standard-defined-entity-AP happens to incorporate other possible standard-defined-entity-APs that would be capable of operating (and might even operate currently) on the 6 GHz channel. As such, I would interpret the AP cases in a manner that the HE 6 GHz Band Capabilities element would be included only in frames transmitted on the 6 GHz band. There are similar cases like the TVHT Operation element and dot11TVHTOptionImplemented. The non-AP STA case is somewhat more confusing with the language talking about being capable of operating on the 6 GHz band and what could happen during a scan, so I’m not sure what to say about Probe Request frames, but my current implementation would be the same even for that case, i.e., no HE 6 GHz Band Capabilities element in Probe Request frames transmitted on the 2.4 or 5 GHz bands. (Re)Association Request frames would be somewhat clearer by being on the operating channel and that would seem more logically bound to a specific single band. All that said, it should also be noted that many people working on IEEE 802.11 amendments do not really fully appreciate the details in this area and whether the original intent was really what the text now says is a separate question.. In this particular case, though, the definition of the HE 6 GHz Band Capabilities element in Clause 9 is quite clearly limiting it to cases where “operating in the 6 GHz band” which would seem to back my interpretation: this element is included only in frames transmitted on the 6 GHz band. (Some openness for more flexible interpretation might be needed to cover cases where Management frames are tunneled through a different link in some multi-band cases where the frame targeting a STA operating on the 6 GHz band might actually be transmitted over-the-air on the 2.4 or 5 GHz band.) - Jouni
