ath12k: spurious beacon-loss disconnects on WCN7850 (regression in 7.2.6)
Izzet Beltir
ath12k-bug-list-09192026 at 0pe.de
Fri Oct 9 07:50:11 PDT 2026
Hi,
#regzbot introduced: v7.2.4..v7.2.6
#regzbot title: ath12k: spurious beacon loss disconnects on WCN7850
since kernel 7.2.6 my WCN7850 drops a perfectly working connection 20-28
times a day with "Connection to AP lost". The disconnects are spurious:
the link is demonstrably alive at the moment it is torn down.
In short: beacon accounting stalls while the link is alive. Unicast data
keeps flowing in both directions at normal latency, but the driver stops
accounting received beacons, so mac80211 sees beacon loss and tears down
the connection. It does the right thing with wrong input.
The regression window is narrow and clean: kernel 7.2.4 ran for 11 days
without a single event, 7.2.6 and 7.2.9 produce 20-28 per day on the
same machine, same AP, same channel, same configuration. The WCN7850
firmware blob is unchanged (byte-identical version string and build
timestamp), and only the two ath12k modules changed between 7.2.4 and
7.2.6. Details and measurements below.
Hardware / software
-------------------
Device Qualcomm WCN7850 hw2.0, PCI 17cb:1107 (rev 01)
subsystem 17aa:e0e6 (Lenovo laptop)
Driver ath12k_wifi7_pci (modules: ath12k, ath12k_wifi7)
Firmware
WLAN.HMT.1.1.c7-00108-QCAHMTSWPL_V1.0_V2.0_SILICONZ_UPSTREAM-3
fw_version 0x1103006c, fw_build_timestamp 2026-03-06 09:10
(linux-firmware 20260916; see "firmware ruled out" below)
Distro Arch Linux, wpa_supplicant 2.12, NetworkManager 1.58.1
Setup
-----
AP AVM FRITZ!Box 5690 Pro, 2.4 GHz, channel 10 (2457 MHz),
20 MHz
HE (Wi-Fi 6), WPA2-PSK/CCMP, no PMF
beacon interval 100 TU, DTIM 1
Client single link, no MLO, no EHT
pinned to 2.4 GHz and to one BSSID via NetworkManager
power save disabled (NM 802-11-wireless.powersave=2;
"iw dev wlan0 get power_save" reports off)
Signal stable -51/-52 dBm, no roaming candidates
Symptom
-------
kernel: wlan0: Connection to AP 1c:xx:xx:xx:xx:xx lost
wpa_supplicant: CTRL-EVENT-DISCONNECTED bssid=1c:xx:xx:xx:xx:xx reason=4
locally_generated=1
preceded ~3 s earlier by:
wpa_supplicant: nl80211: Beacon loss event
wlan0: Event BEACON_LOSS (53) received
Each drop costs 9-11 s of connectivity (teardown plus reassociation).
They arrive in bursts of 2-9 within a few minutes, with hours of normal
operation in between. Rate: 19-28 per day.
Key observation: the link is alive while beacons are "lost"
-----------------------------------------------------------
I sampled "iw dev wlan0 station dump" once per second and ran a 1 Hz
ICMP ping to the AP throughout. Taking one drop (2026-10-09 16:08:27) as
the example:
normal operation, 14 s window beacon rx: +122 (~8.7/s, matches
100 TU)
event window, 15 s window beacon rx: +1 (expected ~150)
During that same 15 s event window the ping to the AP was uninterrupted:
15 requests, 15 replies, mean 5.88 ms, max 18.0 ms, zero loss. The last
reply arrived 1 s before the disconnect. Packet loss only starts *after*
"Connection to AP lost".
Per-second trace of the event (beacon rx delta "d", signal, connected time):
16:08:10 rx=141930 d=- loss=37 sig=-51 conn=15048
16:08:11 rx=141930 d=0 loss=37 sig=-51 conn=15049 <- beacons stop
16:08:12 rx=141931 d=1 loss=37 sig=-52 conn=15050
16:08:13 rx=141931 d=0 loss=37 sig=-52 conn=15051
... (d=0 for 13 consecutive seconds, ping fine throughout)
16:08:24 rx=141931 d=0 loss=37 sig=-52 conn=15062 <- BEACON_LOSS
16:08:25 rx=141931 d=0 loss=38 sig=-52 conn=15063 <- counter
bumps
16:08:27 Connection to AP lost
Inside a burst the pattern repeats immediately after reassociation:
"beacon rx" reaches 1 and never increments again, while the ping keeps
working, and 16 s later the connection is dropped once more:
16:08:36 rx=1 conn=0 (reassociated)
16:08:38 .. 16:08:51 14 consecutive ping replies, 3.6-5.3 ms
16:08:48 BEACON_LOSS
16:08:51 Connection to AP lost
Notes on two things that might look like explanations but are not:
- No scan precedes the event. Scan entries appear in the
wpa_supplicant debug
log only *after* the disconnect, triggered by it. An off-channel
excursion
would also have broken the ping, which it did not.
- The "signal" value stays at -52 dBm during the gap, but that is
simply the
last measured value and goes stale when no frames are accounted; it
is not
evidence of link health. The ping is.
My reading: the driver stops delivering or accounting received beacons
to mac80211 while the data path is unaffected. mac80211 then does the
right thing with wrong input. The 16 s from "beacons stop" to
"connection lost" is the normal mac80211 beacon-loss timeout, not a
stuck timer.
Regression window
-----------------
Per-day count of "Connection to AP lost" from the journal, same machine,
same AP, same channel, same configuration:
kernel 7.1.5 / 7.1.8 August 1-2 events on 6 individual days
kernel 7.2.4.arch1-2 Sep 11 - Sep 22 0 events in 11 days
kernel 7.2.6.arch2-1 from Oct 05 19, 28, 22 per day
kernel 7.2.9.arch1-1 from Oct 08 25, 15 (partial day) per day
The machine was powered off between Sep 22 and Oct 05, so 7.2.6 first
ran on Oct 05 - the day the symptom starts.
Module srcversion across the three Arch kernel packages:
7.2.4 7.2.6 7.2.9
ath12k 54D60149 520EAA1F 520EAA1F changed, then stable
ath12k_wifi7 CA1FFE3A C987B2F0 C987B2F0 changed, then stable
mac80211 8E5D5C40 2FEA9189 33EF1A59 changes every release
cfg80211 33574877 6ECF9FE4 2182EA71 changes every release
Both ath12k modules changed exactly between 7.2.4 and 7.2.6 and are
unchanged in 7.2.9. That matches the symptom pattern (7.2.4 clean, 7.2.6
and 7.2.9 equally affected), whereas mac80211/cfg80211 change in every
release and would predict a difference between 7.2.6 and 7.2.9 that is
not there.
Firmware ruled out
------------------
linux-firmware-atheros was updated 20260910 -> 20260916 in the same
transaction as the kernel, but the loaded WCN7850 blob is unchanged. The
version string and build timestamp logged in August and today are
byte-identical:
fw_version 0x1103006c fw_build_timestamp 2026-03-06 09:10
fw_build_id QC_IMAGE_VERSION_STRING=WLAN.HMT.1.1.c7-00108-...-UPSTREAM-3
What I have not done
--------------------
- No commit-level bisection. The window is package-level, 7.2.4 to 7.2.6
(Arch Linux kernel packages, built from the stable tree). I can test
patches or a bisect build if that helps.
- I have not reproduced it on demand. Bursts appear roughly every
four hours
without an identifiable trigger; local systemd timers do not correlate.
One caveat I want to state rather than hide: a second 2.4 GHz client on
the same AP (older laptop, Wi-Fi 4, different chipset, not ath12k) also
re-associates frequently in the AP's event log. It already did so in
August while this machine was stable for 24 h straight, so I believe it
is an unrelated pre-existing issue - but I cannot fully exclude a shared
cause at the AP.
Questions
---------
- Is this a known regression in 7.2.6?
- Are the recent "ath12k: fixes to improve beacon-miss handling"
patches on
linux-wireless related? They describe MLO operation, and this is a
single
non-MLO link on 2.4 GHz, so I am unsure whether they apply.
- Is there a debug knob that would show whether beacons reach the
host at all
(as opposed to not being accounted)? ath12k exposes only debug_mask and
ftm_mode here.
Attached: ath12k-logs-core.tar.gz (77 kB) with the 1 Hz station-dump
samples and the kernel log for the observation window. All MAC addresses
are masked, neighbouring SSIDs redacted, and all hexdump payloads in the
supplicant log removed.
I also have, and will send to anyone who asks, the 1 Hz ping log, the 5
s samples with retry counters, kernel messages across all October boots,
and the sanitised wpa_supplicant debug log - about 410 kB packed, which
is why they are not attached here.
Happy to run tests or try patches.
Regards,
Izzet Beltir
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ath12k-logs-core.tar.gz
Type: application/gzip
Size: 78543 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/ath12k/attachments/20261009/e2b18c88/attachment-0001.gz>
More information about the ath12k
mailing list