Return-path: Received: from mail-wi0-f169.google.com ([209.85.212.169]:41385 "EHLO mail-wi0-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754924AbbCFMdH (ORCPT ); Fri, 6 Mar 2015 07:33:07 -0500 Received: by wiwl15 with SMTP id l15so3204433wiw.0 for ; Fri, 06 Mar 2015 04:33:06 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <54F99C9B.7000901@neratec.com> References: <54F99C9B.7000901@neratec.com> From: Henning Rogge Date: Fri, 6 Mar 2015 13:32:45 +0100 Message-ID: (sfid-20150306_133315_684362_83128036) Subject: Re: State of DFS with Mac80211/ath9k To: Zefir Kurtisi Cc: "linux-wireless@vger.kernel.org" Content-Type: text/plain; charset=UTF-8 Sender: linux-wireless-owner@vger.kernel.org List-ID: On Fri, Mar 6, 2015 at 1:24 PM, Zefir Kurtisi 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? > 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... > 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? Henning Rogge