On 01/23/2013 01:49 PM, Simon Wunderlich wrote: > Hey Zefir, > > On Mon, Jan 21, 2013 at 11:44:22AM +0100, Zefir Kurtisi wrote: >> On 01/18/2013 10:54 PM, Johannes Berg wrote: >>> On Thu, 2013-01-17 at 14:40 +0100, Simon Wunderlich wrote: >>> >>>> Actually there is no limit how long a channel is considered "available", at >>>> least in ETSI. ETSI EN 301-893 v1.4.1 had a limit of 24 hours for that, >>>> but that was removed in v1.5.1 and didn't re-appear since then (current is >>>> v1.7.1). >>> >>> Huh indeed, I would have expected that to be there. It does have a >>> non-occupancy time though (30 minutes), maybe we should implement that? >>> >> No, why be more restrictive than regulatory demands? >> >> With the recent incremental updates, a general note: Victor's initial approach was >> to keep all logic in hostapd and minimize the modifications in mac by only >> ensuring CAC times there. If NOP handling is also added to mac, we'd have >> everything needed to handle DFS channel states available. With hostapd only left >> to do the selection of the channel to switch to after a radar detection, it might >> make sense to move everything down to mac. I understand that questioning the >> design that late is not helpful, at the same time and since the initial path was >> left, it might be worth considering. > > Actually questioning the design NOW is a good idea, we are already questioning it > through the last patches and better bring up the issues now than later. We have started from the > simple hostap-handles-everything approach and have seen some points are missing when > we think about multi interfaces etc for the future (and implementation issues of course). > > If we move channel states (available/unavailable) already into the kernel space, we might > as well check for other states (already doing CAC, not valid until). Maybe it's better like > this than splitting the management over hostapd and cfg/mac80211? > As written in my other post today, managed master mode can't be supported (as long as we can't override channel states), so for our needs we need a different approach. Remarkably, the proof-of-concept I proposed as 'poor-man's solution' in Vancouver two years ago turned out to be quite well usable. It goes like this: *) hostapd: patched to allow DFS channels *) ath9k: patched to enable radar detection on DFS-channels *) channel states handled by a daemon in user space Switching to AVAILABLE channel: *) set up master immediately Switching to non AVAILABLE channel: *) set up monitor *) wait CAC *) set up master if no radar *) else select different channel Since I need to patch / bypass the master functionality to enable managed DFS mode, I am naturally biased. Nevertheless, ideally everything should be in cfg/mac, as long as there is no compelling reason to split it with hostapd. >>> I'm also thinking with the next regdb format update we should allow >>> specifying these timeouts etc. there. >>> >>> Does anyone have the relevant FCC rules? I can't find anything with >>> google ... >>> >> The FCC 06-96 document (freely available, e.g. >> http://hraunfoss.fcc.gov/edocs_public/attachmatch/FCC-06-96A1.pdf) seems to be the >> most recent one. Skimming over I did not find a requirement for the validity >> period after CAC. >> > > Thanks for pointing us to that doc. Couldn't find anything either, so I'd just > skip any "validity" for now. > >>>> But we can move the CAC/timeout in the wdev and have keep a flag field in >>>> the channel struct instead, marking the channel as available, unavailable, etc. >>>> >>>> What do you think? >>> >>> I think that would make sense. Probably available/unavailable and >>> "non-occupancy until"? >>> >> At that stage, we would have half of all potential states (UNKNOWN, AVAILABLE, >> OPERATING, UNAVAILABLE, USABLE, SCANNING) covered, so a current state per channel >> and the time it was entered would give everything required for the complete state >> machine in mac. > > Sounds good! Will look into this ... > State machine is trivial. If you need a reference implementation and are not scared of C++ code, I can provide you mine. > Thanks, > Simon > Thanks for handling this, Zefir -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
