[PATCH ath-next 0/3] wifi: ath10k: WCN3990 station fixes for PMF and failed connections

[PATCH ath-next 0/3] wifi: ath10k: WCN3990 station fixes for PMF and failed connections

[Shunsuke Nagashima via B4 Relay]

These three patches fix two problems I hit on a comma four (SDM845,
WCN3990 hw1.0 SNOC, firmware WLAN.HL.2.0.c10-00459) in station mode.

Patch 1 sets the PMF peer flag on WCN3990. Without it, the firmware
sends ADDBA Request frames unprotected on PMF connections, no Block Ack
agreement is set up, and throughput on a 5 GHz WPA3 AP was about a
tenth of WPA2 on the same AP. On 5 GHz the protected Deauth also
carried PN 0, which one AP dropped, so the next association got
status 30.

Patches 2 and 3 are about the station vdev after a connection attempt
that failed before the vdev came up. ath10k stops the vdev but does not
bring it down, and this firmware then holds the Auth frames of the
next attempt for about 20 s. Patch 3 sends the down after the stop.
Patch 2 makes ath10k_bss_disassoc() skip its down for a vdev that is
not up, so that the down is not sent while the peer still exists.

Patch 1 does not depend on patches 2 and 3.

All results are from my own device runs on WCN3990 only. The test
kernel is v7.2-based and also carries three out-of-tree ath10k patches
(MAC address, in-order rx A-MSDU, SET_KEY wait).

Patch 3's notes also describe a rare data stall right after an
association. It also happened on a build without patches 2 and 3 and
on builds without patch 1, so no single patch of this series is needed
for it to happen; its cause is not known.

Related patches on the list:

 - David Heidelberg's RFC "wifi: ath10k: skip completion wait for
   pairwise key removal" (patchwork 14827446) adds a hw_params field at
   the same place as patch 1 (the end of the WCN3990 entry and of
   struct ath10k_hw_params). Whichever goes in second needs a small
   rebase in core.c and hw.h (keep both new fields).
 - Fabricio Akio's "wifi: ath10k: don't reset TxBF on disassociation"
   (patchwork 14880772) changes ath10k_bss_disassoc() next to patch 2.
   The two do not depend on each other; either applies on top of the
   other with git am -3.

AI-assistance disclosure:

I worked on this with Claude (mainly claude-opus-5-5 and
claude-fable-5-1) and Codex (gpt-6-astra). They helped go through the
logs and sniffer captures, draft the code changes and the debug builds,
and write the English of the commit messages and this letter. I
reviewed the code. All device tests ran on my own comma four, and the
results come from those runs.

---
Shunsuke Nagashima (3):
      wifi: ath10k: set the PMF peer flag on WCN3990
      wifi: ath10k: skip disassociation down for a station vdev that is not up
      wifi: ath10k: bring down a station vdev that never came up

 drivers/net/wireless/ath/ath10k/core.c |  1 +
 drivers/net/wireless/ath/ath10k/core.h |  2 ++
 drivers/net/wireless/ath/ath10k/hw.h   |  6 +++++
 drivers/net/wireless/ath/ath10k/mac.c  | 45 +++++++++++++++++++++++++++++-----
 4 files changed, 48 insertions(+), 6 deletions(-)
---
base-commit: cd026e68fdbf88b9cc522b76c7a9d92c9a41f709
change-id: 20261016-ath10k-series-v1-send-7761294833dd

Best regards,
--  
Shunsuke Nagashima <shunsuke@nagashi.ma>

[PATCH ath-next 1/3] wifi: ath10k: set the PMF peer flag on WCN3990

[Shunsuke Nagashima via B4 Relay]

From: Shunsuke Nagashima <shunsuke@nagashi.ma>

