On 06/20/2012 03:12 PM, Johannes Berg 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? > > johannes > No, it serves its purpose to ensure hostapd is not going mad and tries to enable TX before the CAC is over via redundant checks. What I'm saying is this: we defined that DFS regulatory compliance is provided by and distributed over driver, mac80211, and hostapd. We always must ensure that a working combination of those operates in compliance. But we have no control over it when a component is exchanged or modified. The regulatory statement we all signed does not even ask for that, it states that 'average users should not accidentally fail to comply...' which can be denied to be accidental for someone running master mode without hostapd. Back to topic: as stated above, radar_detection_timeout should be per wiphy. That would also resolve your concern, right? -- 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
