Automatically adding OCI in mac80211

Automatically adding OCI in mac80211

[James Prestwood]

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

Re: Automatically adding OCI in mac80211

[Johannes Berg]

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.

> 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.

johannes

Re: Automatically adding OCI in mac80211

[James Prestwood]

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

Re: Automatically adding OCI in mac80211

[James Prestwood]

Hi Johannes,

> > 
> > 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.

So thinking about it more I think we have two options:

1. Improve CMD_ASSOCIATE to be non-destructive on failure and allow the
API to accept a channel definition directly i.e. enough info for
nl80211_parse_chandef() to work. Then use this chandef rather than
derive its own. If this fails (e.g. due to a downgrade) return an error
and userspace could downgrade the width itself and try again. What I'm
thinking here is not modifying any values in sdata, link, ifmgd etc.
until the channel switch returns successfully.

2. Build the OCI element all in the kernel. As far as figuring out the
operating class I'm happy to contribute that (IWD already does this).
And I'm not sure what you mean about it not working with MLO, I don't
know much about it.

Also I do think there would be some value doing (1) in general as far
as it being non-destructive. ieee80211_mgd_assoc() starts modifying
state almost immediately making any failure (even -EBUSY) result in a
disconnect AFAICT. This seems kinda bad...

Thanks,
James


> 
> Thanks,
> James
> 
> > 
> > johannes
> 
> 

Re: Automatically adding OCI in mac80211

[Johannes Berg]

Hi James,

Sorry - going through old email that might still need attention, clearly
dropped the ball on this ...

On the other hand, now we have all the MLO code in the tree :)

> So thinking about it more I think we have two options:
> 
> 1. Improve CMD_ASSOCIATE to be non-destructive on failure and allow the
> API to accept a channel definition directly i.e. enough info for
> nl80211_parse_chandef() to work. Then use this chandef rather than
> derive its own. If this fails (e.g. due to a downgrade) return an error
> and userspace could downgrade the width itself and try again. What I'm
> thinking here is not modifying any values in sdata, link, ifmgd etc.
> until the channel switch returns successfully.

That seems rather complex too, to be honest.

> 2. Build the OCI element all in the kernel. As far as figuring out the
> operating class I'm happy to contribute that (IWD already does this).

That might be easier, though I guess it needs to have an opt-in from
userspace to solve this issue.

> And I'm not sure what you mean about it not working with MLO, I don't
> know much about it.

I don't know how OCV works with MLO in the first place, but I guess it'd
have to be per link?

So I guess it would work, just have to be done for each link.

> Also I do think there would be some value doing (1) in general as far
> as it being non-destructive. ieee80211_mgd_assoc() starts modifying
> state almost immediately making any failure (even -EBUSY) result in a
> disconnect AFAICT. This seems kinda bad...

Well, there could be some plausible reordering here, but a lot of hw/fw
fundamentally cannot try to make a new connection while maintaining an
old one, so in general you can't really fix that completely.

johannes

Re: Automatically adding OCI in mac80211

[James Prestwood]

Hi Johannes,

On 4/24/23 10:15 AM, Johannes Berg wrote:
> Hi James,
> 
> Sorry - going through old email that might still need attention, clearly
> dropped the ball on this ...
> 
> On the other hand, now we have all the MLO code in the tree :)

No problem, I had completely forgotten about this as well. Moved on to 
other things :)

> 
>> So thinking about it more I think we have two options:
>>
>> 1. Improve CMD_ASSOCIATE to be non-destructive on failure and allow the
>> API to accept a channel definition directly i.e. enough info for
>> nl80211_parse_chandef() to work. Then use this chandef rather than
>> derive its own. If this fails (e.g. due to a downgrade) return an error
>> and userspace could downgrade the width itself and try again. What I'm
>> thinking here is not modifying any values in sdata, link, ifmgd etc.
>> until the channel switch returns successfully.
> 
> That seems rather complex too, to be honest.

yeah I started down this path and quickly got in over my head.

> 
>> 2. Build the OCI element all in the kernel. As far as figuring out the
>> operating class I'm happy to contribute that (IWD already does this).
> 
> That might be easier, though I guess it needs to have an opt-in from
> userspace to solve this issue.

Yeah, probably some flag attribute would be needed. At the moment I've 
got other priorities but I'll keep this in mind.

Thanks for getting back to me though.
- James

> 
>> And I'm not sure what you mean about it not working with MLO, I don't
>> know much about it.
> 
> I don't know how OCV works with MLO in the first place, but I guess it'd
> have to be per link?
> 
> So I guess it would work, just have to be done for each link.
> 
>> Also I do think there would be some value doing (1) in general as far
>> as it being non-destructive. ieee80211_mgd_assoc() starts modifying
>> state almost immediately making any failure (even -EBUSY) result in a
>> disconnect AFAICT. This seems kinda bad...
> 
> Well, there could be some plausible reordering here, but a lot of hw/fw
> fundamentally cannot try to make a new connection while maintaining an
> old one, so in general you can't really fix that completely.
> 
> johannes