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. > And if you start CAC on two different devices on the same channel, but > they happen to share channel structs in the driver then this will all > conflict quite badly. > Details ;) In fact, if you start device A at a DFS channel and device B at the same channel 50secs later and device A did not detect radars after 60secs, ideally both should get TX enabled at the same time with B's CAC being aborted after 10secs. For that radar_detect_timeout had to be per wiphy. With the proposal here you have to wait for the last device to pass the CAC and if you alternatively put devices A and B up and down every 30secs you can effectively prevent them from TXing forever. > > This needs a lot of more thinking it seems. > > johannes > -- 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
