Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <ff39ff9b6b1a6619ab30118e8a76b43ad2b9a715.camel@sipsolutions.net>
Subject: Re: [RFC PATCH] cfg80211: do some rework towards MLO link APIs
From:   Johannes Berg <johannes@sipsolutions.net>
To:     Vasanthakumar Thiagarajan <quic_vthiagar@quicinc.com>,
        linux-wireless@vger.kernel.org
Cc:     Jouni Malinen <j@w1.fi>
Date:   Thu, 28 Apr 2022 14:36:26 +0200
In-Reply-To: <6b40798e349d11e495a6df20ecba479a8357dad2.camel@sipsolutions.net>
References: <20220414145522.116716-1-johannes@sipsolutions.net>
         <f137ca7f-8b59-3368-c666-247f83d80383@quicinc.com>
         <6b40798e349d11e495a6df20ecba479a8357dad2.camel@sipsolutions.net>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.42.4 (3.42.4-2.fc35) 
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Precedence: bulk

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?