Re: [RFC PATCH v3 0/2] cfg80211: fix duplicated scan entries after channel switch

[Sergey Matyukevich <sergey.matyukevich.os@quantenna.com>]

> > > [External Email]: This email arrived from an external source - Please exercise caution when opening any attachments or clicking on links.
> 
> Heh, you have a not so fun email system that rewrites mails ...

:(
 
> > > > Suggested approach to handle non-transmitting BSS entries is simplified in the
> > > > following sense. If new entries have been already created after channel switch,
> > > > only transmitting bss will be updated using IEs of new entry for the same
> > > > transmitting bss. Non-transmitting bss entries will be updated as soon as
> > > > new mgmt frames are received. Updating non-transmitting bss entries seems
> > > > too expensive: nested nontrans_list traversing is needed since we can not
> > > > rely on the same order of old and new non-transmitting entries.
> > > 
> > > That sounds like a reasonable trade-off. I do wonder though what happens
> > > if we're connected to a non-transmitting BSS?
> > 
> > Well, here I rely upon the assumption that CSA IEs of non-transmitting BSS
> > are handled correctly by mac80211 or any FullMAC firmware. And if we are
> > connected to non-transmitting BSS rather than transmitting one, the
> > following code in the beginning of new cfg80211_update_assoc_bss_entry
> > function is supposed to care about this use-case:
> 
> 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 ?

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.

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.

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.

Regards,
Sergey