ath10k sets the PMF flag in the peer assoc command only when the
firmware file advertises ATH10K_FW_FEATURE_MFP_SUPPORT. That check came
with commit 90eceb3b5fb0 ("ath10k: set peer MFP flag in peer assoc
command"), because at that time "only firmwares 10.1.561 and above have
support for MFP". The WCN3990 firmware-5.bin files in linux-firmware do
not set that feature bit, so the flag is never sent on WCN3990, although
mac80211 negotiates PMF with the AP. ath11k and ath12k set the flag for
every MFP station.

On WCN3990 (firmware WLAN.HL.2.0.c10-00459) in station mode with PMF,
without the flag:

 - The firmware sends its ADDBA Request frames unprotected. The AP does
   not answer them, and no Block Ack agreement is set up, in both the
   2.4 GHz and the 5 GHz band. On a 5 GHz WPA3 AP, iperf3 to a wired
   host gave 22.6-31.6 Mbit/s up and 21.6-21.7 Mbit/s down, against
   280.2-283.0 / 264.5-272.3 Mbit/s with WPA2 on the same AP. A
   WPA2/WPA3 transition network gave the same low rate (23.4/22.7
   Mbit/s), because wpa_supplicant chose SAE with PMF there.

 - On 5 GHz, the protected Deauth sent at disconnect carried CCMP PN 0
   (56 of 56 in one capture). One AP dropped it, kept the old
   association and answered the next association with status 30, so a
   reconnect took 24.3-24.4 s instead of about 5 s. Another AP accepted
   the PN 0 Deauth. On 2.4 GHz the Deauth carried a live PN even
   without the flag. I could not tell whether the band or the AP's
   HT/VHT capability makes the difference.

With the flag set (this series, in a build without ath10k debug):

 - ADDBA Request frames were protected and Block Ack was used: on
   5 GHz with this series, and on 2.4 GHz with an earlier revision of
   it.
 - WPA3 on the same 5 GHz AP gave 264.2-279.0 Mbit/s up and
   236.8-246.2 Mbit/s down, and WPA2 283.4/261.7 Mbit/s. A 60-minute
   upload with 4 TCP streams averaged 277 Mbit/s, and a 30-minute
   download with 4 streams 230 Mbit/s.
 - Deauth frames carried a live PN, except when the Deauth was the first
   protected frame of the connection. With one MAC address, 100 of 100
   connect/disconnect cycles to the same AP connected, with no
   association rejection.
 - With an earlier revision of this series (the same code at run
   time): the transition network gave 276.9/249.6 Mbit/s, and in about
   8 hours of cycles, every association that followed an acknowledged
   Deauth with a current PN (not 0, and not older than a PN already
   used; about 1,300) got status 0.

The vendor driver for this firmware also sets the PMF peer flag for
every PMF connection. On the same device and firmware it reached
259.0-269.7 Mbit/s up with WPA3.

Add a hw_params flag and set it for WCN3990, so that the PMF peer flag
is set for MFP stations there as well. This also applies to MFP clients
when WCN3990 runs as an AP.

Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.2.0.c10-00459-QCAHLSWMTPLZ-1

Assisted-by: LLM sparse
Signed-off-by: Shunsuke Nagashima <shunsuke@nagashi.ma>
---
Notes:

- Other WCN3990 firmware builds: WLAN.HL.2.0-01387 also sent the
  5 GHz Deauth with PN 0 (38 of 38). In a capture shared by
  WLAN.HL.2.0.c10-00236 and c10-00459, it was 60 of 60, and the AP
  answered 28 of 28 next associations with status 30. Setting the same
  peer flag (through a debug switch, not with this exact patch) gave
  the higher throughput with both builds. Protected ADDBA and Block Ack
  were seen in the 01387 capture and in the capture shared by
  c10-00236 and c10-00459.

- AP mode: with an earlier revision, a WPA2-PSK (CCMP) AP on 2.4 GHz
  with one phone (station dump MFP yes, ping 20 of 20); with this
  series, a 5 GHz WPA2-PSK AP with optional PMF and two phones for 30
  minutes (MFP yes and tx failed 0 for both phones in all 30 station
  dumps). Nothing more than that was tested in
  AP mode.

- Not changed by this patch: even with the flag, the first protected
  Action frame of almost every association still goes out with PN 0.
  The vendor driver on the same firmware shows the same, so I think
  this comes from the firmware (an inference from outside observation
  only).

- Related: David Heidelberg's RFC "wifi: ath10k: skip completion wait
  for pairwise key removal" (patchwork 14827446) adds another hw_params
  field at the same place: the end of the WCN3990 entry in core.c and
  the end of struct ath10k_hw_params in hw.h. The two changes do not
  depend on each other, but whichever goes in second needs a small
  rebase in both files (keep both new fields).

- Test kernel: a v7.2-based kernel on a comma four (SDM845) that also
  carries three out-of-tree ath10k patches (MAC address, in-order rx
  A-MSDU, SET_KEY wait). None of them touches the peer assoc flags.
  The results without the flag and the other-firmware results came
  from a debug build of that kernel.

AI-assistance disclosure:

I worked on this with Claude (mainly claude-opus-5-5 and
claude-fable-5-1) and Codex (gpt-6-astra). They helped go through the
logs and sniffer captures, draft the code changes and the debug builds,
and write the English of the commit messages. I reviewed the code. All
device tests ran on my own comma four, and the results above come from
those runs.
---
 drivers/net/wireless/ath/ath10k/core.c | 1 +
 drivers/net/wireless/ath/ath10k/hw.h   | 6 ++++++
 drivers/net/wireless/ath/ath10k/mac.c  | 5 +++--
 3 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
index 7c2939cbde5f..c645f8d77ef3 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -746,6 +746,7 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
 		.use_fw_tx_credits = false,
 		.delay_unmap_buffer = true,
 		.mcast_frame_registration = false,
+		.peer_pmf_support = true,
 	},
 };
 
