On 6/16/2025 2:32 PM, Johannes Berg wrote:
On Wed, 2025-06-11 at 09:59 +0530, Rameshkumar Sundaram wrote:
While this might be appropriate for a multi-band wiphy (i.e., a single
radio capable of operating on both 5 GHz and 6 GHz), it may not be
suitable for a multi-radio wiphy where each band is handled by a
separate radio. In such cases, the Mesh BSS could be running on the 5
GHz radio, which does not inherently support 6 GHz capabilities.
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.
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) ?
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.
--
Ramesh