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? 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
