Hi,
I am working with a co-worker on DFS-support for the 802.11s
implementation of the mac80211 stack.
As a test we just removed the test for "DFS not supported" from
net/mac80211/mesh.c, but we are still facing two problems.
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?
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 Rogge
On 6 March 2015 at 10:26, Henning Rogge <[email protected]> wrote:
> On Fri, Mar 6, 2015 at 9:38 AM, Janusz Dziedzic
> <[email protected]> wrote:
>> On 6 March 2015 at 09:04, Henning Rogge <[email protected]> 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
On Fri, Mar 06, 2015 at 01:54:22PM +0100, Henning Rogge wrote:
> > Yes, wpa_supplicant has support for mesh BSS since November.
>
> Do you mean IBSS or 802.11s?
Mesh BSS is the name of the functionality that was added in the 802.11s
amendment.. "802.11s" is not really a good name to use for this taken
into account that the amendment was already merged into the current IEEE
802.11 standard.
--
Jouni Malinen PGP id EFC895FA
On Fri, Mar 6, 2015 at 1:50 PM, Jouni Malinen <[email protected]> wrote:
> On Fri, Mar 06, 2015 at 01:29:06PM +0100, Janusz Dziedzic wrote:
>> So, in case of ibss/mesh you could make wpa_supplicant dfs.c common
>> and use it (perform CAC and other operations).
>
> I actually pushed out changes yesterday to allow dfs.c/CAC to be used
> from wpa_supplicant in case of AP mode operations. I have not tried what
> would happen with mesh in similar case, but that may need changes and
> IBSS certainly would require more work for DFS.
We are using 802.11s (without multihop forwarding) instead of IBSS.
>> > 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.
>
> Yes, wpa_supplicant has support for mesh BSS since November.
Do you mean IBSS or 802.11s?
Henning Rogge
On 6 March 2015 at 09:04, Henning Rogge <[email protected]> wrote:
> Hi,
>
> I am working with a co-worker on DFS-support for the 802.11s
> implementation of the mac80211 stack.
>
> As a test we just removed the test for "DFS not supported" from
> net/mac80211/mesh.c, but we are still facing two problems.
>
> 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 :)
Anyway, before you can beaconing you should perform CAC, so this
should be added to wpa_supplicant - currently this is not implemented.
> 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 :)
BR
Janusz
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 <[email protected]> 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
On Fri, Mar 6, 2015 at 1:24 PM, Zefir Kurtisi <[email protected]> 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
On Fri, Mar 06, 2015 at 01:29:06PM +0100, Janusz Dziedzic wrote:
> So, in case of ibss/mesh you could make wpa_supplicant dfs.c common
> and use it (perform CAC and other operations).
I actually pushed out changes yesterday to allow dfs.c/CAC to be used
from wpa_supplicant in case of AP mode operations. I have not tried what
would happen with mesh in similar case, but that may need changes and
IBSS certainly would require more work for DFS.
> > 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.
Yes, wpa_supplicant has support for mesh BSS since November.
--
Jouni Malinen PGP id EFC895FA
On Fri, Mar 6, 2015 at 9:38 AM, Janusz Dziedzic
<[email protected]> wrote:
> On 6 March 2015 at 09:04, Henning Rogge <[email protected]> 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.
> 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.
>> 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.
Henning Rogge
On Fri, Mar 6, 2015 at 4:28 PM, Zefir Kurtisi <[email protected]> wrote:
> On 03/06/2015 03:33 PM, Henning Rogge wrote:
>>
>> Is there a way to make the kernel export the pulse patterns when a
>> radar event is detected to do some debugging what was going on?
>>
>
> Anyway, you should compile ath9k with debugging support (which you most probably
> already did) and enable DFS debugging by setting ATH_DBG_DFS (0x00010000) in
> /sys/kernel/debug/ieee80211/phy0/ath9k/debug
>
> This will give debug output per individual pulse and detector results and allow to
> understand why the detector triggered.
>
> Also if not already known, there is a dfs_stats file in the same debugfs directory
> providing global DFS counters.
>
>
> Hope it helps, have a nice weekend.
I already found the dfs_stats file, but the DFS debugging sounds
interesting. Thank you for the hint.
Henning Rogge
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.
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.
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.
Cheers,
Zefir