Client station sends probes on DFS channels

[Jean-Pierre Tosoni]

Hi Adrian,

> What's the etsi spec say about once a station hears beacons?

What ETSI EN301893 v1.8.1 [1] says is:

1) ETSI distinguishes "master" devices and "slave" devices
   (section 4.7.1.3)

2) "Slaves shall only operate in a network controlled by (...) a master"
   (section 4.7.1.3)

3) "A slave device shall stop its transmissions on a channel whenever
   instructed by a master device" (section 4.7.1.4)
   => In my understanding, from a 802.11 point of view, this implies that
      The slave obeys the master, hence it is associated with it "somehow".
      Otherwise, the station must be considered as being a master.

4) Channel move time: the slave must stop transmission within *10 seconds*
   After being instructed so (section 4.7.2.5.1 and table D.1)

5) During these 10 seconds, the airtime used must not exceed 1 second.


So,
- either any unrelated AP is considered a master, and when beacons
  cease this should be considered a hint to stop within 10 seconds,
- or the unassociated client is considered a master itself, and
  must obey CAC, NOP and so on.

Hence I think the relevant duration is the "channel move time" in table D.1
which is limited to 10 seconds -- instead of 10 minutes.

Jean-Pierre

De : Adrian Chadd [mailto:adrian.chadd at gmail.com] 
Envoyé : mercredi 30 novembre 2016 21:41
À : Jean-Pierre Tosoni
Cc : ath10k at lists.infradead.org
Objet : Re: Client station sends probes on DFS channels

Hi,
I thought that seeing beacons meant the sea could treat it as non passive for a while. Ten minutes sounds about right.
What's the etsi spec say about once a station hears beacons?
A

On Nov 30, 2016 12:36 PM, "Jean-Pierre Tosoni" <jp.tosoni at acksys.fr> wrote:
Hello list,

There is a case where I can see probes on a DFS channel, from a
non-associated station using ath10k. (note that the problem does
not arise when using ath9k).

*The setup*

I am using Openwrt, wpa_supplicant and compat-wireless 2016-10-08,
Card firmware is ath10k_pci: qca988x hw2.0 (0x4100016c, 0x043202ff)
                fw 10.2.4.70-2 api 5 htt-ver 2.1 wmi-op 5 htt-op 2
                cal otp max-sta 128 features no-p2p
        ath10k_pci: debug 0 debugfs 1 tracing 0 dfs 1 testmode 1

I am using channel 116, regdom US or FR, where I see no traffic at all
using wireshark+Airpcap.
I set wpa_supplicant to scan this channel only for a specific SSID "ssid1".

At initial startup of the client device, no probes are going out, which is
OK.

Then, on another device, I start a hostapd set to channel 116, with a
different SSID "otherssid" so that the supplicant will not associate.

Shortly (1-2s) after the beacons appear in the air, the client begins to
Send probe request in the air, which is unexpected, but acceptable since
the client can infer absence of radars from the presence of beacons.

*The problem*

If I power down the AP, the client continues to send probes for around
10 minutes, which is unacceptable since it cannot handle radar detection,
as it is a slave device in the meaning of ETSI/EN 301-893[1].


Some tests I made:
- I tried to investigate the "beacon hint" mechanism but it appears that it
  is not used on DFS channels.

- I tried to force the IEEE80211_NO_IR flag when IEEE80211_CHAN_DFS is set.

- When I reload the reg. domain using "iw reg set", the probes cease, but
  will reappear if I cycle my AP again On then Off.

- When I let the client associate, then disassociate and stop the AP, the
  same problem arises. It disappears if I add a call to ath10k_regd_update()
  in mac.c after a disconnection (This is not a fix, since in my case the
  client never associates).

- Since at startup, the client does not send probes, I infer that the
  problem is *not* caused by a hidden AP that the card could see but
  not airpcap.

- I tried with channels 52 and 100, with regdom FR or US: same problem.

Any ideas?


[1]
http://www.etsi.org/deliver/etsi_en/301800_301899/301893/01.08.01_60/en_3018
93v010801p.pdf

J.P. Tosoni - ACKSYS




_______________________________________________
ath10k mailing list
ath10k at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k