[SOLVED] Suddenly Unable to Connect to Home Network

mcaceres · 2024-06-23 01:58:53

I'm not sure how but I suddenly lost connection to my home network from my laptop. Other devices can still connect to the network, and my laptop can connect to other networks; it's just this specific combination of my laptop and my home network that appears to be the issue. I've tried deleting and re-adding the network, restarting my NetworkManager (when I try to connect I get a limited connectivity message at first but it eventually gives up and says unable to connect), restarting my computer, disabling NetworkManager and connecting via iwd (I used iwd to connect when I first installed Arch; I am able to follow the steps here but nothing happens). I'm not sure how to debug, where to look for error messages, or what to do. Any help is appreciated.

I'm on 6.7.6-arch1-2, KDE 5.27,

Last edited by mcaceres (2024-07-14 17:43:46)

skunktrader · 2024-06-23 02:48:49

You didn't mention in your post but did you try rebooting the router? I have had similar symptoms here in the past that magically disappeared with a router reboot.

mcaceres · 2024-06-23 15:16:33

I tried rebooting the router and I still have the same problem. ):

ewaller · 2024-06-23 16:03:58

Could this be a regulatory domain issue?
https://wiki.archlinux.org/title/Networ … ory_domain

seth · 2024-06-23 16:09:42

