Hello Johannes, thanks for your review! On Mon, May 13, 2013 at 12:09:38PM +0200, Johannes Berg wrote: > On Mon, 2013-05-06 at 21:13 +0200, Simon Wunderlich wrote: > > This is an early RFC of a possible channel switch announcement infrastructure. > > It adds CSA/ECSA handling support for AP. This is required for DFS operation > > (e.g. Wi-Fi Alliance requires this for 802.11h certification). This will also > > be required for IBSS-DFS later. > > > > I'd like to discuss if this design approach is going in the right direction. > > What is currently working: > > > > * channels are announced by adding IEs (CSA and Extended CSA) in beacons > > * after some (configurable) time, the channel is switched > > * with the channel switch, CSA/ECSA IEs are removed and channel information > > is updated. > > * Userspace calls a new command NL80211_CMD_CHANNEL_SWITCH along with channel info > > (freq + width), whether traffic should be blocked and timing information > > * it currently works for me [TM] on my ath9k based machine > > I don't really like your approach of building all the IEs in the kernel. > There are some things, like the country-after-switch in the CSA wrapper > (introduced in 11ac), that would be really awkward this way. Hmm ... OK. I have not checked 802.11ac yet (actually I don't have access to the drafts anyway). So what we have to expect is changing the country after the switch, or also other new things? > > * We already have NL80211_CMD_CH_SWITCH_NOTIFY which is only used for notification. > > Maybe we can rename that and re-use it instead of adding a new command > > NL80211_CMD_CHANNEL_SWITCH? > > Sure, I don't really care though. > OK, will try to merge that then. Seems cleaner than having multiple channel switch commands in the API. > > * could other drivers (next to ath9k) work with this API? > > Probably not easily. Any TI folks reading this? I was thinking about adding another callback function or option for that for drivers who do the channel switch internally. Then we would only need mac80211 to adapt. Would that help, or what would be problematic? > > > Anyway I think it'd be better to try to provide > (a) the "during-switch IEs", maybe with an offset to the counter so > mac80211, > driver or the device itself can count down > (b) the "after-switch beacon" IEs (and maybe probe response for o> offload) Yeah, that would be an alternative. I've been inspired by IEEE 802.11-2012/6.3.17 (MLME-CHANNELSWITCH) originally. :) I think your suggestion is good for AP where we control the beacon. For IBSS it would be a little different: when a channel switch is triggered, userspace does not know the beacon (and will not set it). Therefore, we could only accept the change IEs and skip the "after-switch-beacon" IEs (these would be re-generated internally) in IBSS mode. I guess it would be similar for mesh. What do you think? Cheers, Simon
Attachment:
signature.asc
Description: Digital signature
