On Fri, 2019-07-12 at 09:27 +0000, Sergey Matyukevich wrote: > On Fri, Jul 12, 2019 at 11:11:19AM +0200, Johannes Berg wrote: > > > > [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? johannes
