mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Alexander Wilhelm <alexander.wilhelm@westermo.com>
To: 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: ath11k: Question about active scanning of DFS channels
Date: Fri, 25 Sep 2026 16:00:32 +0200	[thread overview]
Message-ID: <arZ-gEnmv0QyuGI0@FUE-ALEWI-WINX> (raw)

Hello Developers,

I would like to investigate the following issue and would greatly appreciate
your support and feedback. I am using a QCN9074 chipset with the `ath11k` driver
and would like to use the background scan functionality in `wpa_supplicant`.
During my testing, I noticed that hidden access points operating on DFS channels
are not discovered. Even when I manually trigger a scan, I can only see the
hidden AP to which the client is currently connected. Other hidden APs remain
absent from the scan results.

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. I also confirmed that the hidden AP responded with a
probe response. However, despite receiving the probe response, the AP never
appears in the `scan_results` list reported by `wpa_supplicant`.

To further investigate, I modified the `ath11k` driver in the scan request
handling path `ath11k_wmi_start_scan_init()` as follows:

    -   arg->repeat_probe_time = 0;
    +   arg->repeat_probe_time = 50;
    +   arg->n_probes = 2;

After applying this changes, I was able to verify that two directed probe
requests were transmitted with a spacing of 50 ms between them. My main question
is how this use case is intended to work. At first glance, this does not appear
to be a driver bug. However, with the default configuration (repeat_probe_time =
0), the scan results do not seem to be updated as expected. Is this modification
to the `ath11k` driver considered valid, or is there a preferred way to handle
this scenario? Are there any `wpa_supplicant` parameters that should be adjusted
instead?

I would like to fully understand the intended behavior and the interaction
between `ath11k`, firmware, and `wpa_supplicant` in this case. Any insights,
recommendations, or background information would be greatly appreciated. Thank
you for your time and support.


Best regards
Alexander Wilhelm

             reply	other threads:[~2026-09-25 14:01 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-25 14:00 Alexander Wilhelm [this message]
2026-09-25 15:03 ` Jeff Johnson

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=arZ-gEnmv0QyuGI0@FUE-ALEWI-WINX \
    --to=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®