Re: State of DFS with Mac80211/ath9k

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

repost, unintentionally removed linux-wireless from CC

On 03/06/2015 01:32 PM, Henning Rogge wrote:
> On Fri, Mar 6, 2015 at 1:24 PM, Zefir Kurtisi <zefir.kurtisi@neratec.com> wrote:
>> On 03/06/2015 09:04 AM, Henning Rogge wrote:
>>> [...]
>>>
>>> Second, we are seeing a huge amount of radar events on some nodes, but
>>> not on a node on the same channel in the next room. What is the status
>>> of the DFS detector in ath9k, is it reliable or is it still
>>> "experimental".
>>>
>>
>> Henning,
>>
>> the DFS detector on one hand still can be labeled as 'experimental' since it seems
>> to be not used / tested all too much. On the other hand, our company got it
>> DFS-ETSI certified for a ath9k based product - so it does what it was made for.
>>
>> As for the 'false' radar detections you observe: those are inherent for the
>> detection method used. The ath9k's pulse detection engine reports anything that
>> somewhat looks like a radar pulse - besides very rare cases where those were
>> generated by real radar, most of them are EM-noise, WLAN traffic, other radio devices.
> 
> This means that the DFS algorithm produce an unacceptable (for mesh
> networks) amount of false positives, right?
> 
'unacceptable' is relative ;)

Regulatory requires you to detect reference patterns with only 50% of the pulses
seen. Take e.g. ETSI pattern 1 which has 10 nominal pulses, i.e. your detector
must be capable to detect any combination of 5 pulses within an presumed interval
as radar. If you have enough noise or WLAN traffic on proximate channels, there is
no way to differentiate between false and true positives.

>> Reality check: let two APs operate close to each other on adjacent DFS-channels,
>> connect one station to one of them and generate continuous downstream traffic
>> (e.g. 10Mbps). It will take only seconds until the other AP will detect a radar -
>> simply because it is inevitable to spot some potential pattern within a lot of
>> random pulses.
> 
> This is bad...
> 
It is. Our company is developing systems that not only get certified for DFS
operation, but also provide a reliable and continuous service on DFS channels. The
effort required is enormous.

> 
>> If you performed the tests in a similar environment, your observation is what you
>> have to expect. And unfortunately there is nothing to be done to prevent the false
>> radar detections - rendering operation on DFS frequencies inapplicable under some
>> environmental conditions.
> 
> Is this just a problem of the Linux Kernel implementation? Or is this
> a problem of all wifi drivers?
> 
> 
No, it is a generic problem of distinguishing radar pulses from any other type of
interferences. This is a problem at physical layer and should be common to all
WLAN devices out there, no matter if the DFS detection is done in HW, FW, or SW.
We are using ath9k for that specific reason: we can't do much about the pulse
detection in HW, but at least we have control over the pattern detector and can
tweak the detection parameters to tune sensitivity.


Cheers,
Zefir