On 6 March 2015 at 10:26, Henning Rogge <hrogge@xxxxxxxxx> wrote: > On Fri, Mar 6, 2015 at 9:38 AM, Janusz Dziedzic > <janusz.dziedzic@xxxxxxxxx> wrote: >> On 6 March 2015 at 09:04, Henning Rogge <hrogge@xxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
