Re: [PATCH ath-next 3/3] wifi: ath10k: bring down a station vdev that never came up

[Nagashima, Shunsuke]

Hi James,

Sorry, I am resending this as plain text. My first reply went out as
HTML by mistake, so it did not reach the lists. James, you may get it
twice. Sorry for the noise.

On 10/19/26 6:12 AM, James Prestwood wrote:
> This seems similar to an issue we see on the QCA6174's. I don't see a 20
> second delay, but sometimes after an auth/assoc timeout we get a spam of
> failed connections with NL80211_TIMEOUT_UNSPECIFIED. I've mentioned this
> quite some time ago [1]. Do you think it has any relation to whats being
> fixed here?

Thanks for the pointer. I read both of your mails in that thread. I
can't say for sure, but I don't think it is the same problem. I only
have WCN3990 here, so this comes from comparing logs, not from a test
on QCA6174.

Why I think it is different:

- In our case the failed attempt gets to the Auth stage. mac80211
 hands the Auth frames to the driver ("send auth to ... (try 1/3)" in
 the kernel log), the firmware completes them with status "discard",
 and the attempt ends with "authentication with ... timed out". In
 your trace, the attempts that fail with NL80211_TIMEOUT_UNSPECIFIED
 never get that far: each one is a short scan by cfg80211 that finds
 nothing from the target BSS, and the first rdev_auth in the trace
 comes only after a scan that did find its BSS. That matches what you
 found in March, that the BSS was missing from the kernel's BSS list.

- During our hold, probe requests still go out on the air. Only the
 Auth frames on that vdev are held.

- Our hold always ran for about 20 s, and only on two newer WCN3990
 firmware builds (c10-00459 and c10-00236). An older build,
 WLAN.HL.2.0-01387, did not show it.

- The missing VDEV_DOWN goes back to commit 077efc8c42e8 (v3.19), so
 5.15 has the same path. If your problem started between 5.15 and
 6.2 on the same firmware, this path alone would not explain that.

- You also see it on ath11k, and this patch only changes ath10k.

There is one overlap: your first case starts with an association
timeout, which is one of the failures after which ath10k stops the
station vdev without a down. If you want to rule it out, the patch is
small. With it, a failed attempt gets a VDEV_DOWN after the VDEV_STOP
(ATH10K_DBG_MAC prints "mac vdev N down (never up)"). If the
NL80211_TIMEOUT_UNSPECIFIED runs still happen on QCA6174 with the
patch, it is something else.

On ath11k, only as a pointer: I have not tested anything there and
have no ath11k hardware, so this is from reading the code (ath-next)
only. ath11k looks the same. A station vdev is stopped with
WMI_VDEV_STOP in ath11k_mac_op_unassign_vif_chanctx(), or in
ath11k_mac_stop_vdev_early() at station removal on chips with
vdev_start_delay, and the only VDEV_DOWN for a station vdev is in
ath11k_bss_disassoc(). So a station vdev that never came up would be
stopped without a down there too. I don't know whether ath11k firmware
cares about that.

I worked through this together with Claude (AI). English is hard for
me, so the English was written with AI help. The WCN3990 results come
from my own device tests on my comma four.

Thanks,
Shunsuke