Re: [PATCHv6 0/6] Add DFS master ability

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

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

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 #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]