diff --git a/drivers/net/wireless/ath/ath10k/hw.h b/drivers/net/wireless/ath/ath10k/hw.h
index cd468b24bd33..88e48646be73 100644
--- a/drivers/net/wireless/ath/ath10k/hw.h
+++ b/drivers/net/wireless/ath/ath10k/hw.h
@@ -638,6 +638,12 @@ struct ath10k_hw_params {
 
 	/* The hardware support multicast frame registrations */
 	bool mcast_frame_registration;
+
+	/* The firmware handles PMF for a peer that has the PMF peer flag,
+	 * although the firmware file does not advertise
+	 * ATH10K_FW_FEATURE_MFP_SUPPORT.
+	 */
+	bool peer_pmf_support;
 };
 
 struct htt_resp;
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 8e604697d6c2..b30cdd1888f4 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -2254,8 +2254,9 @@ static void ath10k_peer_assoc_h_crypto(struct ath10k *ar,
 	}
 
 	if (sta->mfp &&
-	    test_bit(ATH10K_FW_FEATURE_MFP_SUPPORT,
-		     ar->running_fw->fw_file.fw_features)) {
+	    (test_bit(ATH10K_FW_FEATURE_MFP_SUPPORT,
+		      ar->running_fw->fw_file.fw_features) ||
+	     ar->hw_params.peer_pmf_support)) {
 		arg->peer_flags |= ar->wmi.peer_flags->pmf;
 	}
 }

-- 
Git-157)

[PATCH ath-next 2/3] wifi: ath10k: skip disassociation down for a station vdev that is not up

[Shunsuke Nagashima via B4 Relay]

From: Shunsuke Nagashima <shunsuke@nagashi.ma>

ath10k_bss_disassoc() sends WMI_VDEV_DOWN whether or not the vdev was
brought up. When mac80211 replays the station state during
reconfiguration, it can call it for a station whose connection attempt
is still pending: the vdev is started but not up, and the AP peer
exists. On WCN3990 firmware WLAN.HL.2.0.c10-00459, a VDEV_DOWN while
the peer still exists makes the firmware assert.

Send VDEV_DOWN from ath10k_bss_disassoc() only when arvif->is_up is
true, and log when it is skipped. The next patch brings down a station
vdev that never came up after the stop in
ath10k_mac_op_unassign_vif_chanctx().

Normal disconnects are not changed. With this patch and the next one,
in a CONFIG_ATH10K_DEBUG build, no DOWN was skipped in 5 WPA3 cycles
(4 of them with an association rejection with status 30 first) and
5 WPA2 cycles, and each normal disconnect sent exactly one VDEV_DOWN
from ath10k_bss_disassoc(). The change is not specific to WCN3990, but
only WCN3990 was tested.

Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.2.0.c10-00459-QCAHLSWMTPLZ-1

Assisted-by: LLM sparse
Signed-off-by: Shunsuke Nagashima <shunsuke@nagashi.ma>
---
Notes:

- This patch was run on the device only together with the next patch.
  The path it changes was run in a CONFIG_ATH10K_DEBUG build: a hardware
  restart through debugfs while an association was pending (waiting
  after a status 30 rejection). With only the next patch (the same code
  as in this series), the firmware asserted in the VDEV_DOWN from
  ath10k_bss_disassoc() 29 of 29 times. With this patch added, it did
  not assert (0 of 5), and the down was skipped each time. The debugfs
  restart path itself gives SMMU fault and IRQ warnings, with or without
  this patch.

