On 06/20/2012 01:57 PM, Johannes Berg wrote: > On Wed, 2012-06-20 at 13:53 +0200, Zefir Kurtisi wrote: >> On 06/20/2012 10:46 AM, Johannes Berg wrote: >>> On Wed, 2012-06-20 at 10:44 +0200, Johannes Berg wrote: >>>>> + if ((!chan->radar_detect_timeout || >>>>> + time_is_after_jiffies(chan->radar_detect_timeout)) && >>>>> + (chan->flags & IEEE80211_CHAN_RADAR)) >>>>> + return -EPERM; >>>> >>>> Ok so you reject it if it's 0, but the jiffies calculation could return >>>> 0 too.. in fact, since jiffies start at -5 minutes on boot, you might >>>> even hit it if you start radar detection 4 minutes after boot. >>> >>> Also, it seems that the value should be reset eventually ... at least on >>> interface down or so. Otherwise you can start CAC, then bring the >>> interface down to stop the device, and then bring it back up (CAC check >>> is no longer running) and then you can use the channel after some time >>> even though you never really checked for radar... >>> >> No, if you bring it back up on the same DFS channel, >> radar_detection_timeout will be set back to +60s by >> start_radar_detection(). Looks safe to me. > > You need to think a bit more outside the regular code flows ... What if > I'm not calling start_radar_detection()? > > johannes > If you are not calling start_radar_detection() you are not using hostapd. With the design approach we agreed on (when we initially discussed DFS years ago) to have all the logic located in hostapd, it is inevitable that those who intentionally want to bypass DFS regulatory restrictions actually can. You can always replace hostapd by some component that handles DFS control without caring the wait times. I don't see a reliable and fail-safe method to prevent users doing that. Other than maybe moving the logic part up to mac80211 or create some additional barrier like is done with crda (which is exactly that: additional barriers, but no prevention). tl;dr: if the DFS regulatory compliance is provided by hostapd, it is mandatory for master mode - which ensures that start_radar_detection() is called whenever operating a DFS channel. -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
