ath10k firmware sends probes on DFS channels without radar detection

Ben Greear greearb at candelatech.com
Tue Dec 6 11:36:01 PST 2016


On 12/06/2016 09:02 AM, Jean-Pierre Tosoni wrote:
> 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]

Have you confirmed that there are no probe requests being sent by
ath10k driver?

You could also try disabling the station keep-alive and roaming logic in the firmware by
tweaking the wmi initial setup logic.  I disable that in my firmware,
for instance, because mac80211 can do a better job and then I can
save resources in the firmware.

Finally, if that doesn't work, then I could probably fix that in CT firmware
in case that is of interest.

Thanks,
Ben

>
> Jean-Pierre Tosoni
>
>
>
>> -----Message d'origine-----
>> De : ath10k [mailto:ath10k-bounces at lists.infradead.org] De la part de
>> Jean-Pierre Tosoni
>> Envoyé : mercredi 30 novembre 2016 19:04
>> À : ath10k at lists.infradead.org
>> 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 at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/ath10k
>


-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com




More information about the ath10k mailing list