- Related: Fabricio Akio's "wifi: ath10k: don't reset TxBF on
  disassociation" (patchwork 14880772) changes ath10k_bss_disassoc()
  next to this patch. The two do not depend on each other; either one
  applies on top of the other with git am -3.

- Only WCN3990 was tested (hw1.0 SNOC, WLAN.HL.2.0.c10-00459). TDLS,
  P2P client and multiple vifs were not tested.

- Test kernel: a v7.2-based kernel on a comma four (SDM845) that also
  carries three out-of-tree ath10k patches (MAC address, in-order rx
  A-MSDU, SET_KEY wait).

AI-assistance disclosure:

I worked on this with Claude (mainly claude-opus-5-5 and
claude-fable-5-1) and Codex (gpt-6-astra). They helped go through the
logs and sniffer captures, draft the code changes and the debug builds,
and write the English of the commit messages. I reviewed the code. All
device tests ran on my own comma four, and the results above come from
those runs.
---
 drivers/net/wireless/ath/ath10k/mac.c | 19 +++++++++++++++----
 1 file changed, 15 insertions(+), 4 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index b30cdd1888f4..88ebcd2d1110 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -3199,10 +3199,21 @@ static void ath10k_bss_disassoc(struct ieee80211_hw *hw,
 	ath10k_dbg(ar, ATH10K_DBG_MAC, "mac vdev %i disassoc bssid %pM\n",
 		   arvif->vdev_id, arvif->bssid);
 
-	ret = ath10k_wmi_vdev_down(ar, arvif->vdev_id);
-	if (ret)
-		ath10k_warn(ar, "failed to down vdev %i: %d\n",
-			    arvif->vdev_id, ret);
+	/* During hw restart reconfiguration, mac80211 replays disassociation
+	 * for a station with a pending connection attempt. The vdev is started
+	 * but not up, and the AP peer exists. A down then asserts at least
+	 * WCN3990 firmware.
+	 */
+	if (arvif->is_up) {
+		ret = ath10k_wmi_vdev_down(ar, arvif->vdev_id);
+		if (ret)
+			ath10k_warn(ar, "failed to down vdev %i: %d\n",
+				    arvif->vdev_id, ret);
+	} else {
+		ath10k_dbg(ar, ATH10K_DBG_MAC,
+			   "mac vdev %i disassoc bssid %pM skip down (not up)\n",
+			   arvif->vdev_id, arvif->bssid);
+	}
 
 	arvif->def_wep_key_idx = -1;
 

-- 
Git-157)

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

[Shunsuke Nagashima via B4 Relay]

From: Shunsuke Nagashima <shunsuke@nagashi.ma>

When a connection attempt fails before the station vdev is brought up
(authentication timeout, SAE failure, association rejected, or an Auth
burst the AP never acknowledged), mac80211 removes the AP station and
unassigns the channel context. ath10k deletes the peer and sends
WMI_VDEV_STOP, but no WMI_VDEV_DOWN: for a station vdev that never came
up, the down would only come from ath10k_bss_disassoc(), which a failed
connection attempt never reaches.

On WCN3990 firmware WLAN.HL.2.0.c10-00459 and c10-00236, the Auth frames
of the next attempt on the same vdev are then not transmitted
(management tx completion status "discard") until about 20 s after the
first Auth frame of the failed attempt. In sniffer captures, 241 such
holds ended 19.94-20.03 s after that frame. Some lasted longer (in one
overnight run, 29 of 226 had not ended when the cycle ended), for
example when user space gave up on the attempt during the hold. Probe
requests still go out. The state belongs to the vdev: an attempt to
another network (another BSS on the same AP) on the same vdev was held
too (2 of 2), and re-creating the vdev cleared it (2 of 2). This happens
on WPA2 networks as well as WPA3. An older firmware build,
WLAN.HL.2.0-01387, did not hold the frames (0 of 7 reconnects after
status 30).

With the stock driver in its production configuration, a reconnect
after an association rejection with status 30 took 24.3 and 24.4 s
(2 of 2). In an overnight run of PMF connections on the stock driver,
using a local firmware-5.bin with the MFP feature bit set (the same
effect as the first patch of this series), 142 of 6946 connection
cycles failed, and every one of the 142 failures included such a hold.

Until commit 077efc8c42e8 ("ath10k: clean up sta auth/assoc code")
ath10k_bss_disassoc() ran on every AP station removal and sent
VDEV_STOP followed by VDEV_DOWN, with the comment "If we don't call
VDEV-DOWN after VDEV-STOP FW will remain active". That commit moved
the stop to the station removal (today the channel context
unassignment) and kept the down only for the disassociation, so a
station vdev that never came up has been stopped without a down ever
since. ath12k_mac_station_remove() still sends the down on every
station removal of a station vdev, whether or not it came up.

