[solved] highly unstable WiFi on NetworkManager

obsidianical · 2022-06-01 17:43:13

Hello,
the wifi on my relatively fresh arch installation (about a week old) is highly unstable, the connection either freezing or disconnecting fully every few minutes. I thought it was because the router may switch between WPA1 and WPA2, so I switched to WPA3 which did only solve the full disconnects (so far, they were semi rare anyway. Since I did that about an hour ago, nothing happened yet.) I tried looking in the journal but i have found nothing getting logged when the wifi goes down. On another distribution, Fedora 36, it worked flawlessly from the live image so it isn't an issue with the router or with the hardware. I'm having up to 10-30% packet loss which makes doing... anything really quite difficult.
I am on kernel version 5.18.1-arch1-1 using NetworkManager version 1.38.0-1.
Thanks in advance!

Edit: In case anyone having a similar issue stumbles across this and is a user of Spotify desktop and/or the Vivaldi browser: those two programs keps causing the packet loss for me, removing them solved the problems.

Last edited by obsidianical (2022-06-06 19:59:05)

V1del · 2022-06-01 18:20:21

How sure are you you are only using networkmanager? Output of

find /etc/systemd -type l -exec test -f {} \; -print | awk -F'/' '{ printf ("%-40s | %s\n", $(NF-0), $(NF-1)) }' | sort -f
#During such an unstable phase
sudo journalctl -b

post these in code tags or to a pastebin https://wiki.archlinux.org/title/List_o … n_services

obsidianical · 2022-06-01 18:30:14

first one:

bluetooth.service                        | bluetooth.target.wants
dbus-org.bluez.service                   | system
dbus-org.freedesktop.nm-dispatcher.service | system
dirmngr.socket                           | sockets.target.wants
display-manager.service                  | system
gcr-ssh-agent.socket                     | sockets.target.wants
getty@tty1.service                       | getty.target.wants
gnome-keyring-daemon.socket              | sockets.target.wants
gpg-agent-browser.socket                 | sockets.target.wants
gpg-agent-extra.socket                   | sockets.target.wants
gpg-agent.socket                         | sockets.target.wants
gpg-agent-ssh.socket                     | sockets.target.wants
libvirtd-ro.socket                       | sockets.target.wants
libvirtd.service                         | multi-user.target.wants
libvirtd.socket                          | sockets.target.wants
NetworkManager.service                   | multi-user.target.wants
NetworkManager-wait-online.service       | network-online.target.wants
ntpd.service                             | multi-user.target.wants
p11-kit-server.socket                    | sockets.target.wants
pipewire-media-session.service           | pipewire.service.wants
pipewire-pulse.socket                    | sockets.target.wants
pipewire-session-manager.service         | user
pipewire.socket                          | sockets.target.wants
remote-fs.target                         | multi-user.target.wants
sshd.service                             | multi-user.target.wants
virtlockd.socket                         | sockets.target.wants
virtlogd.socket                          | sockets.target.wants

~~I already checked the journal when and after it goes down, but usually there's nothing in the journal before, during or after that time.~~
CORRECTION: I didn't see it timing wise before, but now i was running `sudo journalctl -f` and sometimes before it freezes, around a few seconds before, that kind of stuff gets logged:

Jun 01 20:32:05 monosodium-glutamate-g pipewire-media-session[1455]: spa.bluez5.native: unknown AT+IPHONEACCEV key:2 value:0
Jun 01 20:34:05 monosodium-glutamate-g pipewire-media-session[1455]: spa.bluez5.native: unknown AT+IPHONEACCEV key:2 value:0
Jun 01 20:36:01 monosodium-glutamate-g pipewire-media-session[1455]: spa.bluez5.native: unknown AT+IPHONEACCEV key:2 value:0

Last edited by obsidianical (2022-06-01 18:37:12)

seth · 2022-06-01 18:44:44

The journal will also tell us about the used hardware, firmware, … 2.4/5GHz races, … power management …
Also NM is super-chatty and checks the connectivity all the time - if the network drops out there's probably something in the journal (nb. that running journalctl as non-root will by default only give you the irrelevant session journal)

Do you have a more stable connection w/
1. https://wiki.archlinux.org/title/Networ … Fi_backend
2. disabling https://wiki.archlinux.org/title/Networ … domization

If this is a 2.4GHz connection there's also the possibility of BT interference.

Also :do you test the package loss w/ ping or something that tries to write to disk (or a browser etc.)?

obsidianical · 2022-06-02 14:25:48

Hello, the used hardware is a B550 AORUS PRO AX motherboard, I am using the wifi antenna that came with it. I believe that'd be the only relevant part. I'd prefer not sending the journal because to be honest I'm not sure if there might be any personal info (my public IP or something) in there, so if there is another option I would prefer that. The wifi issues happen just after the aforementioned log messages, but I usually do not fully disconnect, but I'm not able to even ping the router either.

