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

[Zefir Kurtisi <zefir.kurtisi@neratec.com>]

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?