Hi Sergey, Sorry for dropping the ball on this thread. > > Right, it will be updated on RX. But then if we chanswitch, we would > > probably (mac80211 using a pointer to the non-transmitting BSS) update > > only one of the nontransmitting BSSes? > > > > Just saying that maybe we need to be careful there - or your wording > > might be incorrect. We might end up updating a *nontransmitting* BSS, > > and then its transmitting/other non-tx ones only later? > > Hmmm... I am not sure we are on the same page here. Could you please > clarify your concerns here ? I'm trying to say we might have this: cfg80211 * transmitting BSS 0 - nontx BSS 1 - nontx BSS 2 - nontx BSS 3 mac80211 * ifmgd->associated (and cfg80211's wdev->current_bss?) = nontx BSS 2 Now, things like the channel information etc. will always be identical between the 4 BSSes, by definition. However, if you chanswitch and mac80211 just lets cfg80211 know about the current_bss, then you may end up in a situation where the channel information is no longer the same, which is very surprising. > The normal (non multi-BSSID) BSS usecase seem to be clear: keep old and > remove new (if any), since it is not easy to update ifmgd->associated. Right. > Now let me take another look at the usecase when STA is connected to > a transmitting or non-transmitting BSS of a multi-BSS AP. At the moment > suggested code does the following. If STA is connected to the non-transmitting > BSS, then we switch to its transmitting BSS, instead of working with > current_bss directly. We switch? Where? Maybe I missed that. > So we look for the new entry (with new channel) of the transmitting BSS. > If it exists, then we remove it and _all_ of its non-transmitting BSSs. > Finally, we update channel and location in rb-tree of the existing (old) > transmitting BSS as well as _all_ of its non-transmitting entries. That would indeed address the scenario I was thinking of ... johannes
