On Sat, 2022-08-27 at 16:46 +0200, Johannes Berg wrote: > 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. > > > > Well, actually, you can still authenticate with multiple BSSes, we > just > don't really track it. Yes what I meant (which I never made clear) was that once you authenticate you can never go back to the original BSS without fully disconnecting. > > > CMD_AUTHENTICATE now changes state/channel, and is not > > recoverable if authentication fails (i.e. disconnect). > > 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. Yeah, true the kernel doesn't have the tables for operating classes... Basically the critical info we need is the channel width and center1 frequency (plus center2 freq for 80+80) values for the offchannel operation. So maybe another API for getting this? Give it a channel/freq and a BSS MAC, and run roughly the same derivation as ieee80211_determine_chantype(). The only problem here is when picking the channel the kernel tries one configuration, and if it fails it downgrades the width... So this would need to be fixed to know ahead of time, if thats possible. Note, adding something like this would also benefit FT-over-DS since currently you cannot do OCV with it. Thanks, James > > johannes
