On 8/11/2023 5:08 PM, Johannes Berg wrote:
On Fri, 2023-08-11 at 17:05 +0800, Wen Gong wrote:
On 8/11/2023 5:03 PM, Johannes Berg wrote:
On Fri, 2023-08-11 at 11:51 +0800, Wen Gong wrote:
Now there are many nl80211_band such as NL80211_BAND_2GHZ/
NL80211_BAND_5GHZ/NL80211_BAND_6GHZ... In the same interface, if some bands
support EML, and other bands not support EML, then how to handler this
case?
But ... these are MLD capabilities, not of the (associated) STA?
Yes, I know it.
Then you can't honestly be suggesting we move "MLD capa and ops" into
per-band, no?
I know it just now after I send the suggestion😁
So not sure how that would make sense? What would you even _do_ with
that?
I think another change is not move "u16 eml_capabilities", and only add
a new
field "u16 eml_supp_bands" together with the "u16 eml_capabilities", the
eml_supp_bands is filled with the bit map of enum nl80211_band. Is that OK?
And again, what would you do with it? Not advertise EML when you have
selected links that are not in the map? And if the links change
dynamically in the future? You'd probably need a bunch of validation for
that.
For example, for station, NOT support EML on 2 GHz, support EML on 5
GHz/6 GHz.
When connect to 2/3 links AP, then EML should NOT add in assoc req while
connect
to AP which is 2 GHz+5 GHz or 2 GHz+6 GHz or 2 GHz+5 GHz+6 GHz.
EML should add in assoc req while connect to AP which is 5 GHz+6 GHz.
For dynamic link change, it is another new topic, so I have not good advise
for that.😁
And usually you'd probably always connect to all the bands?
I really don't get it.
Sometimes AP is 3 links (2 GHz+5 GHz+6 GHz), but station only support 2
links,
then station will not connect all bands, station need choose 2 bands to
connect.
Btw this is all client - so your client implementation can just not send
the EML action frame (forgot the name right now) when the currently
active links are not compatible.
I guess you are refer to "EML Operating Mode Notification frame".
johannes
