On Thu, Jan 31, 2013 at 05:48:22PM +0100, Johannes Berg wrote: > > > > +void ieee80211_radar_detected(struct ieee80211_vif *vif, gfp_t gfp) > > > > +{ > > > > + struct ieee80211_sub_if_data *sdata = vif_to_sdata(vif); > > > > + > > > > + trace_api_radar_detected(sdata); > > > > + > > > > + /* may happen to devices which have been added but are not up */ > > > > + if (!cfg80211_chandef_valid(&sdata->vif.bss_conf.chandef)) > > > > + return; > > > > > > Huh, what does device and up have to do with that? > > > > > > > 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 ... Cheers, Simon
Attachment:
signature.asc
Description: Digital signature