Hey Zefir, > [...] > >> Not sure if IEEE80211_DFS_UNKNOWN is not missing here, i.e. whether a channel that > >> never passed a CAC (or the CAC has been aborted) is always USABLE. Once I realized > >> why ETSI defined an UNKNOWN state, but forgot meanwhile - so maybe only relevant > >> for managed operation (like an UNKNOWN state can be overridden by external > >> information, whereas e.g. UNAVAILABLE can't). > > > > I've seen the UNKNOWN state in your last mail and your last slides, but didn't see > > a purpose for it. If you can remember what we need it for, please tell me. :) We could > > reject changes for an UNAVAILABLE channel from outside access if this is required. > > Double checked it and realized that ETSI removed that state between v1.5 and v1.7. > Before, it enabled the frequency manager to differentiate between untouched > channels and channels that passed a NOP (which is the only way to become USABLE). > OK, good, then we can skip it. :) > > The idea was that a CAC can always be started, and state transition is only performed > > after a succesful CAC. This simplifies the state machine and some corner cases. A > > channel stays USABLE through the CAC, and is only changed to AVAILABLE after CAC is > > completed. We also don't forbid checking the same channel on different WiFi modules, > > if any of them completes the channel is changed to AVAILABLE. > > > Really, a CAC is done whenever you switch to a DFS channel? I'd expect that > switching from an operating channel and back does not require a CAC (that's the > sole purpose of the AVAILABLE state and a centralized state handler). > No, as you say: if you switch operating channel to another one which is available, both channels stay available. You can CAC all channels after booting and switch between them without doing any other CAC (at least as long as you don't sense a radar). What I was trying to say: If the channel is USABLE before (this is also the initial state), it is only set AVAILABLE after CAC has finished on this device. If the CAC is aborted, no state transition is done. If you have a second AP instance (when multiple interfaces are supported at one point, they are not in the current version), it can also do start a CAC independently from the first AP. I like to keep the interfaces as independent as possible, to prevent weird race conditions/interactions between the interfaces which would be hard to debug. :) > > The same goes for the OPERATING state (defined in ETSI at least) - I don't have this > > as dfs state, because it is just the same as AVAILABLE plus the information that > > we currently use it, and that we know in the driver. Adding the state would just > > add management overhead with no practical gain, IMHO. > > > Would there be a benefit of an OPERATING state on systems with multiple wiphys? > I don't know - I've not looked up who creates the channels, but Johannes told me that different wiphys might have independent channel structs, if I remember correctly. If we have an OPERATING state we have to sync it over multiple wiphys and/or multiple interfaces - for example, when an interface goes down we have to check all other interfaces if they still use the channel before setting it back to AVAILABLE. Certainly doable, but bothersome. I currently don't see any benefit, but maybe someone else does and can explain. :) Cheers, Simon
Attachment:
signature.asc
Description: Digital signature
