Re: [PATCH v2 3/7] nl80211/cfg80211: add ability to enable TX on op-channel

[Johannes Berg <johannes@sipsolutions.net>]

On Wed, 2012-06-20 at 16:32 +0300, Goldenshtein, Victor wrote:
> On Wed, Jun 20, 2012 at 4:12 PM, Johannes Berg
> <johannes@sipsolutions.net> 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