Re: [PATCHv7 2/3] mac80211: add radar detection command/event

[Johannes Berg <johannes@sipsolutions.net>]

On Sat, 2013-02-02 at 23:15 +0100, Simon Wunderlich wrote:
> On Fri, Feb 01, 2013 at 10:57:00AM +0100, Johannes Berg wrote:
> > On Thu, 2013-01-31 at 18:47 +0100, Simon Wunderlich wrote:
> > 
> > > > > What I've tried:
> > > > >  * configure 2 SSIDs in hostapd, start it
> > > > >  * both wlan0 and wlan0-1 got created
> > > > >  * only wlan0 comes up, wlan0-1 was rejected because of missing channel combinations
> > > > >  * now I've injected a radar - which should be sent to wlan0 and wlan0-1
> > > > >  * wlan0 could send the event, but wlan0-1 had no bss configured and therefore no chandef
> > > > > 
> > > > > I can change this comment to "may happen to devices which have currently no BSS configured",
> > > > > maybe that it is not so confusing ...
> > > > 
> > > > Not sure I understand, how would the radar detected event come to an
> > > > interface that doesn't really exist for the driver?
> > > 
> > > wlan0-1 exists and was created, but no AP was ever started - because hostapd tried
> > > to start the AP on a DFS channel when wlan0 was already active, and thanks to our
> > > interface combinations this is not allowed. Therefore, the vif.bss_conf.chandef is empty.
> > > 
> > > The interface does exist for the driver (interface add succeeded), but start_ap failed,
> > > so it is a virgin AP interface.
> > > 
> > > I think this behaviour is correct like that ...
> > 
> > So ... starting the AP failed because it was a different channel, it was
> > added to the driver because multiple AP interfaces were allowed but the
> > specific channel wasn't allowed (in addition) when it was started? But I
> > still don't see why that interface should get an event since it doesn't
> > even have a channel yet, except maybe preset_chan which is really only
> > for backward compatibility reasons?
> > 
> > What am I missing? Where does the event on wlan0-1 come from anyway?
> 
> In the (dummy) ath9k part I'm handling the radar by simply sending radar events
> to all ieee80211_vifs which are registered on this phy - regardless their
> status, if they are up or not. That's why both wlan0 and wlan0-1 get the
> event in my example. Of course, sending the event to wlan0-1 is pretty
> useless in my case, but we should better check. :)

That sounds strange -- how does ath9k even know about an interface
that's not UP? Maybe you mean it didn't start an AP?

Why does the driver even report it by interface? It seems it should do
it on a channel context, or even on the hw since it can only be a single
channel in that case anyway?

johannes