On Tue, 2022-04-26 at 09:16 +0200, Johannes Berg wrote: > > > The proposal to have some sort of mapping between local and OTA link > > will work. So in AP mode, it is OTA link_id but in STA mode, it is > > local > > link_id which does not change the life time of the STA link > > interface? Will that be still called link_id or something which > > means > > pseudo link_id (something like link_idx?) to avoid confusions with > > OTA link_id? > > I started calling it link_num later, but that might also be confusing > and misinterpreted as num_links or so? ... However, I'm starting to have second thoughts on this. I do understand the concern that Jouni mentioned, that the device might roam by itself, and change the underlying links, and you'd have races if you identify only by the link ID, and that just changed, and so now you're referring to something else. His suggestion was that we might need to include the BSSID or the address of the AP MLD, or such, in some cases. [1] However, if e.g. roaming is offloaded but the supplicant isn't, then we really do need the ability to refer to the link ID, e.g. to set the per link GTK/IGTK/BIGTK after the 4-way-HS (or later 2-way-HS). So now I'm wondering what we're achieving by having a mapping, if every component in the system needs to be aware of the mapping? johannes [1] Now that I'm writing this, I'll also note that basically such offloaded MLO-aware roaming basically means all the previous things we discussed with netdevs or wdevs don't work either?
