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