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: <432703ce83ac979ba06e2b85d6dc500f246c6a76.camel@gmail.com>
Subject: Automatically adding OCI in mac80211
From:   James Prestwood <prestwoj@gmail.com>
To:     linux-wireless@vger.kernel.org
Date:   Fri, 26 Aug 2022 14:12:43 -0700
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.40.4 (3.40.4-5.fc34) 
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Precedence: bulk

Hi,

I'll preface this with some background:

Long ago support for multiple authenticated BSS's was removed due to
its complexity. CMD_AUTHENTICATE now changes state/channel, and is not
recoverable if authentication fails (i.e. disconnect). The spec
actually allows/intends for multiple authentications to be supported
and FT specifically can really benefit from this.

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.

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.

Does this sound reasonable?

Thanks,
James