Latest Fedora 35 kernel update 5.16.15-201 breaks ath9k Wifi

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:

# modinfo ath9k:
filename: /lib/modules/5.16.15-201.fc35.x86_64 …

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?

1 Like

Fedora use dnf as a package manager.
We recommended to a dnf update.

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.

Interesting, Fedora is flapping between two ip addresses:. That can sure make a small problem a lot worse!

3: wlp1s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
    link/ether 08:ed:b9:69:86:45 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.65/24 brd 192.168.1.255 scope global dynamic noprefixroute wlp1s0
       valid_lft 86385sec preferred_lft 86385sec
    inet6 2600:1700:bb10:78d0:fbf1:7a0a:4fd1:105b/64 scope global dynamic noprefixroute 
       valid_lft 3204sec preferred_lft 3204sec
....later....
3: wlp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 08:ed:b9:69:86:45 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.86/24 brd 192.168.1.255 scope global dynamic noprefixroute wlp1s0
       valid_lft 86297sec preferred_lft 86297sec
    inet6 2600:1700:bb10:78d0:fbf1:7a0a:4fd1:105b/64

Let me try using a static and also disabling IPV4 and see what happens… (although this is probbaly a side effect of the wireless link flapping.)

1 Like

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!)

1 Like

I searched around a bit, and this seems to be a long running issue that crops up from time to time.

Here’s a post from 2011 with some workarounds:

https://bbs.archlinux.org/viewtopic.php?id=129344

I went looking at the kernel bugzilla, and found

https://bugzilla.kernel.org/show_bug.cgi?id=42877

A new recent bug for kernel 5.16.5 is here too:

https://bugzilla.kernel.org/show_bug.cgi?id=215698

here’s the complete search for ath9k:

https://bugzilla.kernel.org/buglist.cgi?quicksearch=ath9k

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.

1 Like

Thanks.

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.

Opened

https://bugzilla.redhat.com/show_bug.cgi?id=2066432

“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.

1 Like

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)

1 Like

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)

See kernel-5.16.18-100.fc34 | Build Info. This appears to be one of the problematic commits mentioned in the various bug reports, e.g. 215703 – ath9k frequent connection problems after kernel upgrade.

2 Likes

Did reply that that upgrading to 5.16.12-200.fc35.x86_64 seemed to have fixed this? It did.

1 Like