Client station sends probes on DFS channels

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




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

RE: 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@gmail.com] 
Envoyé : mercredi 30 novembre 2016 21:41
À : Jean-Pierre Tosoni
Cc : ath10k@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@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@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k


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

Re: Client station sends probes on DFS channels

[Adrian Chadd]

Hi,

So to be clear:

* if you get a CSA, the STA should move and not use the air
* if you just start another AP And then kill the APs, there's nothing
above that says when the STA should stop talking?

Thanks,



-adrian

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

TR: Client station sends probes on DFS channels

[Jean-Pierre Tosoni]

Just keeping the list informed... At some point the discussion turned private.

Jean-Pierre Tosoni

-----Message d'origine-----
De : Adrian Chadd [mailto:adrian.chadd@gmail.com] 
Envoyé : jeudi 1 décembre 2016 19:20
À : Jean-Pierre Tosoni
Objet : Re: Client station sends probes on DFS channels

well, if it fails ETSI certification then you can file a complain with QCA. :) they're passing certification tests with it atm, so...


-a


On 1 December 2016 at 10:18, Jean-Pierre Tosoni <jp.tosoni@acksys.fr> wrote:
> :(
> Can we expect a fix someday?
>
> JP
>
>
>
>> -----Message d'origine-----
>> De : Adrian Chadd [mailto:adrian.chadd@gmail.com] Envoyé : jeudi 1 
>> décembre 2016 19:00 À : Jean-Pierre Tosoni Objet : Re: Client station 
>> sends probes on DFS channels
>>
>> firmware
>>
>>
>> -a
>>
>>
>> On 1 December 2016 at 09:53, Jean-Pierre Tosoni <jp.tosoni@acksys.fr>
>> wrote:
>> > Hi again,
>> >
>> > That being said, is this 10-minutes delay implemented in ath10k or 
>> > in the firmware of the card? Or is it configurable maybe?
>> >
>> > Jean-Pierre
>> >
>> >> -----Message d'origine-----
>> >> De : Adrian Chadd [mailto:adrian.chadd@gmail.com] Envoyé : jeudi 1 
>> >> décembre 2016 18:21 À : Jean-Pierre Tosoni Objet : Re: Client 
>> >> station sends probes on DFS channels
>> >>
>> >> Hi,
>> >>
>> >> So the implementations I've seen all treat "I see beacons" as "the 
>> >> channel is blessed"; there's no logic for doing it for an AP that 
>> >> you're associated to.
>> >>
>> >> That's likely what we need clarification around.
>> >>
>> >> The "controlled by a master" doesn't necessarily imply that the 
>> >> STA is controlled by the AP, just that the AP has gone through the 
>> >> CAC and is doing DFS checking. Otherwise the STA couldn't actually 
>> >> send assoc req/response frames, because the station hasn't yet 
>> >> associated to an AP to be considered "in control" by it.
>> >>
>> >>
>> >> -adrian
>> >>
>> >>
>> >> On 1 December 2016 at 09:09, Jean-Pierre Tosoni 
>> >> <jp.tosoni@acksys.fr>
>> >> wrote:
>> >> > Not quite so.
>> >> >
>> >> >> * if you get a CSA, the STA should move and not use the air
>> >> >
>> >> > No, because the STA is not associated: it is currently searching 
>> >> > for an
>> >> AP.
>> >> > So, it cannot receive a CSA, and should do a passive scan.
>> >> >
>> >> >> * if you just start another AP And then kill the APs, there's 
>> >> >> nothing above that says when the STA should stop talking?
>> >> >
>> >> > Wrong, the norm says that the STA should *not begin* talking 
>> >> > (since it is not associated with a master AP)
>> >> >
>> >> >> -----Message d'origine-----
>> >> >> De : Adrian Chadd [mailto:adrian.chadd@gmail.com] Envoyé : 
>> >> >> jeudi 1 décembre 2016 17:53 À : Jean-Pierre Tosoni Cc :
>> >> >> ath10k@lists.infradead.org Objet : Re: Client station sends 
>> >> >> probes on DFS channels
>> >> >>
>> >> >> Hi,
>> >> >>
>> >> >> So to be clear:
>> >> >>
>> >> >> * if you get a CSA, the STA should move and not use the air
>> >> >> * if you just start another AP And then kill the APs, there's 
>> >> >> nothing above that says when the STA should stop talking?
>> >> >>
>> >> >> Thanks,
>> >> >>
>> >> >>
>> >> >>
>> >> >> -adrian
>> >> >
>> >
>


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