Try to connect w/ NM and wpa_supplicant (don't enable that, NM calls it itself) and post the system journal covering that attempt.

mcaceres · 2024-06-23 19:10:32

Thank you for your suggestions! I'm not sure that I know how to use "NM and wpa_supplicant". I tried connecting via the NetworkManager applet in KDE. Here's journalctl for that: https://0x0.st/XAJY.txt

I also tried the steps here but was told after running wpa_supplicant "ctrl_iface exists and seems to be in use"; I tried using wpa_cli but the "save_config" step just printed out FAIL.

seth · 2024-06-23 20:05:12

NM is lazy for NetworkManager - it defaults to wpa_supplicant as backend and you cannot run a second wpa_sup on top of that.

The snippet alone there has NM, iwd wpa_sup and dhcpcd
Please post the output of

find /etc/systemd -type l -exec test -f {} \; -print | awk -F'/' '{ printf ("%-40s | %s\n", $(NF-0), $(NF-1)) }' | sort -f

We need to clean up this mess first.

mcaceres · 2024-06-23 21:16:00

I see, thanks! If it's a mess that might be the issue so it sounds like cause for optimism. It sounds like I'm not supposed to have all of these running and they're clashing somehow? Here's the output:

bluetooth.service                        | bluetooth.target.wants
cronie.service                           | multi-user.target.wants
cups.path                                | multi-user.target.wants
cups.service                             | multi-user.target.wants
cups.service                             | printer.target.wants
cups.socket                              | sockets.target.wants
dbus-org.bluez.service                   | system
dbus-org.freedesktop.nm-dispatcher.service | system
dbus-org.freedesktop.timesync1.service   | system
dhcpcd.service                           | multi-user.target.wants
display-manager.service                  | system
gcr-ssh-agent.socket                     | sockets.target.wants
getty@tty1.service                       | getty.target.wants
httpd.service                            | multi-user.target.wants
iwd.service                              | multi-user.target.wants
NetworkManager.service                   | multi-user.target.wants
NetworkManager-wait-online.service       | network-online.target.wants
nmb.service                              | multi-user.target.wants
nordvpnd.service                         | default.target.wants
p11-kit-server.socket                    | sockets.target.wants
pcscd.socket                             | sockets.target.wants
pipewire-media-session.service           | pipewire.service.wants
pipewire-session-manager.service         | user
pipewire.socket                          | sockets.target.wants
power-profiles-daemon.service            | graphical.target.wants
pulseaudio.socket                        | sockets.target.wants
remote-fs.target                         | multi-user.target.wants
smb.service                              | multi-user.target.wants
sshd.service                             | multi-user.target.wants
syncthing@mauricio.service               | multi-user.target.wants
systemd-timesyncd.service                | sysinit.target.wants
xdg-user-dirs-update.service             | default.target.wants

seth · 2024-06-23 21:26:36

Certainly disable
- iwd.service
- dhcpcd.service
and replace pulseaudio with pipewire-pulse

If you still think you're problems, try to disable
- nordvpnd.service
to rule out the VPN

You're intentionally running apache and samba?

mcaceres · 2024-06-23 23:06:18

Sounds good; will try these when I get home later. (I did make sure to have nord disconnected but I'll also disable the service just in case.)

I don't believe I've used either Apache or Samba in a few years so almost surely this is not intentional, but some version of legacy code debt (i.e. I probably needed them at some point and have carried them around since).

Thanks a lot for looking into my problem! I really appreciate the guidance.

mcaceres · 2024-06-24 11:34:10

Actually, when I tried this, disabling iwd meant I couldn't get any wifi at all.

seth · 2024-06-24 14:31:46

Please post the system journal for that boot.

mcaceres · 2024-07-12 04:50:03

Sorry I went MIA (I've been away from home for the past few weeks and this wasn't an issue in other networks). I was able to disable iwd, dhcpcd, nordvpn, apache, samba; I'm still having this issue (journal covering attempt): https://0x0.st/XMgf.log

I'm deeply hesitant to mess with my audio; why is replacing pulseaudio with pipewide-pulse necessary?

seth · 2024-07-12 08:15:40

Because you cannot reasonably run two audio daemons concurrently - pipewire-pulse provides a shim that transparently allows pulseaudio clients to use pipewire through the pulseaudio API.
It's that or replacing pipewire w/ pulseaudio entirely (what is not suggested)

Jul 12 00:40:07 mauricio-carbon NetworkManager[902]: <info>  [1720759207.8035] device (wlan0): state change: ip-config -> failed (reason 'ip-config-unavailable', sys-iface-state: 'managed')

Delete the connection and re-create it.
The dhcp request somehow fails. In doubt you can use a different https://wiki.archlinux.org/title/Networ … HCP_client (assuming it's currently the internal one, the journal tail doesn't tell that…)

V1del · 2024-07-12 11:17:02

FWIW you can also run pipewire without the audio parts and if you don't have the stuff from pipewire-audio installed and use pipewire-media-session in lieu of wireplumber it's quite possible to run pulseaudio and pipewire concurrently (pipewire will just be handling video/screen sharing in that case)

But as far as future developments are going pipewire simply has more traction than pulse.

mcaceres · 2024-07-13 16:34:21

Thanks both; I replaced pulseaudio with pipewire-pulse.

I'm not sure how to "Delete the connection and re-create it"? Does this just mean to delete the network from NetworkManager and reconnect? If so then I did do this; if something else not sure.

I deleted the network again, installed dhclient, and edited /etc/NetworkManager/conf.d/dhcp-client.conf as the link (https://wiki.archlinux.org/title/Networ … HCP_client) shows. I then restarted NetworkManager via systemctl and tried to connect again. Here's the journal tail for that (it fails and goes back to tethering off my phone). http://0x0.st/Xurq.txt

Last edited by mcaceres (2024-07-13 16:34:34)

seth · 2024-07-13 19:59:26

this just mean to delete the network from NetworkManager and reconnect

Yes.

Here's the journal tail for that (it fails and goes back to tethering off my phone).

No, you're actually using the phones hotspot.
Status quo remains:

Jul 13 12:30:30 mauricio-carbon NetworkManager[7709]: <info>  [1720888230.9718] device (wlp0s20f3): state change: config -> ip-config (reason 'none', sys-iface-state: 'managed')
Jul 13 12:30:30 mauricio-carbon NetworkManager[7709]: <info>  [1720888230.9730] dhcp4 (wlp0s20f3): activation: beginning transaction (timeout in 45 seconds)
Jul 13 12:30:30 mauricio-carbon NetworkManager[7709]: <info>  [1720888230.9779] dhcp4 (wlp0s20f3): dhclient started with pid 7909
Jul 13 12:30:31 mauricio-carbon dhclient[7909]: DHCPDISCOVER on wlp0s20f3 to 255.255.255.255 port 67 interval 7
Jul 13 12:30:37 mauricio-carbon dhclient[7909]: DHCPDISCOVER on wlp0s20f3 to 255.255.255.255 port 67 interval 17
Jul 13 12:30:54 mauricio-carbon dhclient[7909]: DHCPDISCOVER on wlp0s20f3 to 255.255.255.255 port 67 interval 8
Jul 13 12:31:02 mauricio-carbon dhclient[7909]: DHCPDISCOVER on wlp0s20f3 to 255.255.255.255 port 67 interval 13
Jul 13 12:31:15 mauricio-carbon dhclient[7909]: DHCPDISCOVER on wlp0s20f3 to 255.255.255.255 port 67 interval 15
Jul 13 12:31:15 mauricio-carbon NetworkManager[7709]: <info>  [1720888275.8386] device (wlp0s20f3): state change: ip-config -> failed (reason 'ip-config-unavailable', sys-iface-state: 'managed')
Jul 13 12:31:15 mauricio-carbon kernel: wlp0s20f3: deauthenticating from 4c:19:5d:37:47:b8 by local choice (Reason: 3=DEAUTH_LEAVING)

You connect but the router doesn't answer your dhcp request.

Check the router for stale leases, in doubt reboot it and try to disable https://wiki.archlinux.org/title/Networ … domization

This is very unlikely a problem with the arch system now as the behavior is unique to the router and affects two different dhcp implementations.

twelveeighty · 2024-07-13 22:38:39

This may be a long shot, but what does the following return:

nmcli connection show <con-name> | grep ipv4.method

Replace <con-name> with the name for your home network. To get the exact name, you can use 'nmcli connection show' to see a listing of your configured connections. It doesn't matter if the connection is active or not.

If that is showing anything but 'auto', that's a problem. You can set it to auto using:

nmcli connection modify <con-name> ipv4.method auto

If it is already set to 'auto', then another you could try to prove it's DHCP is to temporarily switch your connection to manual and specifying the subnet + IP manually in NM. Make sure to pick an available local IP, of course. You might also want to reserve it with the router (by MAC address) to rule out the fact that the router may actually be "out" of IP addresses to issue. That would be bizarre, unless you have some kind of device on the network that's gone haywire with its DHCP requests and has exhausted the available IPs. Also make sure your router isn't blocking IPv4 traffic.

mcaceres · 2024-07-13 23:52:38

- I guess I don't know the difference between hotspot and tethering here.
- I tried disabling random MAC addresses as shown in the link (https://wiki.archlinux.org/title/Networ … domization). I deleted the network, restarted the router, restarted NetworkManager, and tried again. Same result.
- ipv4.method is set to auto.

I don't know how to check on the rest (stale leases, connect manually via IP, check if the router is blocking IPv4 traffic). However, I just found out we'll be getting a new router tomorrow (unrelated to this issue). It sounds like it would be exceedingly strange if my problem persisted after that, so I will report back then. Thank you all for all your help debugging this so far; I appreciate it.

seth · 2024-07-14 07:03:41

I guess I don't know the difference between hotspot and tethering here.

Tethering involves a cable or an annoying little plastic strap that tried to prevent you from drinking like a civilized human

stale leases, connect manually via IP, check if the router is blocking IPv4 traffic

In the router settings, rebooting it should have taken care of the stale leases.

It sounds like it would be exceedingly strange if my problem persisted after that

Let's hope so, because otherwise you'll have to manually establish a carrier ("wifi cable") and scan for dhcp servers (cause maybe there's a rogue one in your LAN)

mcaceres · 2024-07-14 17:43:15

New router; same network name and password. Connected automatically after it was set up.

Thank you for all your help.

Arch Linux

#1 2024-06-23 01:58:53

[SOLVED] Suddenly Unable to Connect to Home Network

#2 2024-06-23 02:48:49

Re: [SOLVED] Suddenly Unable to Connect to Home Network

#3 2024-06-23 15:16:33

Re: [SOLVED] Suddenly Unable to Connect to Home Network

#4 2024-06-23 16:03:58

Re: [SOLVED] Suddenly Unable to Connect to Home Network

#5 2024-06-23 16:09:42

Re: [SOLVED] Suddenly Unable to Connect to Home Network

#6 2024-06-23 19:10:32

Re: [SOLVED] Suddenly Unable to Connect to Home Network

#7 2024-06-23 20:05:12

Re: [SOLVED] Suddenly Unable to Connect to Home Network

#8 2024-06-23 21:16:00

Re: [SOLVED] Suddenly Unable to Connect to Home Network

#9 2024-06-23 21:26:36

Re: [SOLVED] Suddenly Unable to Connect to Home Network

#10 2024-06-23 23:06:18

Re: [SOLVED] Suddenly Unable to Connect to Home Network

#11 2024-06-24 11:34:10

Re: [SOLVED] Suddenly Unable to Connect to Home Network

#12 2024-06-24 14:31:46

Re: [SOLVED] Suddenly Unable to Connect to Home Network

#13 2024-07-12 04:50:03

Re: [SOLVED] Suddenly Unable to Connect to Home Network

#14 2024-07-12 08:15:40

Re: [SOLVED] Suddenly Unable to Connect to Home Network

#15 2024-07-12 11:17:02

Re: [SOLVED] Suddenly Unable to Connect to Home Network

#16 2024-07-13 16:34:21

Re: [SOLVED] Suddenly Unable to Connect to Home Network

#17 2024-07-13 19:59:26

Re: [SOLVED] Suddenly Unable to Connect to Home Network

#18 2024-07-13 22:38:39

Re: [SOLVED] Suddenly Unable to Connect to Home Network

#19 2024-07-13 23:52:38

Re: [SOLVED] Suddenly Unable to Connect to Home Network

#20 2024-07-14 07:03:41

Re: [SOLVED] Suddenly Unable to Connect to Home Network

#21 2024-07-14 17:43:15

Re: [SOLVED] Suddenly Unable to Connect to Home Network

Board footer