Arch Linux

steelstarling

Member

Registered: Today

Posts: 2

Suddenly Unable to Connect to Ethernet

Hey all,

I was using my computer yesterday with no issue, but upon starting it up this morning, my hardwired ethernet connection has stopped working and I can't for the life of me figure out why.

I've only done two things since the last reboot where it worked, those being install Tailscaled (which, after disabling with systemctl and restarting (and checking it was still offline), did not resolve my issue) and physically move the computer to the other side of my desk. I did, in this process, change which ethernet cable I'm using to connect, but again, swapping back to the old one did not resolve this, so I'm frankly unsure what could've caused the issue.

I'm still able to connect to wireless just fine, it's only my ethernet setup that gives me issues. When connecting on Plasma (which I have installed purely so I can troubleshoot more easily for cases like this), it ends up showing me a message saying "IP configuration was unavailable" however I'm unsure how to resolve this.

Looking at my ip link, I see the following:

2: enp6s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000

(and another few lines I'm leaving out)

Additionally, looking at nmcli device I get this:

enp6s0         ethernet  connecting (getting IP configuration)  Wired connection 1

And from [nmcli connection:

Wired connection 1  c53f419f-647a-3eaa-bbdc-6059f7d57fe0  ethernet  enp6s0

Finally, dhcpcd is running, per systemctl status dhcpcd:

● dhcpcd.service - DHCP/ IPv4LL/ IPv6RA/ DHCPv6 client on all interfaces
     Loaded: loaded (/usr/lib/systemd/system/dhcpcd.service; enabled; preset: disabled)
     Active: active (running) since Tue 2026-06-30 19:22:35 MDT; 23min ago
 Invocation: 29f5c342b0a24f5d9db55a233bade476
   Main PID: 531 (dhcpcd)
      Tasks: 6 (limit: 37123)
     Memory: 4.4M (peak: 8.4M)
        CPU: 94ms

I've tried updating my system, various restarts, and of course, trying other cables and connections, but nothing seems to work. Help would be greatly appreciated.

EDIT: Fixed code block formatting

Last edited by steelstarling (Today 08:15:37)

-thc

Member

Registered: 2017-03-15

Posts: 1,148

Re: Suddenly Unable to Connect to Ethernet

Please use [ code ] [ / code ] tags to format your post.

Make sure no other network management interferes:

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

If you want NetworkManager to use an external DHCP client instead of it's own internal one, configure it:

# /etc/NetworkManager/conf.d/dhcp-client.conf

[main]
dhcp=dhcpcd

The rest is guesswork. One cause:

(and another few lines I'm leaving out)

Well, those are the interesting ones.

My best guess: DHCPv4 isn't working properly but SLAAC is.

seth

Member

From: Won't reply 2 private help req

Registered: 2012-09-03

Posts: 76,427

Re: Suddenly Unable to Connect to Ethernet

Additionally, looking at nmcli device I get this:
Finally, dhcpcd is running, per systemctl status dhcpcd:

Don't run competing network daemons.
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

(and another few lines I'm leaving out)

If fixing your network daemons doesn't suffice and you want to know whether you've a lease that's not an option.

ip a; ip r

Edit: F5CK!

Last edited by seth (Today 06:01:58)

---

How to upload text · How to boot w/o GUI · Disable Windows Fast-Start! · Fix your xinitrc

steelstarling

Member

Registered: Today

Posts: 2

Re: Suddenly Unable to Connect to Ethernet

Fixed the formatting (thanks for bearing with me, still relatively new to Arch and the forum).

For the output requested (and yes, dhcpcd was there originally, but I've now deactivated it in favor of NetworkManager which was running already (as I mention later in this post), so here's what it currently is):

[...@... ~]$ find /etc/systemd -type l -exec test -f {} \; -print | awk -F'/' '{ printf ("%-40s | %s\n", $(NF-0), $(NF-1)) }' | sort -f
autovt@.service                          | system
bluetooth.service                        | bluetooth.target.wants
dbus-org.bluez.service                   | system
dbus-org.freedesktop.network1.service    | system
dbus-org.freedesktop.nm-dispatcher.service | system
dbus-org.freedesktop.resolve1.service    | system
display-manager.service                  | system
getty@tty1.service                       | getty.target.wants
NetworkManager.service                   | multi-user.target.wants
NetworkManager-wait-online.service       | network-online.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
sshd.service                             | multi-user.target.wants
systemd-networkd-resolve-hook.socket     | sockets.target.wants
systemd-networkd.service                 | multi-user.target.wants
systemd-networkd.socket                  | sockets.target.wants
systemd-networkd-varlink.socket          | sockets.target.wants
systemd-networkd-wait-online.service     | network-online.target.wants
systemd-network-generator.service        | sysinit.target.wants
systemd-resolved-monitor.socket          | sockets.target.wants
systemd-resolved.service                 | sysinit.target.wants
systemd-resolved-varlink.socket          | sockets.target.wants
systemd-userdbd.socket                   | sockets.target.wants
wireplumber.service                      | pipewire.service.wants
xdg-user-dirs.service                    | graphical-session-pre.target.wants

Additionally

If you want NetworkManager to use an external DHCP client instead of it's own internal one, configure it:

I wasn't doing this originally, but I (in my infinite lack of wisdom) futzed with it trying to figure out what was wrong, alas, it still is broken after disabling it.

And finally, here's the following (with the MAC addresses redacted to "g", because I'm annoyingly privacy paranoid, albeit if they are needed to be shown, do tell me)

[...@... ~]$ ip a; ip r
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: enp6s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether gg:gg:gg:gg:gg:gg brd ff:ff:ff:ff:ff:ff
    altname enx10ffe0b6a88d
    inet6 fe80::261b:5f66:eef:869b/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether gg:gg:gg:gg:gg:gg brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.172/24 brd 192.168.1.255 scope global dynamic noprefixroute wlan0
       valid_lft 5266sec preferred_lft 5266sec
    inet 192.168.1.173/24 brd 192.168.1.255 scope global secondary dynamic noprefixroute wlan0
       valid_lft 5277sec preferred_lft 4377sec
    inet6 fe80::c142:ea82:d904:834c/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
    inet6 fe80::a756:3995:86d6:ed93/64 scope link 
       valid_lft forever preferred_lft forever
default via 192.168.1.1 dev wlan0 proto dhcp src 192.168.1.172 metric 600 
default via 192.168.1.1 dev wlan0 proto dhcp src 192.168.1.173 metric 3003 
192.168.1.0/24 dev wlan0 proto kernel scope link src 192.168.1.172 metric 600 
192.168.1.0/24 dev wlan0 proto dhcp scope link src 192.168.1.173 metric 3003

Last edited by steelstarling (Today 08:33:18)