Client station sends probes on DFS channels

[Jean-Pierre Tosoni]

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