This follows on the previous discussion "Client station sends probes on DFS channels" Problem: The combination of QCA988X firmware v10.2.4.70-2 + ath10k + wpa_supplicant do not comply with the norm ETSI/EN 301-893 section 4.7; because they can send probes for 600s when no AP is around. Analysis: The problem seems to lie in the firmware, which regards the presence of *any* beacon as a proof that the channel is radar-clean for 600s. This is a wrong hypothesis, since a rogue AP sending fraudulent beacons should not induce a scrupulous STA in sending illegal probes. Moreover, the norm (table D.1) sets a time limit of 10s to shutdown when no AP positively allows the STA to transmit on the DFS channel. Status: - there is no known plan at QCA to fix the issue. - ath10k firmware is not publicly available for fixes. - there is no obvious fix working in ath10k. - the issue does not show up with other mac80211 devices like ath9k. - wpa_supplicant considers this is a kernel issue [2] Jean-Pierre Tosoni > -----Message d'origine----- > De : ath10k [mailto:ath10k-bounces@xxxxxxxxxxxxxxxxxxx] De la part de > Jean-Pierre Tosoni > Envoyé : mercredi 30 novembre 2016 19:04 > À : ath10k@xxxxxxxxxxxxxxxxxxx > Objet : Client station sends probes on DFS channels > > 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_301893v010801p.pdf [2] http://lists.shmoo.com/pipermail/hostap/2015-January/031906.html > > J.P. Tosoni - ACKSYS > > > > > _______________________________________________ > ath10k mailing list > ath10k@xxxxxxxxxxxxxxxxxxx > http://lists.infradead.org/mailman/listinfo/ath10k
