On Wed, Jun 20, 2012 at 4:12 PM, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: > On Wed, 2012-06-20 at 14:58 +0200, Zefir Kurtisi wrote: > >> >> 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()? > >> 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. > > But this kernel patch is attempting to enforce the wait time. Are you > saying it shouldn't even pretend to enforce it? > It's not just attempts, it's ensures that no transmission will occur until we perform a radar detection on the channel. It's doesn't matter if the usermode use hostapd or some other applications. -- Thanks, Victor. -- 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
