After a yum upgrade last night, the Wifi on my Dell Vostro 3360 seems to be misbehaving. This has a Qualcomm Atheros AR9462 chip and the ath9k driver is loaded:
Other wireless devices on the home net are fine. The Fedora 35 laptop is getting intermittent “internet down” errors in Chrome, and speed tests are failing. I have shuffled Wifi channels and rebooted my AT&T Pace router a couple of times. My Wifi signal seems to be good (CHUM BUCKET is my SSID):
> BSSID SSID MODE CHAN RATE SIGNAL BARS
> DC:7F:A4:0C:C1:2D CHUM BUCKET Infra 9 130 Mbit/s 87 ▂▄▆█
> DC:7F:A4:0C:C1:30 -- Infra 9 130 Mbit/s 84 ▂▄▆█
> DC:7F:A4:0C:C1:36 CHUM BUCKET Infra 161 540 Mbit/s 67 ▂▄▆_
Anyone else seeing this after a recent update/upgrade?
yum is a symlink to dnf now, so it won’t make a difference.
@wsanders : can you check the logs to see if there’s anything there that’s related to this? It could be a wireless issue, but it could also be related to dns name resolution or something else, so a look at the logs will give us a starting point for our debugging.
Yes, there is a ton of stuff from wpa_supplicant and network manager that started showing up after the update, like
Mar 20 12:33:40 elvostro wpa_supplicant[1056]: RRM: Ignoring radio measurement request: Not RRM network
Mar 20 12:33:43 elvostro wpa_supplicant[1056]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-54 noise=-93 txrate=216000
and the occasional
Mar 20 12:31:14 elvostro wpa_supplicant[1056]: wlp1s0: CTRL-EVENT-REGDOM-CHANGE init=BEACON_HINT type=UNKNOWN
Mar 20 12:31:16 elvostro wpa_supplicant[1056]: wlp1s0: CTRL-EVENT-REGDOM-CHANGE init=BEACON_HINT type=UNKNOWN
Mar 20 12:31:16 elvostro kernel: wlp1s0: authenticate with dc:7f:a4:0c:c1:36
Mar 20 12:31:16 elvostro wpa_supplicant[1056]: wlp1s0: SME: Trying to authenticate with dc:7f:a4:0c:c1:36 (SSID='CHUM BUCKET' freq=5805 MHz)
Mar 20 12:31:16 elvostro kernel: wlp1s0: send auth to dc:7f:a4:0c:c1:36 (try 1/3)
Mar 20 12:31:16 elvostro kernel: wlp1s0: authenticated
And these cascade down to DHCP and avahi causing various messes.
I’m trying to sort it out and see if there is a pattern. All these Network Manager and wpa_supplicant errors weren’t in the log before the update yesterday.
The laptop is fairly usable with a status IPV4 since the addresses are not flapping anymore. Still seeing occasional blocks of
Mar 20 14:58:16 elvostro wpa_supplicant[1065]: RRM: Ignoring radio measurement request: Not RRM network
Mar 20 14:58:16 elvostro wpa_supplicant[1065]: RRM: Ignoring radio measurement request: Not RRM network
Mar 20 14:58:22 elvostro wpa_supplicant[1065]: wlp1s0: CTRL-EVENT-BEACON-LOSS
Mar 20 14:58:23 elvostro wpa_supplicant[1065]: wlp1s0: CTRL-EVENT-BEACON-LOSS
Mar 20 14:58:24 elvostro wpa_supplicant[1065]: wlp1s0: CTRL-EVENT-BEACON-LOSS
Mar 20 14:58:25 elvostro wpa_supplicant[1065]: wlp1s0: CTRL-EVENT-BEACON-LOSS
Mar 20 14:58:26 elvostro wpa_supplicant[1065]: wlp1s0: CTRL-EVENT-BEACON-LOSS
Mar 20 14:58:26 elvostro wpa_supplicant[1065]: wlp1s0: CTRL-EVENT-DISCONNECTED bssid=dc:7f:a4:0c:c1:36 reason=4 locally_generated=1
But the effect is less disruptive with a static IP.
The “RRM: Ignoring radio measurement request” errors have been in the logs for weeks, but the SIGNAL-CHANGE and BEACON-LOSS errors only starting showing up after last night’s update.
For now, solution is to downgrade to 5.16.12-200.fc35 kernel and drivers. I am not sure why this didn’t work earlier, except that I did it from grub. This time, I booted the old kernel, then deleted the 5.16.15-201 packages, and then rebooted just to make sure none of the new drivers loaded (could they? I don’t think so actually. It’s been a long time - years! - since a kernel upgrade broke my system!)
Worth skimming the list to see what fits your issue best, and then maybe there’s a workaround in the bug. Otherwise, worth bumping it with whatever information you can provide.
FWIW wpa_supplicant doesn’t seem to have been updated in the 5.16.12-200 to 5.16.15-201 and looking the the kernel.org git, the ath9k driver hasn’t been touched in a long time.
The following workarounds did not help:
Disabling bluetooth
IPV4 vs IPV6
5 vs 2.4 band
Not my hardware, I have 2 Vostros with same chipsets and after downgrade to 5.16.12-200 both are fine.
I don’t have a non-802.11n or -802.11ac router/AP to test with.
“Unfortunately the patch that introduced that regression is a CVE fix. I am tracking the upstream discussion to see if there is a fix.”
I let him know I’d be happy with a workaround/patch that lobotomizes wpa_supplicant or the driver’s interaction with ACPI/DBUS if that is a root cause.
Thanks for opening the bug. Hopefully there’ll be a fix soon.
I see the bug has been marked as a private one—if there isn’t any personal information there, could you make it public so that everyone can see it? (Only package maintainers and the reporter can see private bugs)
Kernel 5.16.18 has just been released by Fedora today and this appears to have greatly mitigated/solved the issue for me with a Qualcomm Atheros adapter. Before this kernel I could not complete a WiFi speed test, now I see normal speeds.
The release changelog describes a revert:
Revert “swiotlb: rework “fix info leak with DMA_FROM_DEVICE”” (Linus Torvalds)