ath10k firmware sends probes on DFS channels without radar detection

Wed Dec 14 10:28:44 PST 2016

On 12/14/2016 10:14 AM, Jean-Pierre Tosoni wrote:
> On 12/06/15 08:36 PM, Ben Greear wrote:
>> 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?
>
> I have put a printk in the ath10k_tx function (in the path for management
> frames) and it does not show up.
> On another hand I cannot find any other function preparing / sending probes.
> There is only the wmi command that starts scans.

That wmi command causes probes, so make sure it is not being called.

>> 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.
>
> Do you mean the values set in wmi.c:: ath10k_wmi_start_scan_init() ?
>
> Should I replace all the scan offload by a mac80211-controlled scan like
> in ath9k? The problem then is to switch channels; channel switching
> seems very different from ath9k.

You might try one or more of these settings in the ath10k_wmi_10_1_op_gen_init
method (or 10.2 if that is the FW you are using):

	config.roam_offload_max_vdev = 0; /* disable roaming */
	config.roam_offload_max_ap_profiles = 0; /* disable roaming */
	config.bmiss_offload_max_vdev = 0;

I have only tested this using my CT firmware, and I have some additional
patches in my driver to enable mac80211 keep-alive logic when using my
CT firmware.

Thanks,
Ben

>
> Thanks,
> JP
>
>> 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
>>
>>
>> _______________________________________________
>> 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