On Wed, 2012-06-20 at 16:32 +0300, Goldenshtein, Victor wrote: > 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. As written, it doesn't have that effect. 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