Remember whether the vdev has been brought up since it was last
started and, in ath10k_mac_op_unassign_vif_chanctx(), send
WMI_VDEV_DOWN after WMI_VDEV_STOP for a station vdev that never came
up. Checking is_up alone would not do: ath10k_bss_disassoc() clears
it after sending its own down, so every normal disconnect would get a
second down. Normal disconnects, where the vdev was up, are not changed.
The order matters: the down has to follow the peer deletion and the
stop, because on this firmware a down while the peer still exists
makes the firmware assert. AP, IBSS and monitor vdevs are not touched.
Nothing in the change is specific to WCN3990, but only WCN3990 was
tested.

With this patch alone in the production configuration (no ath10k
debug), 6 of 6 reconnects after an association rejection with status 30
took 6.8-9.2 s. Sniffer captures showed every Auth frame of the next
attempt on the air at once, with none held. All 105 WPA3 cycles (103
with a status-30 rejection first) and all 50 WPA2 cycles connected,
with no kernel WARN. Link loss during a pending association (3 of 3),
rfkill, AP mode, and an SAE password mismatch with a firmware file
having the MFP feature bit also worked. A further 480 cycles, half
WPA3 and half WPA2, all connected.

With all three patches of this series (an earlier form of the first
patch) in the production configuration, the next correct connection
after an SAE password mismatch on the same vdev sent its first Auth
0.18-0.23 s after the failed attempt ended and connected (4 of 4; with
the final version of the series, 4 of 4 connected in 0.76-0.85 s). In
7,100 cycles over about 10 hours (WPA3, WPA2/WPA3 transition and WPA2),
no Auth was held in the first 8 hours, which were checked on the air:
all 13,511 Auth transmissions that mac80211 logged there were seen on
the air.

With a CONFIG_ATH10K_DEBUG build of this patch together with the
previous patch, a normal disconnect sent exactly one VDEV_DOWN, from
ath10k_bss_disassoc(), and a failed attempt one VDEV_DOWN after
VDEV_STOP (5 WPA3 cycles, 4 of them with status 30 first, and 5 WPA2
cycles).

Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.2.0.c10-00459-QCAHLSWMTPLZ-1

Assisted-by: LLM sparse
Signed-off-by: Shunsuke Nagashima <shunsuke@nagashi.ma>
---
Notes:

- Only WCN3990 was tested (hw1.0 SNOC, WLAN.HL.2.0.c10-00459). TDLS,
  P2P client and multiple vifs were not tested.

- An earlier revision with the same WMI command order ran 4603 cycles
  overnight with 2229 failed attempts; the next attempt's first Auth
  went out at once after every one of them.

- A separate, rare problem: right after an association, all host data
  is dropped (HTT tx completion status 5) for about 45-59 s. On the air,
  after EAPOL M4 the station sends no data, no ADDBA and gets no Block
  Ack from the AP; it only sends QoS Null frames, and the protected
  Deauth at the end carries PN 0. On one AP, I saw it 3 times in 14,937
  PMF associations on three earlier test builds (an earlier revision of
  this patch alone; this patch and the previous one in a debug build;
  all three patches with an earlier form of the first patch). Two of
  these three builds did not set the PMF peer flag (no first patch, and
  the stock firmware file). On a different AP (a WPA3-only mobile
  router), with a firmware file having the MFP feature bit, it happened
  2 times in 27,360 SAE/PMF connection cycles over about 42 hours with a
  debug build without patches 2 and 3 (whose vdev down and
  disassociation code is the stock code), and once in about 36,800
  SAE/PMF connection cycles with the final version of the series. So no
  single patch of this series is needed for it to happen. These counts
  come from different setups and are not a controlled comparison. The
  cause is not known.

- Test kernel: a v7.2-based kernel on a comma four (SDM845) that also
  carries three out-of-tree ath10k patches (MAC address, in-order rx
  A-MSDU, SET_KEY wait).

AI-assistance disclosure:

