Re: [PATCHv6 3/6] nl80211/cfg80211: add radar detection command/event

[Simon Wunderlich <simon.wunderlich@s2003.tu-chemnitz.de>]

[-- Attachment #1: Type: text/plain, Size: 3112 bytes --]

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?

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

Thanks,
	Simon

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]