> What's the etsi spec say about once a station hears beacons?
What ETSI EN301893 v1.8.1  says is:
1) ETSI distinguishes "master" devices and "slave" devices
2) "Slaves shall only operate in a network controlled by (...) a master"
3) "A slave device shall stop its transmissions on a channel whenever
instructed by a master device" (section 22.214.171.124)
=> 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 126.96.36.199.1 and table D.1)
5) During these 10 seconds, the airtime used must not exceed 1 second.
- 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.
De : Adrian Chadd [mailto:adrian.ch...@gmail.com]
Envoyé : mercredi 30 novembre 2016 21:41
À : Jean-Pierre Tosoni
Cc : firstname.lastname@example.org
Objet : Re: Client station sends probes on DFS channels
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?
On Nov 30, 2016 12:36 PM, "Jean-Pierre Tosoni" <jp.tos...@acksys.fr> wrote:
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).
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
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
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.
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.
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
- I tried with channels 52 and 100, with regdom FR or US: same problem.
J.P. Tosoni - ACKSYS
ath10k mailing list
ath10k mailing list