You are not logged in.

#1 2026-07-01 01:47:22

steelstarling
Member
Registered: 2026-07-01
Posts: 5

Suddenly Unable to Connect to Ethernet [RESOLVED]

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 (2026-07-04 03:41:55)

Offline

#2 2026-07-01 05:57:54

-thc
Member
Registered: 2017-03-15
Posts: 1,155

Re: Suddenly Unable to Connect to Ethernet [RESOLVED]

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:

steelstarling wrote:

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

Offline

#3 2026-07-01 06:01:31

seth
Member
From: Won't reply 2 private help req
Registered: 2012-09-03
Posts: 76,823

Re: Suddenly Unable to Connect to Ethernet [RESOLVED]

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 (2026-07-01 06:01:58)

Offline

#4 2026-07-01 08:28:55

steelstarling
Member
Registered: 2026-07-01
Posts: 5

Re: Suddenly Unable to Connect to Ethernet [RESOLVED]

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 (2026-07-01 08:33:18)

Offline

#5 2026-07-01 13:41:49

-thc
Member
Registered: 2017-03-15
Posts: 1,155

Re: Suddenly Unable to Connect to Ethernet [RESOLVED]

You have activated systemd-networkd and NetworkManager. Those are in conflict. Choose one.

If you want to keep systemd-resolved for DNS tell NetworkManager:

# /etc/NetworkManager/conf.d/dns.conf

[main]
dns=systemd-resolved

Offline

#6 2026-07-01 17:32:51

seth
Member
From: Won't reply 2 private help req
Registered: 2012-09-03
Posts: 76,823

Re: Suddenly Unable to Connect to Ethernet [RESOLVED]

This does explain the double-lease on wlan0  but not the missing lease on  enp6s0

If it's not just the service collision

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

https://bbs.archlinux.org/viewtopic.php … 0#p2303100
Also

sudo nmap -e enp6s0 --script broadcast-dhcp-discover

Offline

#7 2026-07-02 00:36:43

steelstarling
Member
Registered: 2026-07-01
Posts: 5

Re: Suddenly Unable to Connect to Ethernet [RESOLVED]

I've disabled all of systemd-resolved (including the linked triggers), however, my ethernet is still not working.

Running the command provided gives me the following:

sudo nmap -e enp6s0 --script broadcast-dhcp-discover
Starting Nmap 7.99 ( https://nmap.org ) at 2026-07-01 18:34 -0600
I cannot figure out what source address to use for device enp6s0, does it even exist?
QUITTING!

Otherwise, I'll provide ip link one more time:

ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enp6s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
    link/ether 10:ff:e0:b6:a8:8d brd ff:ff:ff:ff:ff:ff
    altname enx10ffe0b6a88d
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DORMANT group default qlen 1000
    link/ether ac:36:1b:e6:20:07 brd ff:ff:ff:ff:ff:ff

Any further idea what could be going on here?

Offline

#8 2026-07-02 04:17:02

-thc
Member
Registered: 2017-03-15
Posts: 1,155

Re: Suddenly Unable to Connect to Ethernet [RESOLVED]

systemd-resolved isn't a problem (for NetworkManager) as long as it's configured correctly. NetworkManager can also use it's own internal DNS management.

systemd-networkd and NetworkManager active at the same time is a problem.

Offline

#9 2026-07-02 05:19:04

seth
Member
From: Won't reply 2 private help req
Registered: 2012-09-03
Posts: 76,823

Re: Suddenly Unable to Connect to Ethernet [RESOLVED]

Also "ip a" is relevant, the NIC is there up and has a carrier, but obviously dhcp fails for so far unknown reasons.
Did you re-assure that you plugged the cable into the proper slots on both ends?

If the physical connection is ok and things keep failing despite having stopped and disabled systemd-networkd (you might want to also temporarily stop NM fror the nmap scan) please post your complete system journal for the boot:

sudo journalctl -b | curl -s -H "Accept: application/json, */*" --upload-file - 'https://paste.c-net.org/'

Offline

#10 2026-07-02 23:19:20

steelstarling
Member
Registered: 2026-07-01
Posts: 5

Re: Suddenly Unable to Connect to Ethernet [RESOLVED]

So, here should be everything you asked for (and for what you mentioned -thc, pardon my ignorance, but what exactly do I need to do to ensure my systemd-resolved is setup in a way that's not interfering?)

[...@... ~]$ 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: enp6s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 10:ff:e0:b6:a8:8d 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 ac:36:1b:e6:20:07 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 7177sec preferred_lft 7177sec
    inet6 fe80::c142:ea82:d904:834c/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever

with network manager stopped, nmap gives me the exact same results (just obviously a different timestamp), and, for sanity checking, the following is the output of the find systemd command from earlier, with my current settings:

[...@... ~]$ 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.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-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

finally, here's the whole system journal
https://paste.c-net.org/OctopusDrinker

Hopefully something in here helps, otherwise, my cables are plugged into the correct slots on both ends (this motherboard only has a single ethernet port, and I've tried two known working cables with it without changing how they're connected.

Last edited by steelstarling (2026-07-02 23:19:48)

Offline

#11 2026-07-03 05:28:34

seth
Member
From: Won't reply 2 private help req
Registered: 2012-09-03
Posts: 76,823

Re: Suddenly Unable to Connect to Ethernet [RESOLVED]

There's actually some noise from the wifi module

Jul 02 17:13:01 corvidae-beta kernel: rtw89_8922ae 0000:07:00.0: poll HWSI is busy
Jul 02 17:13:01 corvidae-beta kernel: rtw89_8922ae 0000:07:00.0: [rtw89_phy_write_full_rf_v2_a] HWSI is busy

but the wired connection simply times out on the dhcp request

Jul 02 17:12:07 archlinux kernel: pci 0000:06:00.0: [10ec:8125] type 00 class 0x020000 PCIe Endpoint
Jul 02 17:12:07 archlinux kernel: pci 0000:06:00.0: BAR 0 [io  0xd000-0xd0ff]
Jul 02 17:12:07 archlinux kernel: pci 0000:06:00.0: BAR 2 [mem 0xdcb00000-0xdcb0ffff 64bit]
Jul 02 17:12:07 archlinux kernel: pci 0000:06:00.0: BAR 4 [mem 0xdcb10000-0xdcb13fff 64bit]
Jul 02 17:12:07 archlinux kernel: pci 0000:06:00.0: supports D1 D2
Jul 02 17:12:07 archlinux kernel: pci 0000:06:00.0: PME# supported from D0 D1 D2 D3hot D3cold
Jul 02 17:12:07 archlinux kernel: pci 0000:06:00.0: Adding to iommu group 17
Jul 02 17:12:11 corvidae-beta kernel: r8169 0000:06:00.0 eth0: RTL8125D, 10:ff:e0:b6:a8:8d, XID 688, IRQ 133
Jul 02 17:12:11 corvidae-beta kernel: r8169 0000:06:00.0 eth0: jumbo features [frames: 16362 bytes, tx checksumming: ko]
Jul 02 17:12:11 corvidae-beta kernel: r8169 0000:06:00.0 enp6s0: renamed from eth0
Jul 02 17:12:11 corvidae-beta NetworkManager[516]: <info>  [1783033931.9130] manager: (enp6s0): new Ethernet device (/org/freedesktop/NetworkManager/Devices/2)
Jul 02 17:12:11 corvidae-beta NetworkManager[516]: <info>  [1783033931.9133] settings: (enp6s0): created default wired connection 'Wired connection 1'
Jul 02 17:12:11 corvidae-beta NetworkManager[516]: <info>  [1783033931.9133] device (enp6s0): state change: unmanaged -> unavailable (reason 'managed', managed-type: 'external')
Jul 02 17:12:11 corvidae-beta kernel: Realtek Internal NBASE-T PHY r8169-0-600:00: attached PHY driver (mii_bus:phy_addr=r8169-0-600:00, irq=MAC)
Jul 02 17:12:12 corvidae-beta kernel: r8169 0000:06:00.0 enp6s0: Link is Down
Jul 02 17:12:15 corvidae-beta NetworkManager[516]: <info>  [1783033935.2860] device (enp6s0): carrier: link connected
Jul 02 17:12:15 corvidae-beta NetworkManager[516]: <info>  [1783033935.2861] device (enp6s0): state change: unavailable -> disconnected (reason 'carrier-changed', managed-type: 'full')
Jul 02 17:12:15 corvidae-beta NetworkManager[516]: <info>  [1783033935.2865] device (enp6s0): Activation: starting connection 'Wired connection 1' (c53f419f-647a-3eaa-bbdc-6059f7d57fe0)
Jul 02 17:12:15 corvidae-beta NetworkManager[516]: <info>  [1783033935.2866] device (enp6s0): state change: disconnected -> prepare (reason 'none', managed-type: 'full')
Jul 02 17:12:15 corvidae-beta kernel: r8169 0000:06:00.0 enp6s0: Link is Up - 1Gbps/Full - flow control rx/tx
Jul 02 17:12:15 corvidae-beta NetworkManager[516]: <info>  [1783033935.2870] device (enp6s0): state change: prepare -> config (reason 'none', managed-type: 'full')
Jul 02 17:12:15 corvidae-beta NetworkManager[516]: <info>  [1783033935.2874] device (enp6s0): state change: config -> ip-config (reason 'none', managed-type: 'full')
Jul 02 17:12:15 corvidae-beta NetworkManager[516]: <info>  [1783033935.2875] dhcp4 (enp6s0): activation: beginning transaction (timeout in 45 seconds)
Jul 02 17:12:32 corvidae-beta systemd-resolved[365]: enp6s0: Bus client set default route setting: no
Jul 02 17:13:00 corvidae-beta NetworkManager[516]: <info>  [1783033980.8457] device (enp6s0): state change: ip-config -> failed (reason 'ip-config-unavailable', managed-type: 'full')
Jul 02 17:13:00 corvidae-beta NetworkManager[516]: <warn>  [1783033980.8458] device (enp6s0): Activation: failed for connection 'Wired connection 1'
Jul 02 17:13:00 corvidae-beta NetworkManager[516]: <info>  [1783033980.8459] device (enp6s0): state change: failed -> disconnected (reason 'none', managed-type: 'full')
Jul 02 17:13:00 corvidae-beta NetworkManager[516]: <info>  [1783033980.8497] dhcp4 (enp6s0): canceled DHCP transaction
Jul 02 17:13:00 corvidae-beta NetworkManager[516]: <info>  [1783033980.8497] dhcp4 (enp6s0): activation: beginning transaction (timeout in 45 seconds)
Jul 02 17:13:00 corvidae-beta NetworkManager[516]: <info>  [1783033980.8497] dhcp4 (enp6s0): state changed no lease
Jul 02 17:13:00 corvidae-beta NetworkManager[516]: <info>  [1783033980.8503] device (enp6s0): Activation: starting connection 'Wired connection 1' (c53f419f-647a-3eaa-bbdc-6059f7d57fe0)
Jul 02 17:13:00 corvidae-beta NetworkManager[516]: <info>  [1783033980.8503] device (enp6s0): state change: disconnected -> prepare (reason 'none', managed-type: 'full')
Jul 02 17:13:00 corvidae-beta NetworkManager[516]: <info>  [1783033980.8504] device (enp6s0): state change: prepare -> config (reason 'none', managed-type: 'full')
Jul 02 17:13:00 corvidae-beta NetworkManager[516]: <info>  [1783033980.8506] device (enp6s0): state change: config -> ip-config (reason 'none', managed-type: 'full')
Jul 02 17:13:00 corvidae-beta NetworkManager[516]: <info>  [1783033980.8508] dhcp4 (enp6s0): activation: beginning transaction (timeout in 45 seconds)
Jul 02 17:13:44 corvidae-beta NetworkManager[516]: <info>  [1783034024.5467] dhcp4 (enp6s0): canceled DHCP transaction
Jul 02 17:13:44 corvidae-beta NetworkManager[516]: <info>  [1783034024.5467] dhcp4 (enp6s0): state changed no lease
Jul 02 17:14:08 corvidae-beta sudo[2542]: steelstarling : TTY=pts/1 ; PWD=/home/steelstarling ; USER=root ; COMMAND=/usr/bin/nmap -e enp6s0 --script broadcast-dhcp-discover
Jul 02 17:16:58 corvidae-beta NetworkManager[2717]: <info>  [1783034218.0949] device (enp6s0): carrier: link connected
Jul 02 17:16:58 corvidae-beta NetworkManager[2717]: <info>  [1783034218.0951] manager: (enp6s0): new Ethernet device (/org/freedesktop/NetworkManager/Devices/2)
Jul 02 17:16:58 corvidae-beta NetworkManager[2717]: <info>  [1783034218.0952] manager: (enp6s0): assume: will attempt to assume matching connection 'Wired connection 1' (c53f419f-647a-3eaa-bbdc-6059f7d57fe0) (indicated)
Jul 02 17:16:58 corvidae-beta NetworkManager[2717]: <info>  [1783034218.0952] device (enp6s0): state change: unmanaged -> unavailable (reason 'connection-assumed', managed-type: 'assume')
Jul 02 17:16:58 corvidae-beta NetworkManager[2717]: <info>  [1783034218.0954] device (enp6s0): state change: unavailable -> disconnected (reason 'connection-assumed', managed-type: 'assume')
Jul 02 17:16:58 corvidae-beta NetworkManager[2717]: <info>  [1783034218.0957] device (enp6s0): Activation: starting connection 'Wired connection 1' (c53f419f-647a-3eaa-bbdc-6059f7d57fe0)
Jul 02 17:16:58 corvidae-beta NetworkManager[2717]: <info>  [1783034218.2411] device (enp6s0): state change: disconnected -> prepare (reason 'none', managed-type: 'assume')
Jul 02 17:16:58 corvidae-beta NetworkManager[2717]: <info>  [1783034218.2412] device (enp6s0): state change: prepare -> config (reason 'none', managed-type: 'assume')
Jul 02 17:16:58 corvidae-beta NetworkManager[2717]: <info>  [1783034218.2416] device (enp6s0): state change: config -> ip-config (reason 'none', managed-type: 'assume')
Jul 02 17:16:58 corvidae-beta NetworkManager[2717]: <info>  [1783034218.2417] dhcp4 (enp6s0): activation: beginning transaction (timeout in 45 seconds)

Since you have a carrier, there're no downshifts or anything else on that layer
1. reboot the router
2. try a different jack on the router
3. install https://archlinux.org/packages/extra/x86_64/dhclient/

systemctl stop NetworkManager.service
sudo dhclient -dv enp6s0

Offline

#12 2026-07-03 06:32:11

-thc
Member
Registered: 2017-03-15
Posts: 1,155

Re: Suddenly Unable to Connect to Ethernet [RESOLVED]

steelstarling wrote:

(and for what you mentioned -thc, pardon my ignorance, but what exactly do I need to do to ensure my systemd-resolved is setup in a way that's not interfering?)

Make sure systemd-resolved is configured in "stub" mode by checking that "/etc/resolv.conf" is the correct link:

[thc@box ~]$ ls -l /etc/resolv.conf 
lrwxrwxrwx 1 root root 37 Dec 12  2024 /etc/resolv.conf -> /run/systemd/resolve/stub-resolv.conf

"resolvectl status" shows this too:

[thc@box ~]$ resolvectl status
Global
       Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub
[...]

NetworkManager should automatically use systemd-resolved if it's correctly set up. This

# /etc/NetworkManager/conf.d/dns.conf

[main]
dns=systemd-resolved

is preventing NetworkMananger from using it's internal DNS management if something is off.

Offline

#13 2026-07-03 15:14:42

ewaller
Administrator
From: Pasadena, CA
Registered: 2009-07-13
Posts: 20,683

Re: Suddenly Unable to Connect to Ethernet [RESOLVED]

You might also try rebooting your router.   Mine is ISP provided and it does go brain dead occasionally when I disconnect and reconnect to a wired port.


Nothing is too wonderful to be true, if it be consistent with the laws of nature -- Michael Faraday
The shortest way to ruin a country is to give power to demagogues.— Dionysius of Halicarnassus
---
How to Ask Questions the Smart Way

Offline

#14 2026-07-04 03:40:11

steelstarling
Member
Registered: 2026-07-01
Posts: 5

Re: Suddenly Unable to Connect to Ethernet [RESOLVED]

In a strange turn of events, just as it began, it's fixed itself again, legitimately unsure what has changed this time around, but now it all connects and acts as if nothing was wrong.

Thanks everyone for all your help, even if uh, the actual cause of this is still an enigma to me, it was actually quite useful learning more about how this all works, I'll mark this as resolved (since I figure this technically isn't solved, just kinda, fixed itself), but if I should put it as "solved" in the title, do tell me, still learning the etiquette of this forum.

(also yes, I will be futzing around with making sure resolved is setup properly!)

Last edited by steelstarling (2026-07-04 03:41:45)

Offline

Board footer

Powered by FluxBB