Return-path: Received: from mail-wg0-f46.google.com ([74.125.82.46]:42055 "EHLO mail-wg0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751240AbbCFM3I (ORCPT ); Fri, 6 Mar 2015 07:29:08 -0500 Received: by wggz12 with SMTP id z12so22621315wgg.9 for ; Fri, 06 Mar 2015 04:29:06 -0800 (PST) MIME-Version: 1.0 In-Reply-To: References: Date: Fri, 6 Mar 2015 13:29:06 +0100 Message-ID: (sfid-20150306_132913_349221_A217560A) Subject: Re: State of DFS with Mac80211/ath9k From: Janusz Dziedzic To: Henning Rogge Cc: "linux-wireless@vger.kernel.org" , Jouni Malinen Content-Type: text/plain; charset=UTF-8 Sender: linux-wireless-owner@vger.kernel.org List-ID: On 6 March 2015 at 10:26, Henning Rogge wrote: > On Fri, Mar 6, 2015 at 9:38 AM, Janusz Dziedzic > wrote: >> On 6 March 2015 at 09:04, Henning Rogge wrote: >>> First, we cannot open a Mesh interface on a DFS channel unless we open >>> an AP interface first (and closing the AP interface before activating >>> the mesh). Are we missing some special initialization? >>> >> I think this works beacause we didn't integrate patch: >> [PATCH v5] cfg80211: fix dfs channel state after stopping AP >> and discussion here: >> http://comments.gmane.org/gmane.linux.kernel.wireless.general/117095 >> >> Anyway I think this is a BUG while for example: >> 1) we can run AP (CAC) on chanel 36 >> 2) next shut down AP >> 3) wait few days with loaded cfg80211 and in the same time for example >> move to other location (AP in bus/train) >> 4) we don't need run CAC again - for me this is a cfg80211 bug :) > > Yes, this sounds like a bug... when wpa_supplicant "disconnects" from > the mac80211 stack the flag should revert to "dfs not available". But > I am not sure if you can easily detect that wpa_supplicant is not > there anymore. > This was implemented for hostapd (AP, multi APs) in patch [PATCH v5] cfg80211: fix dfs channel state after stopping AP. In case of STA (wpa_supplicant) we don't change channels DFS flags - we trust AP here. So, in case of ibss/mesh you could make wpa_supplicant dfs.c common and use it (perform CAC and other operations). >> Anyway, before you can beaconing you should perform CAC, so this >> should be added to wpa_supplicant - currently this is not implemented. > > Has the "802.11s support" ever been merged to wpa_supplicant? > > At the moment we are using neither wpa_supplicant nor hostapd... when > we use encryption, we use the authsae tool from the open802.11s page. > I am not sure, adding Jouni here. >>> 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". >>> >> We tested/using ath10k hw, so I don't know ath9k status :) > > Thank you for the information. > BR Janusz