On Wed, 2024-07-31 at 17:52 +0530, Sowmiya Sree Elavalagan wrote: > From: Rameshkumar Sundaram <quic_ramess@xxxxxxxxxxx> > > Current implementation of MBSSID configuration parsing mandates > MBSSID elements for Tx BSS (index 0). However with ML link addition > it is possible that Non-Tx BSS'es can be added at a later point in > time after Tx BSS is brought up. Hence allow bring up of MBSSID Tx > BSS even if no Non-Tx BSS are present at that time when EMA is > disabled. Later when new Non-TX BSS are added TX BSS beacon can be > updated with MBSSID Elements. So ... I've been deliberating on this for a while, because I really couldn't convince myself quickly that it's correct. And now that I look at it again, I'm again unsure whether or not it's correct, because now you can have MBSSID w/o params->beacon.mbssid_ies set, which has certain consequences, one of them being not setting link_conf->bssid_indicator in mac80211. This might not matter too much, depending on the driver, but it feels a bit inconsistent? Also I worry about something expecting the pointer, I guess. (There might also be a bug in mac80211? The bssid_indicator isn't updated when MBSSID disappears entirely?) I feel the MBSSID code here is probably too fragile overall, maybe you can find some time to go over it. That said, I was discussing it with Benjamin briefly, and he realized that you could just include an empty MBSSID element, or I think in fact zero-length element data in the nl80211 API. That way, your code also works with older versions, because you have num_elems, just that the data in the elems is 3 bytes (empty MBSSID element) or 0 bytes (none at all). johannes