I worked on this with Claude (mainly claude-opus-5-5 and
claude-fable-5-1) and Codex (gpt-6-astra). They helped go through the
logs and sniffer captures, draft the code changes and the debug builds,
and write the English of the commit messages. I reviewed the code. All
device tests ran on my own comma four, and the results above come from
those runs.
---
 drivers/net/wireless/ath/ath10k/core.h |  2 ++
 drivers/net/wireless/ath/ath10k/mac.c  | 21 +++++++++++++++++++++
 2 files changed, 23 insertions(+)

diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
index dfee432615eb..373b84082128 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -605,6 +605,8 @@ struct ath10k_vif {
 	union {
 		struct {
 			u32 uapsd;
+			/* vdev was brought up since it was last started */
+			bool was_up;
 		} sta;
 		struct {
 			/* 512 stations */
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 88ebcd2d1110..a95c016cbb34 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -3170,6 +3170,7 @@ static void ath10k_bss_assoc(struct ieee80211_hw *hw,
 	}
 
 	arvif->is_up = true;
+	arvif->u.sta.was_up = true;
 
 	ath10k_mac_set_sar_power(ar);
 
@@ -9023,6 +9024,9 @@ ath10k_mac_op_assign_vif_chanctx(struct ieee80211_hw *hw,
 
 	arvif->is_started = true;
 
+	if (arvif->vdev_type == WMI_VDEV_TYPE_STA)
+		arvif->u.sta.was_up = false;
+
 	ret = ath10k_mac_vif_setup_ps(arvif);
 	if (ret) {
 		ath10k_warn(ar, "failed to update vdev %i ps: %d\n",
@@ -9106,6 +9110,23 @@ ath10k_mac_op_unassign_vif_chanctx(struct ieee80211_hw *hw,
 		ath10k_warn(ar, "failed to stop vdev %i: %d\n",
 			    arvif->vdev_id, ret);
 
+	/* A connection attempt that fails before the vdev is up never reaches
+	 * ath10k_bss_disassoc(), so the station vdev would be stopped without
+	 * ever being brought down. At least WCN3990 firmware then holds the
+	 * Auth frames of the next attempt for about 20 seconds. Bring it down
+	 * here, after the peer is gone and the vdev is stopped: a down while
+	 * the peer still exists asserts the firmware.
+	 */
+	if (arvif->vdev_type == WMI_VDEV_TYPE_STA && !arvif->u.sta.was_up) {
+		ath10k_dbg(ar, ATH10K_DBG_MAC, "mac vdev %i down (never up)\n",
+			   arvif->vdev_id);
+
+		ret = ath10k_wmi_vdev_down(ar, arvif->vdev_id);
+		if (ret)
+			ath10k_warn(ar, "failed to down vdev %i after stop: %d\n",
+				    arvif->vdev_id, ret);
+	}
+
 	arvif->is_started = false;
 
 	mutex_unlock(&ar->conf_mutex);

-- 
Git-157)

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

[James Prestwood]

Hi Shunsuke,

On 10/15/26 5:17 PM, Shunsuke Nagashima via B4 Relay wrote:
> From: Shunsuke Nagashima <shunsuke@nagashi.ma>
>
> When a connection attempt fails before the station vdev is brought up
> (authentication timeout, SAE failure, association rejected, or an Auth
> burst the AP never acknowledged), mac80211 removes the AP station and
> unassigns the channel context. ath10k deletes the peer and sends
> WMI_VDEV_STOP, but no WMI_VDEV_DOWN: for a station vdev that never came
> up, the down would only come from ath10k_bss_disassoc(), which a failed
> connection attempt never reaches.
>
> On WCN3990 firmware WLAN.HL.2.0.c10-00459 and c10-00236, the Auth frames
> of the next attempt on the same vdev are then not transmitted
> (management tx completion status "discard") until about 20 s after the
> first Auth frame of the failed attempt. In sniffer captures, 241 such
> holds ended 19.94-20.03 s after that frame. Some lasted longer (in one
> overnight run, 29 of 226 had not ended when the cycle ended), for
> example when user space gave up on the attempt during the hold. Probe
> requests still go out. The state belongs to the vdev: an attempt to
> another network (another BSS on the same AP) on the same vdev was held
> too (2 of 2), and re-creating the vdev cleared it (2 of 2). This happens
> on WPA2 networks as well as WPA3. An older firmware build,
> WLAN.HL.2.0-01387, did not hold the frames (0 of 7 reconnects after
> status 30).

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,

James

[1] 
https://lore.kernel.org/linux-wireless/441e9883-1efc-498b-ba33-6a4f12443f3b@gmail.com/