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 subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb 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 Status in linux package in Ubuntu: New Bug description: 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). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2167019/+subscriptions
Комментариев нет:
Отправить комментарий