On 6/18/2025 5:05 PM, Johannes Berg wrote:
On Wed, 2025-06-18 at 16:55 +0530, Rameshkumar Sundaram wrote:
I think it might make more sense for _mesh_ to do this, and honestly
mesh probably doesn't have much 6 GHz language in the spec anyway? I
didn't check now.
Guess mesh is defined for 6 GHz as well,
26.17.2 HE BSS operation in the 6 GHz band
A mesh STA with dot11HE6GOptionImplemented equal to true and operating
in the 6 GHz band is a 6 GHz mesh STA.
OK fair :)
I don't see why multi-radio would behave differently, sure, something
else could be occupying the 6 GHz band but that's also true for a "non-
multi-radio design", after all that doesn't mean it doesn't have
multiple radios, it just manages them differently.
That makes sense, thanks for the explanation, but is there a reason we
should include the 6 GHz band capabilities element even-though the link
STA/ mesh BSS that is going to send the beacon/assoc req frames is
operating in a lower band (say 5GHz) ?
It's probably not useful in a *beacon*, I guess?
Does this help in discovery of any out of band capabilities ? Just
trying to understand how this is useful.
With current implementation, an ML STA negotiating 5 GHz and 6 GHz links
with an ML AP would send HE 6 GHz Band capabilities element in both the
links as part of association request.
There was, afaik, some discussion here in the spec asking explicitly to
have it included if the STA is 6 GHz capable, but don't ask me why.
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.
Thanks for the detailed explanation.
But does that make sense for beacons? Not really?
Feel like it doesn't. Shall i make this patch to restrict this only for
mesh beacons ?
--
Ramesh
