From: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
To: Alexander Wilhelm <alexander.wilhelm@westermo.com>,
Jeff Johnson <jjohnson@kernel.org>, Jouni Malinen <j@w1.fi>
Cc: ath11k@lists.infradead.org, linux-kernel@vger.kernel.org,
hostap@lists.infradead.org
Subject: Re: ath11k: Question about active scanning of DFS channels
Date: Fri, 25 Sep 2026 08:03:16 -0700 [thread overview]
Message-ID: <3ea7e9ab-ed3a-4e6a-9006-b6f6af51c1fd@oss.qualcomm.com> (raw)
In-Reply-To: <arZ-gEnmv0QyuGI0@FUE-ALEWI-WINX>
On 9/25/2026 7:00 AM, Alexander Wilhelm wrote:
> Based on my research, DFS channels cannot be scanned passively, so I used a
> sniffer to verify that the "directed" probe requests with given SSID were
> actually being transmitted.
In general that isn't correct.
For starters, everything related to DFS is gated by regulatory rules. So the
operation of the client device first depends upon whether it is configured for
operation in a given country, or if it is configured for World Mode.
If configured for World Mode, then initially DFS channels can only be scanned
passively. A client device in World Mode must not transmit on a DFS channel
unless under the control of a master device. To do otherwise violates
regulatory rules in many countries. So the normal process is to perform
passive scan on DFS channels and process Country elements in Beacon frames in
order to determine the country in which the client is operating (aka perform
an 802.11d scan). Then the client can switch from World behavior to
country-specific behavior.
But even when operating in country-specific mode, whether by the initial
configuration or by processing Country elements, a client cannot transmit on a
DFS channel unless it is under control of a master device. If a client
receives a beacon on a DFS channel, then that channel is considered to be
under control of the master device that sent the beacon, and only at that
point can a client device actively probe/authenticate/associate.
Further complicating the issue is that some regulatory bodies have rules that
govern under what conditions Country elements can be used to determine the
current operating country. In particular, the FCC has rules which require a
device to maintain all FCC restrictions unless multiple criteria are met (I
don't remember the exact rules but seem to remember that at a minimum there
cannot be any master devices sending beacons with US Country elements and
there must be multiple master devices sending beacons with the same non-US
Country element before the device can be consider to be located in that non-US
country.
/jeff
prev parent reply other threads:[~2026-09-25 15:03 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-25 14:00 Alexander Wilhelm
2026-09-25 15:03 ` Jeff Johnson [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3ea7e9ab-ed3a-4e6a-9006-b6f6af51c1fd@oss.qualcomm.com \
--to=jeff.johnson@oss.qualcomm.com \
--cc=alexander.wilhelm@westermo.com \
--cc=ath11k@lists.infradead.org \
--cc=hostap@lists.infradead.org \
--cc=j@w1.fi \
--cc=jjohnson@kernel.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®