On Fri, Jan 18, 2013 at 11:08:53PM +0100, Johannes Berg wrote: > Hi, > > > As stated before: "available until ..." time is not neccessary as far > > as I know. Also the channel must stay available when AP stops operation, > > I'll change that. > > Yeah, I checked the documents myself now ... strange, but hey. Radars > are fixed installations and mostly active continually, so I guess they > figured it was no big deal. > Yup. There was this "24 hours disconnect" problem many users complained about. Some vendors ignored it, some actually implemented to be quiet for 1 minute after using a channel for 24 hours. It's a good thing that this requirement was removed. :) > > > * radar detection finished: > > > - driver: call mac80211 with result (radar detected or not) > > > - mac80211: free up channel context (probably needs workqueue!) > > > pass result to cfg80211 > > > - cfg80211: clear wdev radar detect chandef > > > if OK to use: store availability in channel struct > > > send result to userspace > > > > Right now we only have the event for radar detect (i.e. detection > > failed). > > > > We could add a timer to mark the channel available after the CAC time, > > if no radar has been detected in this time. Don't know if mac80211 or > > cfg80211 would be the best place for this, but I think the driver is not > > - this timer must be shared over various drivers after all. > > Fair point. It seems likely though that full-MAC chips, if they > implement this at all, would have the timer in firmware. Therefore, > providing API for "radar detected" and "channel is usable" would make > more sense? The timer would then go into mac80211. > > Later, if we modify the regdb format/API, we could also pass the minimum > time from there. That way, if it ever gets changed and we want to rely > on regdb info, we could. > OK, will look into that. > > > * start AP: > > > - cfg80211: check channel availability > > > - cfg80211/mac80211/driver? - enable radar detection while operating > > > > mac80211 can instruct the driver to use radar detection while operating. > > E.g. pass it in sdata->vis.bss_conf ? > > I would say in the chanctx, i.e. struct ieee80211_chanctx_conf. Since > not all drivers implement that yet, also struct ieee80211_conf. See how > local->_oper_channel gets set in mac80211/chan.c. This information would > be similar, the "master" information would be in the chandef, copied to > local/local->hw.conf. > OK. > > > * AP channel switch: > > > - if due to radar, mark channel as not clear > > OK - in AP case, we would have got the radar event anyway so the channel > > would already be marked "not clear". In IBSS however, that is possible > > (another station may have asked us to switch channel because of radar). > > Oh, I wasn't even considering that -- don't care what you do there, > although it makes sense. OTOH, we would detect the radar ourselves, so > it doesn't really matter? > It might happen that a radar is detected on one device but not on the other. Think of a longshot operated with IBSS or a big mesh network. The other participants of the IBSS will have to switch channels as well - and the same channel would be good. :) Anyway, the IBSS case is special and we can handle it later. Cheers, Simon
Attachment:
signature.asc
Description: Digital signature
