Hey Felix, On Fri, Jun 07, 2013 at 07:33:16PM +0200, Felix Fietkau wrote: > On 2013-06-07 7:05 PM, Simon Wunderlich wrote: > > This is the follow up from the RFC posted a month ago. This patchset adds generic > > channel switch 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. > > > > The rough design is: > > * userspace asks kernel to switch a channel using the new NL80211_CMD_CHANNEL_SWITCH > > command. It supplies IE information for the time while staying on the old channel and > > announcing the switch, and IE information for after the switch to the new channel. > > * IE information contains the beacon and optionally probe responses, which should > > include (E)CSA IEs for the CSA case. Furthermore an offset is provided (for beacon > > and probe response) to point to the counter field within the channel switch IEs. > > * The driver gets the new beacons passed and must set them, and decrement the > > counter field. When it reaches 0, the channel is changed and userspace notified. > > > > Discussion points: > > * Assembling all these IE information is a little bit tedious but doable (I've > > patched hostapd). > > * Other future users like IBSS/MESH will not get the beacon/probe response IEs, as they > > generate these beacons themselves. Therefore they need the COUNT attribute, which > > is kind of duplicate right now. > > * Userspace must generate/handle all IEs, which lifts the previous limitations of > > the RFC (e.g. no change of band allowed, no operation mode change allowed). > > * it currently works for me [TM] on my ath9k based machine > I think this is a bit racy. Just because the driver gets a beacon from > mac80211 doesn't mean that the beacon will be sent *immediately*. I'd > recommend calling back from the driver into mac80211 on beacon tx > completion. Also, it might make sense to skip CAB queue transmissions in > this case. mhm, you're right, changing channel might race with sending the beacon as it's set right now. I'd change it to: * update the counter within get_beacon() (as done now) * perform the channel switch after beacon transmission is completed (not sure how to get this event practically yet ... :] ) What do you think? This must probably handle stuck/lost beacons too - is there any completion function called for stuck beacons? Thanks, Simon
Attachment:
signature.asc
Description: Digital signature
