[Solved] Ethernet not working, but Wifi does

Spacebar · 2025-06-30 18:15:17

Hey guys, first post here, loving arch, but I'm having some issues and was hoping to get some assistance. Below is a copy and paste of a Reddit post I made. Please let me know if you guys need any additional information from me and I'd be happy to provide it.

So I have an Ubuntu server that automatically forces all devices to use it as the DNS resolver via Pi-hole.

I installed Arch a few days ago, everything has been working great, but I think I broke my ethernet, and I'm not really sure how it occured or how to fix it.

Pinging anything results in a time out. KDE shows that I'm connected via ethernet, but have no internet.

WiFi works perfectly fine and uses Pi-hole as expected. I have tried editing `/etc/resolv.conf` to verify that the DNS server was set to my Pi-hole servers IP, which it was.

I have tried bringing down the interface and back up.

I have tried installing dhcpcd (wasn't installed by default), then running `sudo dhcpcd enp6s0`, where enp6s0 is the name of my interface.

Does anyone have any additional device on steps to drive. I've taken a look at the wiki and still can't get things to work.

Results of `journalctl -b -u NetworkManager`: https://pastebin.com/X346rN1v

Results of `ip link show enp6s0`:

2: enp6s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
link/ether 4c:ed:fb:c4:7c:eb brd ff:ff:ff:ff:ff:ff
altname enx4cedfbc47ceb

EDIT: I deleted the connection with KDE, then ran `sudo systemctl start dhcpcd`, which recreated the enp6s0 interface within the network manager. After connecting and disable wifi, the internet is still not working. Pinging anything results in `Temporary failure in name resolution`.

Interestingly enough, if I start the ping while on wifi, turn off wifi, it continues pinging, leading me to believe this is a DNS issue.

I have disabled Pi-holes blocking capabilities, though it is still the dhcpcd server.

EDIT 2: Running dig queries when connected only to ethernet results in:

[brody@archlinux ~]$ dig queries
;; communications error to ::1#53: connection refused
;; communications error to ::1#53: connection refused
;; communications error to ::1#53: connection refused
;; communications error to 127.0.0.1#53: connection refused

; <<>> DiG 9.20.10 <<>> queries
;; global options: +cmd
;; no servers could be reached

EDIT 3: Deleting the DHCP lease within pihole and reconnecting did not resolve the issue. I uninstalled dhcpcd from my system, as it was working fine before without it. I believe my system is using `systemd-networkd` anyway.

EDIT 4: Since my Ubuntu server has IPv6 disabled, I tried disabling IPv6 via kernel parameters on Arch, which did not resolve the issue. Connecting to ethernet and running `ip address show` shows no IP address has been assigned. Attempting to ping my router or Ubuntu server works as expected, but pinging an external IP results in a timeout due to : `ping: google.com: Temporary failure in name resolution` Running `dig queries` with IPv6 disabled results in `;; communications error to 192.168.1.2#53: connection refused`

EDIT 5: You guys are not going to believe this. Somehow, no idea how because I didn't do it, UFW created a rule to reject all requests from my PC. WTF? Removing the rule solved the issue. But I'm super curious exactly why this happened. Do you guys think my server could have been hacked?

Last edited by Spacebar (2025-06-30 20:56:49)

wonderworld · 2025-06-30 20:42:20

> Somehow, no idea how because I didn't do it, UFW created a rule to reject all requests from my PC.

I don't know PiHole but maybe it has some feaure to block misbehaving clients automatically and your PC triggered it somehow?

Spacebar · 2025-06-30 20:56:20

wonderworld wrote:

> Somehow, no idea how because I didn't do it, UFW created a rule to reject all requests from my PC.
I don't know PiHole but maybe it has some feaure to block misbehaving clients automatically and your PC triggered it somehow?

I'm not sure if Pihole has that function, but it's running within Docker, so I don't think it'd be able to do that even if it wanted to, unless it somehow had a separate UFW firewallw within the container environment.

I'm glad to have resolved the issue, but I'm super confused.

seth · 2025-06-30 21:23:16

Somehow, no idea how because I didn't do it, UFW created a rule to reject all requests from my PC.

Sure was UFW? Did you maybe install and eneable https://wiki.archlinux.org/title/Nftabl … e_firewall ?

Spacebar · 2025-07-01 14:45:14

seth wrote:

Somehow, no idea how because I didn't do it, UFW created a rule to reject all requests from my PC.
Sure was UFW? Did you maybe install and eneable https://wiki.archlinux.org/title/Nftabl … e_firewall ?

Yes, it was UFW, but the rule was added via fail2ban.

I recently switched to Arch instead of Windows, Pop, Ubuntu, etc like I had used in the past. When switching to Arch, I chose Kitty as my terminal emulator.

I *think* Kitty automatically retries to connect over SSH if it loses connection. I have fail2ban set up to add a client to the blacklist after 3 failed authentication attempts and have always left my local network on there too with no issues over the past 5 or so years, but yeah, I guess Kitty is causing it.

Either that, or my fresh Arch installation was hacked. Perhaps there is another possible cause, but I'm just not sure what it would be.

Last edited by Spacebar (2025-07-01 14:46:14)

cryptearth · 2025-07-01 18:27:33

Spacebar wrote:

or my fresh Arch installation was hacked

ok - aside from paranoia lets put together the requirements for that to happen:
- something vulnerable - although no linux software is perfect an attacker first needs an attack vector to attack - and a fresh system likely just doesn't have anything installed an attacker could even attack
- access - your setup sounds like most private connections: a modem/router combo with integrated nat firewall - that little black magic protecting most users from most common crap - and attacker would first require to get into your network before being able to attack your fesh install
- timing - aside from the above at lets say a system directly connected to the wide internet without a nat-router - an attacker would need to get the timing right and attack you right at that time when they have access to something vulnerable on your network - and at least here your theory falls apart

tldr: there's just too much that has to go wrong for a fesh linux install to get hacked
even hijacking a mirror and distributing bad software would not that easy due to the arch-keyring as the install environment needs to be compromised to accept bad signatures
I guess you can start to see that this just doesn't work

seth · 2025-07-01 19:29:22

You could wireshark the system and check what kitty is doing there, do you use some built-in ssh client or openssh?

Arch Linux

#1 2025-06-30 18:15:17

[Solved] Ethernet not working, but Wifi does

#2 2025-06-30 20:42:20

Re: [Solved] Ethernet not working, but Wifi does

#3 2025-06-30 20:56:20

Re: [Solved] Ethernet not working, but Wifi does

#4 2025-06-30 21:23:16

Re: [Solved] Ethernet not working, but Wifi does

#5 2025-07-01 14:45:14

Re: [Solved] Ethernet not working, but Wifi does

#6 2025-07-01 18:27:33

Re: [Solved] Ethernet not working, but Wifi does

#7 2025-07-01 19:29:22

Re: [Solved] Ethernet not working, but Wifi does

Board footer