Public bug reported:
The pc-kernel snap refresh from 7.0.0-28.28 (rev 3672) to 7.0.0-31.31 (rev 3699)
breaks Wi-Fi data traffic on a MediaTek MT7925 [14c3:7925] (Filogic 360).
The distinguishing symptom is that connection management keeps working while the
data path does not. The card scans, authenticates, completes the WPA 4-way
handshake and obtains its DHCP lease -- the same address every time -- then sits
in the "activated" state looking healthy while almost no traffic completes. DNS
resolution fails essentially continuously.
No firmware crash, watchdog reset, or driver error is logged at any point. The
link reports itself as connected with strong signal throughout, which makes this
easy to misdiagnose as a DNS, VPN, or upstream network problem.
Reverting to 7.0.0-28.28 restores full function immediately and
reproducibly.
[KEY EVIDENCE: FAILURE WHILE THE LINK IS PROVABLY STABLE]
On a 12-minute boot of 7.0.0-31 there is a window from 12:21:11 to 12:29:20 --
just over eight minutes -- during which the interface was continuously
associated, with ZERO deauthentication events and the DHCP lease held.
Within that stable window there were 12 distinct DNS resolution failures,
roughly one per minute, spread evenly across it.
This rules out reconnection churn as the cause. The link was up, authenticated
and addressed, and traffic still did not pass. The packet loss is the primary
fault; the disconnects are secondary.
[DNS FAILURES, BAD VS GOOD KERNEL]
boot kernel duration "Temporary failure NoDnsConnectivity
in name resolution"
---- ---------------- -------- ------------------ -----------------
-4 7.0.0-28-generic 16h 09m 0 0
-1 7.0.0-31-generic 12m 42 12
Zero failures in sixteen hours on the old kernel; 42 in twelve minutes
on the new.
[VERSIONS]
GOOD BAD
snap revision pc-kernel rev 3672 pc-kernel rev 3699
version 7.0.0-28.28 7.0.0-31.31
kernel 7.0.0-28-generic 7.0.0-31-generic
MT7925 HW/SW build 20260106153007a 20260605184651a
MT7925 WM firmware 20260106153120 20260605184805
PRIME SUSPECT: the kernel snap carries the MT7925 firmware blobs, and 7.0.0-31
bumps them from a 2026-01-06 build to a 2026-06-05 build. Given that association
and control-plane exchanges succeed while bulk data silently fails, a
firmware-side RX/TX data-path fault (aggregation, offload, or data-path key
handling) seems more likely than a change in the mt7925e/mt76 driver code.
These two should be bisected independently.
[REPRODUCTION]
1. On MT7925 hardware, run pc-kernel 7.0.0-28.28 -- Wi-Fi is stable.
2. snap refresh pc-kernel to 7.0.0-31.31 (rev 3699). Reboot.
3. Associate to a 5 GHz AP. Association, 4-way handshake and DHCP all succeed;
the interface reaches "activated" and holds a valid lease.
4. Attempt normal use. Traffic largely does not complete; DNS fails repeatedly
while the link continues to report itself as connected.
5. snap revert pc-kernel to rev 3672 and reboot -- problem disappears entirely.
Performed twice on this machine (two separate boots of 7.0.0-31, two
reverts).
[DISCONNECTS, CORRECTLY ATTRIBUTED]
Six deauthentications occurred on the 12-minute boot, but they are not all
spontaneous. By the NetworkManager state-change reason recorded at the same
instant:
12:20:12 activated -> unavailable (reason 'none') SPONTANEOUS reset
12:21:04 activated -> deactivating ('new-activation') operator reconnect
12:21:06 activated -> unavailable (reason 'none') SPONTANEOUS reset
12:29:20 activated -> deactivating ('new-activation') operator reconnect
12:29:21 activated -> unavailable (reason 'none') SPONTANEOUS reset
12:30:25 activated -> deactivating ('unmanaged') shutdown for reboot
So three spontaneous interface resets in 12 minutes, not six; the rest were the
operator manually reconnecting to try to recover, plus shutdown. The 16-hour
7.0.0-28 boot recorded two deauthentications in total.
The spontaneous ones show the supplicant returning to "internal-starting",
indicating the interface was re-initialised underneath userspace rather than
roamed by choice -- consistent with a driver- or firmware-level reset.
[HEALTHY BASELINE ON 7.0.0-28, FOR CONTRAST]
ping 172.16.96.1 (gateway) 20 packets, 0% loss, rtt 2.203/2.825/6.265 ms
ping 1.1.1.1 20 packets, 0% loss, rtt 7.042/9.424/15.675 ms
ping 8.8.8.8 20 packets, 0% loss, rtt 7.739/10.719/15.754 ms
signal -46 dBm
rx bitrate 258.0 MBit/s HE-MCS 10 HE-NSS 2
tx bitrate 286.7 MBit/s HE-MCS 11 HE-NSS 2
tx retries 6 (of 9429 tx packets)
tx failed 0
beacon loss 0
Signal is strong and error counters are essentially zero, so this is not a
weak-signal or RF-congestion problem that merely coincided with the update.
[CAVEATS FOR ANYONE REPRODUCING]
1. THE LOSS PERCENTAGE WAS NOT MEASURED. I observed roughly 80% packet loss
while running 7.0.0-31, severe enough to make the machine unusable, but no
ping statistics or interface counters were captured during either 7.0.0-31
boot and those counters do not survive a reboot. Treat 80% as a reported
magnitude, not a measurement. What the logs independently establish is the
42 DNS failures, the 12 failures inside a provably stable 8-minute window,
and the three spontaneous interface resets -- all specific to 7.0.0-31.
2. DNS ON THIS HOST IS DoH THROUGH A CLOUDFLARE WARP TUNNEL
(operation_mode: WarpWithDnsOverHttps, tunnel MTU 1280), not plain UDP/53.
DNS therefore depends on the tunnel, which depends on the Wi-Fi data path --
which is why DNS failure is such a visible symptom here. A machine without
WARP may present less dramatically, as general packet loss rather than
near-total DNS failure. Do not assume the absence of total DNS failure means
the bug is absent; test the data path directly.
The most useful capture on 7.0.0-31, while associated and stable, is:
ping -c 200 -i 0.2 <gateway> # on-link, bypasses both tunnel and DNS
ip -s link show wlp194s0
iw dev wlp194s0 station dump
[IMPACT]
linux-image-generic-hwe-26.04 currently has candidate 7.0.0-31.31 in
resolute-updates, so this is the version being handed out. Any MT7925
(Filogic 360) system taking the update is likely to hit this. The MT7925 is
common in current AMD laptops.
The silent nature of the failure makes it worse than an outright breakage: the
card reports itself as connected with a valid lease and good signal, so affected
users are likely to blame their router, ISP, or VPN rather than the kernel.
[CURRENT MITIGATION]
snap revert pc-kernel # back to rev 3672 / 7.0.0-28.28
snap refresh --hold pc-kernel # prevents automatic re-update
Both revisions are held; rev 3699 is retained but disabled, so it remains
available for further testing without a re-download.
[REQUESTED]
1. Confirm whether the MT7925 firmware bump (2026-01-06 -> 2026-06-05) is the
cause, independent of the mt76/mt7925e driver changes in 7.0.0-31.
2. If so, consider reverting the firmware blob or gating it pending a fix.
3. Investigate why the data path fails silently while association, EAPOL and
DHCP all succeed -- the absence of any logged error is itself a defect.
[SYSTEM]
Ubuntu 26.04.1 LTS (resolute), Ubuntu Core / snap-delivered kernel, x86_64
Wi-Fi: MEDIATEK MT7925 802.11be 160MHz 2x2 PCIe [Filogic 360] [14c3:7925]
Subsystem: Lenovo [17aa:e025], PCI c2:00.0, driver mt7925e (mt76)
AP: ch 116 (5580 MHz), 20 MHz, WPA2/3
Full diagnostics attached (mt7925-diagnostics.txt).
** Affects: linux (Ubuntu)
Importance: Undecided
Status: New
** Attachment added: "regression-update resolute mt7925"
https://bugs.launchpad.net/bugs/2167019/+attachment/5999324/+files/mt7925-diagnostics.txt
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2167019
Title:
MT7925 Wi-Fi: silent data-path packet loss on associated link after
pc-kernel 7.0.0-31.31
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2167019/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
