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: <199f2ac280a1e1a195add45290411a9c1dc519fc.camel@sipsolutions.net>
Subject: Re: Automatically adding OCI in mac80211
From:   Johannes Berg <johannes@sipsolutions.net>
To:     James Prestwood <prestwoj@gmail.com>,
        linux-wireless@vger.kernel.org
Date:   Sat, 27 Aug 2022 16:46:12 +0200
In-Reply-To: <432703ce83ac979ba06e2b85d6dc500f246c6a76.camel@gmail.com>
References: <432703ce83ac979ba06e2b85d6dc500f246c6a76.camel@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.44.4 (3.44.4-1.fc36) 
MIME-Version: 1.0
Precedence: bulk

On Fri, 2022-08-26 at 14:12 -0700, James Prestwood wrote:
> Long ago support for multiple authenticated BSS's was removed due to
> its complexity.=C2=A0
>=20

Well, actually, you can still authenticate with multiple BSSes, we just
don't really track it.

> CMD_AUTHENTICATE now changes state/channel, and is not
> recoverable if authentication fails (i.e. disconnect).=C2=A0

It never did anything else though, IIRC? Anyway, doesn't matter much
now.

> The spec
> actually allows/intends for multiple authentications to be supported
> and FT specifically can really benefit from this.

Sure, and with FT especially you can do some things over the DS too -
but the kernel no longer cares, which is the part that was removed, if
you try to assoc without ever authenticating it doesn't matter as far as
the kernel is concerned.

> As a workaround we started playing around with using
> CMD_FRAME/offchannel for authentication, bypassing the kernels state.
> This works, and we can authenticate, fail, try another BSS etc. all
> without the kernel knowing, then proceed to association.

Should work, yeah.

> The small problem is dealing with OCV. Prior, we would call
> CMD_AUTHENTICATE (channel changes), then GET_INTERFACE in order to
> obtain the channel/operating class to build the OCI element. Now, since
> authentication is done offchannel we cannot use GET_INTERFACE. Deriving
> the OCI based on capabilities is certainly possible, after all this is
> what the kernel does, but rather than trying to mirror/maintain that
> code I thought it would be great if the kernel could append the OCI
> automatically to the association request. This would also save a round
> trip since GET_INTERFACE wouldn't be needed.

I don't understand. You already have to know the channel in order to
even *do* this (off-channel TX)? The kernel doesn't really know much
about operating classes, so that part seems a bit tricky.

Also note that this is not going to work so well with MLO due to the
link and MLD addresses, and the kernel currently inserting the ML
element, so not sure you're going to want to go this route now.

johannes