I switched to networkmanager-iwd to try it out and it feels better at least, but there's still significant packet loss, I didn't check if it's a significant amount less on a longer term. I also disabled the MAC adress randomization completely, which doesn't seem to solve it either.

While checking something while typing i noticed that there's a second network (with the SSID of our normal one, but a 1 on the end), so may that have anything to do with it as well?

I am testing packet loss mainly via ping, but the issues persist all across my system, be it a browser, discord call or a chat app. I am sure that I'm using 5ghz wifi, as i set it manually but 2.4ghz has the same issues.

Edit: I wrote the post just when getting on my PC but i have noticed another issue, which probably is related. When I open some websites (e.g whatsapp web) my wifi has a similar in nature freeze, which explains the huge measurement variations originally. The logs are all mainly about bluetooth and pipewire, so I think it may have something to do with that?

Edit 2: Some relevant looking logs

Last edited by obsidianical (2022-06-02 14:57:55)

seth · 2022-06-02 15:01:17

I'm not sure if there might be any personal info (my public IP or something) in there

Not unless there's a massive bug.

Some board brand & label unfortunately doesn't tell us anything - at best one could google for its specs and get an idea what wifi HW is *maybe* on it, but that doesn't say anything about the situation you're facing.
You don't have to share the journal, but you'll then have to identify the problem yourself (not "that", but "why") and can at best ask then for known mitigations.

obsidianical · 2022-06-02 15:07:01

Okay, then here are the full logs.

seth · 2022-06-02 15:24:48

No service collisions, no indication of AP hopping, no connection losses.
iwlwifi, no firmware crashes but possibly https://wiki.archlinux.org/title/Networ … oexistence

iwd unlike wpa_supplicant unfortunately doesn't reveal frequency or signal quality:
https://wiki.archlinux.org/title/Networ … _interface

You can try https://wiki.archlinux.org/title/Networ … s#Cause_#6 and https://wiki.archlinux.org/title/Networ … s#Cause_#7

obsidianical · 2022-06-02 15:47:22

I have disabled bluetooth coexistence, it seems to be a bit more stable now. If iwd doesn't reveal the signal quality, then i assume the info from the nm-applet's icon isn't indicative of the actual value? And if the issue was bluetooth coexistence, then it may work if I switched back to wpa_supplicant too, right? The connection quality is quite nice to know I'd say.

Edit: After running pings for 10-20min on various devices, yes it is more stable. Now it's down to ~4-4.5% packet loss, while all the other devices (with or without bluetooth on) were in the 0-0.1% area. And those numbers persist across tests without bluetooth, but it doesn't seem to be big at-once failures anymore, and there hasn't been anything in the journals either. I'm gonna play around with configs again, and if that doesn't fix it switch back to wpa_supplicant. Will report back with those test results as well in a bit.

Last edited by obsidianical (2022-06-02 16:40:00)

seth · 2022-06-02 15:57:16

It doesn't reveal it to the journal, you can still check the quality manually w/ iw or nmcli (i guess) - the signal strength will provide a general oversight on whether that might be the problem (if your signal is at -70dbm it'd be no wonder when the connection breaks down all the time)

obsidianical · 2022-06-03 13:35:14

Hello, the signal strength is pretty definitely not the problem, it's more then good enough. I tested other devices around the same physical location, no other one had the same issue. Other distributions (I tested on Fedora and EndeavourOS) have no issues either. I also tried the arch install image, which does have the issue as well. It seems to be specific to arch.

Arch Linux

#1 2022-06-01 17:43:13

[solved] highly unstable WiFi on NetworkManager

#2 2022-06-01 18:20:21

Re: [solved] highly unstable WiFi on NetworkManager

#3 2022-06-01 18:30:14

Re: [solved] highly unstable WiFi on NetworkManager

#4 2022-06-01 18:44:44

Re: [solved] highly unstable WiFi on NetworkManager

#5 2022-06-02 14:25:48

Re: [solved] highly unstable WiFi on NetworkManager

#6 2022-06-02 15:01:17

Re: [solved] highly unstable WiFi on NetworkManager

#7 2022-06-02 15:07:01

Re: [solved] highly unstable WiFi on NetworkManager

#8 2022-06-02 15:24:48

Re: [solved] highly unstable WiFi on NetworkManager

#9 2022-06-02 15:47:22

Re: [solved] highly unstable WiFi on NetworkManager

#10 2022-06-02 15:57:16

Re: [solved] highly unstable WiFi on NetworkManager

#11 2022-06-03 13:35:14

Re: [solved] highly unstable WiFi on NetworkManager

Board footer