You are not logged in.
Pages: 1
Topic closed
I have this really annoying issue where my Wi-Fi connection will randomly disconnect at any random interval. Sometimes it's three hours, other times it's three days. I run a virtualized Windows instance with GPU pass-through that I set up to host Parsec on, for gaming or media purposes. It becomes particularly aggravating when I am not able to reach my desktop due to being out of town, and there is literally no way at all to connect to the host or the guest because the connection cuts out. The intermittence of the intervals is also particularly confusing. Let me describe the problem in detail.
I can connect to my home Wi-Fi network with no problems or delays whatsoever. Yet, on any random occasion, the network will disconnect. When it disconnects, it presents an "Incorrect password" dialog, as if it tried to connect but had an authentication error. Every single time, I type in the correct password. When I type in the correct password, though, it does not automatically reconnect. I have to open the Network Manager panel again and hit connect. When I do that, it connects flawlessly, and does not give me any more trouble until the next time it disconnects. I have verified that the password saved in the connection's configuration is correct. Like I said before, this does not ever really bother me, until I am not within physical proximity of the desktop. Also, this connection problem occurs regardless of whether or not a virtual instance is currently running.
For context, this Arch installation is about six months old, and while the network problem is just as old, I've often opted to ignore it. I've kept on top of maintaining my installation, and it doesn't give me any problems besides this weird network dilemma.
$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host noprefixroute
valid_lft forever preferred_lft forever
2: enp5s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
link/ether a8:a1:59:61:5b:8f brd ff:ff:ff:ff:ff:ff
5: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether f8:e4:e3:7d:d2:ff brd ff:ff:ff:ff:ff:ff
inet 10.0.0.110/24 brd 10.0.0.255 scope global dynamic noprefixroute wlan0
valid_lft 171833sec preferred_lft 171833sec
6: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
link/ether 52:54:00:af:5b:d5 brd ff:ff:ff:ff:ff:ff
inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0
valid_lft forever preferred_lft forever$ neofetch ### truncated
OS: Arch Linux x86_64
Host: B550 Phantom Gaming 4
Kernel: 6.9.5-arch1-1
Uptime: 2 days, 20 hours, 24 mins
Packages: 1382 (pacman), 9 (flatpak)
Shell: fish 3.7.1
Resolution: 1920x1080
DE: Plasma 6.1.0
WM: KWin
Theme: [Plasma], Gradient-Dark-GTK [GT
Icons: [Plasma], breeze-dark [GTK2/3]
Terminal: konsole
CPU: AMD Ryzen 7 5700G with Radeon Gra
GPU: AMD ATI Radeon Vega Series / Rade
GPU: NVIDIA GeForce GTX 1050 Ti
Memory: 2105MiB / 27933MiBLast edited by austanss (2024-06-27 16:03:03)
Offline
Post the outputs of
find /etc/systemd -type l -exec test -f {} \; -print | awk -F'/' '{ printf ("%-40s | %s\n", $(NF-0), $(NF-1)) }' | sort -f
sudo journalctl -bhttps://wiki.archlinux.org/title/List_o … n_services
The fact your wifi is called wlan0 smells like iwd, and if both it and networkmanager are actively running services you are conflicting between the two. Since you probably want to keep plasma's applet integration make sure to disable the iwd service.
Offline
I disabled iwd, then rebooted. My network still runs fine, as NetworkManager pulls the labor. This is the output after I disabled iwd.
bluetooth.service | bluetooth.target.wants
dbus-org.bluez.service | system
dbus-org.freedesktop.nm-dispatcher.service | system
dbus-org.freedesktop.resolve1.service | system
dbus-org.freedesktop.timesync1.service | system
display-manager.service | system
gcr-ssh-agent.socket | sockets.target.wants
getty@tty1.service | getty.target.wants
libvirtd-admin.socket | sockets.target.wants
libvirtd-ro.socket | sockets.target.wants
libvirtd.socket | sockets.target.wants
NetworkManager-wait-online.service | network-online.target.wants
NetworkManager.service | multi-user.target.wants
p11-kit-server.socket | sockets.target.wants
pipewire-pulse.socket | sockets.target.wants
pipewire-session-manager.service | user
pipewire.socket | sockets.target.wants
remote-fs.target | multi-user.target.wants
systemd-resolved.service | sysinit.target.wants
systemd-timesyncd.service | sysinit.target.wants
virtlockd-admin.socket | sockets.target.wants
virtlockd.socket | sockets.target.wants
virtlogd-admin.socket | sockets.target.wants
virtlogd.socket | sockets.target.wants
wireplumber.service | pipewire.service.wants
xdg-user-dirs-update.service | default.target.wantsjournal:
https://termbin.com/p0uy
The iwd conflict seems like a reasonable root cause of the issue. As it stands currently though, I have no way of testing if the solution is final or not. I'll post back here in five days if it doesn't give me any issue, or earlier if it does. Five days should be long enough for the possible problem to present itself...
Offline
24 hours later, can confirm that the solution was not final. Woke up this morning and saw that the Wi-Fi had disconnected in the same exact manner. Seizing upon the opportunity, I tested another case. When I click "Cancel" on the password prompt dialog, and then hit "Connect" in the Plasma applet, it will connect with no problems. I do not need to provide a new password, yet it still disconnects and prompts for one anyway, despite having the correct password stored. I went further and uninstalled iwd rather than simply disabling it. The wifi adapter is still named wlan0. The output of `ip a` is still the same. All the previous command outputs still apply, AFAIK.
Offline
The journal coverign that would probably be useful.
Woke up this morning and saw that the Wi-Fi had disconnected
Were you the only one sleeping or did you also wake up the system?
Is there any chance the AP reboots at night?
Offline
Im noticing this in your journal:
NetworkManager[PID]: <info> [TIMESTAMP] device (wlan0): state change: need-auth -> failed (reason 'no-secrets', sys-iface-state: 'managed')
So maybe your kde-wallet isnt functioning properly, to provide the passwoed to NetworkManager when it tried to reauthenticate
Check this thread for different proposed solutions, and also some people suggesting its a router/hardware problem:
https://unix.stackexchange.com/q/420640
Offline
I also thought about kwallet, because the automatic kwallet unlock hasn't worked after an update yesterday. There has been a kwallet_pam update, though, so with some luck just updating the system will do the trick.
EDIT: I can confirm, that after updating kwallet-pam, kwallet unlocks automatically once more. If that was the root cause, then it'll go away by itself.
Last edited by Awebb (2024-06-29 03:46:00)
Offline
Were you the only one sleeping or did you also wake up the system?
My system never sleeps, I only allow it to lock and turn the screen off.
Is there any chance the AP reboots at night?
If that was the case, then the computer would automatically reconnect when it comes back online. It wouldn't prompt about an incorrect password, because the password doesn't change.
some people suggesting its a router/hardware problem
Unless my 3 year old Intel Wi-Fi 6-ax WPA3 network PCIe card is giving out, I don't think its a hardware issue...
Sometimes it comes loose from its unlocked 1x slot, but when it does that I don't get any connection at all.
Check this thread for different proposed solutions
All of those solutions (not to say I didn't try them) are incredibly vague, brief, and are not particularly relevant to my situation because my connection works fine until it cuts out.
The dis-connection occurs randomly, intermittently, and unpredictably. Yet, when it cuts out, I can reconnect it easily. However, it does not happen automatically. The re-connection is a manual task that I must perform while having physical access to the computer.
This is problematic when I wish to access the computer remotely, as the computer needs to have similar uptime and reliability (of which my hardware and power supply certainly is reliable enough to accommodate) to that of a server.
Last edited by austanss (2024-06-29 20:44:14)
Offline
If that was the case, then the computer would automatically reconnect when it comes back online.
The question would what causes the disconnects tbw.
The PW flubs might be down to Awebb's kwallet suggestion.
Offline
Hey, have you managed to find any solution for this problem?
Last edited by gerswick (2026-01-17 22:28:07)
Offline
The OP hasn't been active on the board > 18 months and if this has been a software issue you're not overly likely to face the exact same problem after that time anyway.
You're better off opening a new thread and presenting/illustrating your problem instead of necrobumping seemingly similar threads.
Offline
Mod note: closing this old thread
https://wiki.archlinux.org/title/Genera … bumping%22
Last edited by WorMzy (2026-01-18 10:44:25)
Sakura:-
Mobo: MSI MAG X570S TORPEDO MAX // Processor: AMD Ryzen 9 5950X @4.9GHz // GFX: AMD Radeon RX 5700 XT // RAM: 32GB (4x 8GB) Corsair DDR4 (@ 3000MHz) // Storage: 1x 3TB HDD, 6x 1TB SSD, 2x 120GB SSD, 1x 275GB M2 SSD
Making lemonade from lemons since 2015.
Offline
Pages: 1
Topic closed