here’s also some stuff I did with chatgpt, which maybe have some use:
Skip to content
You said:
my nixos system isn't connecting to internet via ethernet. NetworkManager sees the gateway but the gateway doesn't see my computer
ChatGPT said:
Got it — this is a fairly common NixOS + Ethernet issue. Since NetworkManager sees the gateway but the gateway doesn’t see your machine, that usually means link is up but traffic isn’t actually leaving your NIC (or MAC/IP isn’t being registered).
Let’s go through this systematically, starting with the highest-probability causes on NixOS.
1. Confirm link + driver (very important)
First, make sure the kernel driver is actually working.
ip link
You should see something like:
enp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP>
Key things:
UP
LOWER_UP (means physical link detected)
If LOWER_UP is missing, that’s a driver or cable issue.
Also check:
ethtool enp3s0
Look for:
Link detected: yes
If link is no, stop here — it’s physical/driver.
2. Check IP assignment (DHCP)
Since NetworkManager “sees” the gateway, but traffic fails, DHCP may be half-working.
ip addr show enp3s0
You should see something like:
inet 192.168.1.123/24
If you see:
No inet address → DHCP failed
169.254.x.x → DHCP failed (link-local fallback)
Force DHCP renewal:
nmcli device set enp3s0 managed yes
nmcli device disconnect enp3s0
nmcli device connect enp3s0
Then check logs:
journalctl -u NetworkManager --no-pager -n 50
Look for:
DHCP failed
no lease
carrier changed
3. Verify routing (very common silent failure)
Even with an IP, routing may be broken.
ip route
You must see a default route:
default via 192.168.1.1 dev enp3s0
If default route is missing:
nmcli connection show
nmcli connection modify "<connection-name>" ipv4.method auto
nmcli connection up "<connection-name>"
4. ARP test (this reveals the real problem)
Since the gateway doesn’t see your computer, ARP may be failing.
Run:
ip neigh
Then:
ping -c 3 192.168.1.1
ip neigh
Interpretation:
FAILED or INCOMPLETE → gateway never sees your MAC
REACHABLE → ARP works, problem is higher up
If ARP fails, this is usually:
Wrong VLAN
Bad MAC filtering
Driver offload bug
5. Disable offloading (fixes many NixOS Ethernet issues)
Some NICs (Realtek, Intel I225/I226) misbehave with offloading.
Try:
sudo ethtool -K enp3s0 tso off gso off gro off
Then retry pinging the gateway.
If that fixes it, make it permanent in NixOS:
networking.interfaces.enp3s0 = {
useDHCP = true;
};
and add:
systemd.services.disable-offloading = {
wantedBy = [ "multi-user.target" ];
script = ''
ethtool -K enp3s0 tso off gso off gro off
'';
};
6. Check for MAC randomization (gateway “doesn’t see” you)
Some routers reject randomized MACs.
Check:
nmcli device show enp3s0 | grep MAC
Disable MAC randomization:
nmcli connection modify "<connection-name>" 802-3-ethernet.cloned-mac-address permanent
nmcli connection down "<connection-name>"
nmcli connection up "<connection-name>"
7. Firewall sanity check
NixOS firewall usually doesn’t block outbound, but verify:
sudo iptables -L -n
Temporarily disable firewall:
sudo systemctl stop firewall
If it suddenly works → firewall config issue.
8. Quick isolation test (bypass NetworkManager)
This tells us if NM is the problem:
sudo systemctl stop NetworkManager
sudo dhclient enp3s0
If this works, the issue is NetworkManager config, not the driver.
The 3 most common root causes (based on your symptom)
Given “gateway sees nothing”, the most likely are:
Broken NIC offloading
MAC randomization rejected by router
Driver issue (especially Realtek / Intel 2.5G)
Next step (so I don’t guess)
Reply with:
Output of ip link
Output of ip addr show enp3s0
Output of ip route
Your NIC model (lspci | grep -i ethernet)
With that, I can tell you exactly what’s wrong and how to fix it permanently on NixOS.
You said:
enp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> is present
ethtool is not present on my system
inet address is present with the static ip that I gave the machine
no warnings for my Ethernet adapter in journalctl; although some errors when attempting internet connection via USB tethering from my phone: "set-link: failure to set link negotiation", "set-link: failure to reset link negotiation" and some dns-sd-resolved warnings: "send-updates SetLinkDomains@n failed: GDBus.Error:org.freedesktop.resolve1.NoSuchLink: Link n not found"
default ip route is present
ip neigh: "IPV6_ADDRESS_HERE dev vnet0 FAILED"
ChatGPT said:
Thanks, that narrows it down a lot. Based on what you’ve given, this is almost certainly an L2/ARP problem on IPv4, not DNS, routing, or link state.
Let me explain why, then what to do.
What your info tells us
✅ Physical link is fine
UP, LOWER_UP → cable + PHY + driver OK
✅ IP stack is configured
Static IPv4 address present
Default route present
🚨 ARP is broken (key point)
ip neigh shows only:
IPV6_ADDRESS_HERE dev vnet0 FAILED
No entry for your IPv4 gateway
vnet0 strongly suggests a virtual interface, not your real NIC
This means:
Your machine is not successfully ARPing for the gateway on enp3s0
If ARP fails, the gateway literally cannot see your computer, exactly matching your symptom.
Why this happens on NixOS
Given:
static IP
NetworkManager
no ethtool installed
vnet0 present
The most common causes are:
Wrong interface is actually being used
Wrong subnet or gateway for the static IP
VLAN mismatch
Bridge / virtualization interference
NIC offloading bug (still possible even without ethtool installed)
Step 1: Confirm ARP failure directly (important)
Run this and tell me what happens:
ping -c 3 <YOUR_GATEWAY_IPV4>
Then immediately:
ip neigh show dev enp3s0
Expected if broken:
Ping times out
No neighbor entry OR INCOMPLETE / FAILED
If that’s what you see, we’re 100% confirmed on ARP.
Step 2: Verify your static IP is actually valid
Please double-check these exact values:
ip addr show enp3s0
ip route
Specifically:
IP address (e.g. 192.168.1.10/24)
Gateway (e.g. 192.168.1.1)
⚠️ Common mistake:
IP like 192.168.1.10/24
Gateway like 192.168.0.1
→ ARP will never work
The gateway must be in the same L2 subnet.
Step 3: Check if enp3s0 is actually the active NM device
NetworkManager sometimes silently prefers another interface.
nmcli device status
You should see:
enp3s0 ethernet connected
If you see:
vnet0 connected
enp3s0 unmanaged or disconnected
Then NM is not using your real NIC.
Fix:
nmcli device set enp3s0 managed yes
nmcli device connect enp3s0
Step 4: Virtualization is a red flag here
The presence of vnet0 means libvirt / qemu bridge networking.
This can break ARP if:
enp3s0 is enslaved to a bridge
NM is configuring the wrong layer
Check:
bridge link
If enp3s0 is part of a bridge (virbr0, etc.), your IP must be on the bridge, not enp3s0.
If you see that, say so — the fix is different and very specific.
Step 5: Install ethtool (you need it)
Even though link is up, offloading bugs can still kill ARP.
Install temporarily:
nix-shell -p ethtool
Then:
sudo ethtool -K enp3s0 tso off gso off gro off
Retry pinging the gateway.
If this fixes it, we’ll make it permanent in your NixOS config.
Step 6: Eliminate NetworkManager entirely (quick isolation)
This is the fastest way to prove whether NM is the culprit:
sudo systemctl stop NetworkManager
sudo ip addr flush dev enp3s0
sudo ip addr add <YOUR_IP>/<PREFIX> dev enp3s0
sudo ip link set enp3s0 up
sudo ip route add default via <GATEWAY>
ping <GATEWAY>
✅ If this works → NetworkManager config issue
❌ If this fails → driver / VLAN / L2 issue
What I need next (minimal)
Please reply with:
Output of ping <gateway>
Output of ip neigh show dev enp3s0
Output of nmcli device status
Whether bridge link shows enp3s0 enslaved
With that, I can tell you exactly which of the above it is and give you the precise NixOS fix.
You said:
ping -c 3 <YOUR_GATEWAY_IPV4> - destination port Unreachable
ip neigh show dev enp3s0 - no output
ip addr show enp3s0 - device IP is present, no gateway IP
IP Route - default via correct gateway, src is the device IP; network address is correct
nmcli device status - enp3s0 ethernet connected, lo loopback connected (externally), virbr0 bridge connected (externally), vnet0 tun connected (externally)
bridge link - vnet0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master virbr0 state forwarding priority 32 cost 2
sudo systemctl stop NetworkManagersudo ip addr flush dev enp3s0sudo ip addr add <YOUR_IP>/<PREFIX> dev enp3s0sudo ip link set enp3s0 upsudo ip route add default via <GATEWAY>ping <GATEWAY>
FAILED, destination port unreachable.
ChatGPT said:
Great, thanks — this is now very clear.
You’ve done the right isolation steps, and the result is definitive.
The key smoking guns
1. No ARP entries at all for enp3s0
ip neigh show dev enp3s0
# (no output)
That means:
Your kernel is not successfully resolving L2 neighbors
The gateway never learns your MAC
This is below IP, so DNS, routing, NM, static vs DHCP don’t matter
2. Fails even without NetworkManager
You manually configured IP + route and still get:
Destination Port Unreachable
That rules out NetworkManager entirely.
3. That error message is very important
ping normally times out if packets just disappear.
“Destination Port Unreachable” immediately usually means:
The local system is rejecting packets
OR nftables/iptables is actively sending ICMP rejects
OR a netdev-level firewall rule is blocking ARP/ICMP
This is not a normal “network down” symptom.
What this is NOT
❌ Not a gateway problem
❌ Not IP config
❌ Not routing
❌ Not DNS
❌ Not NetworkManager
❌ Not virtualization bridge (enp3s0 is not enslaved)
What this almost certainly IS
👉 nftables / firewall blocking traffic at L2 or early L3
On NixOS this can happen if:
networking.firewall.enable = true;
A netdev or ingress nftables table exists
Or a leftover custom ruleset exists
ARP can be blocked by nftables — and when it is, you get exactly this behavior.
Step 1: Prove it (safe test)
Run this temporarily:
sudo systemctl stop firewall
sudo nft flush ruleset
Then immediately:
ping <gateway>
ip neigh show dev enp3s0
If this suddenly works:
✅ Problem confirmed: firewall ruleset
Step 2: If it works — the permanent NixOS fix
Edit your NixOS config and ensure:
networking.firewall.enable = false;
OR, if you want the firewall:
networking.firewall = {
enable = true;
allowPing = true;
checkReversePath = false;
};
Then rebuild:
sudo nixos-rebuild switch
Step 3: Check for netdev / ingress rules (very likely)
Even if the firewall service is stopped, check:
sudo nft list ruleset
If you see anything like:
table netdev filter
table netdev ingress
Those can block ARP.
They should not exist on a normal workstation.
Step 4: One more subtle but real cause — wrong prefix length
Double-check this carefully:
ip addr show enp3s0
If you see something like:
inet 192.168.1.10/32
or
/31
ARP will fail even with a “correct-looking” route.
For a normal LAN it should be:
/24 (255.255.255.0)
Why libvirt is not the cause (important)
enp3s0 is not enslaved to virbr0
vnet0 is correctly bridged
This setup does not interfere with host ARP unless firewalling is involved
So you don’t need to remove libvirt.
Final diagnosis (with high confidence)
Your system is blocking ARP / ICMP locally via nftables/firewall, causing:
No ARP entries
Gateway never sees your MAC
Immediate “Destination Port Unreachable”
Next reply — just one thing
Please run:
sudo nft list ruleset
Paste it (or confirm that flushing fixed everything), and I’ll tell you exactly which rule is responsible and how to fix it cleanly in NixOS.
You said:
sudo systemctl stop firewall
sudo nft flush ruleset
I don't have nft on my system and I don't have network to temporarily obtain it
ChatGPT said:
Perfect — and thanks for sticking with this, because this detail actually changes the conclusion in a useful way.
If you do not have nft installed at all, then:
networking.firewall (nftables) is not active
There is no netdev / ingress filtering
The “Destination Port Unreachable” is not coming from nftables
So we go one layer lower.
Re-interpreting the symptoms (correctly, now)
Let’s restate the hard facts:
Link is up (LOWER_UP)
Static IP + route configured
Fails with NM and without NM
No ARP entries ever appear
Gateway never sees your MAC
Immediate ICMP error, not timeout
No nftables, no firewall
libvirt bridge exists but does not enslave enp3s0
This combination points to the NIC itself never transmitting frames, even though the kernel thinks it is up.
That narrows it to exactly three real causes.
The actual likely causes (ranked)
🥇 Broken / missing NIC firmware
Very common on NixOS, especially with:
Intel I219 / I225 / I226
Realtek RTL8125 / RTL8168
Without firmware:
Link comes up
IP config works
ARP never leaves the machine
🥈 Wrong kernel driver bound
The wrong module can bring link up but not TX.
🥉 VLAN tagging mismatch
If your switch/router expects untagged traffic but your NIC is tagging (or vice versa), ARP dies silently.
Step 1: Identify the NIC (this is critical)
Run:
lspci -nn | grep -i ethernet
Paste the full line.
This tells us exactly which firmware or driver is missing.
Step 2: Check which driver is loaded
Run:
lspci -k | grep -A3 -i ethernet
Look for:
Kernel driver in use:
Kernel modules:
Step 3: Check firmware loading errors
Even without internet, logs will tell us:
dmesg | grep -i firmware
dmesg | grep -i eth
If you see:
failed to load firmware
or
Direct firmware load failed
→ this is the bug.
Step 4: The NixOS fix (offline-safe)
Once you tell me the NIC model, I’ll give you the exact config, but the most common fix is:
hardware.enableRedistributableFirmware = true;
and sometimes:
boot.kernelPackages = pkgs.linuxPackages_latest;
Then:
sudo nixos-rebuild switch
This works offline as long as the firmware is already in your nix store (often is).
Step 5: One fast sanity test (no new packages)
Run:
ip -s link show enp3s0
Then ping the gateway again and re-run it.
If:
RX increases
TX stays at 0
That proves the NIC is not transmitting.
Why I’m confident this is firmware/driver
ARP never appears
Firewall eliminated
NM eliminated
Route correct
Link up
Immediate ICMP error
This is textbook “NIC up, firmware missing”.
Next (only thing I need)
Reply with:
lspci -nn | grep -i ethernet
Output of ip -s link show enp3s0
After that, I can give you a one-shot NixOS config fix tailored to your exact hardware.
You said:
[nika@nixos:~]$ lspci -nn | grep -i ethernet 26:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8125 2.5GbE Controller [10ec:8125] (rev 04) [nika@nixos:~]$ lspci -k | grep -A3 -i ethernet 26:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8125 2.5GbE Controller (rev 04) Subsystem: Micro-Star International Co., Ltd. [MSI] Device 7c84 Kernel driver in use: r8169 Kernel modules: r8169 [nika@nixos:~]$ dmesg | grep -i firmware dmesg: read kernel buffer failed: Operation not permitted [nika@nixos:~]$ sudo dmesg | grep -i firmware [sudo] password for nika: [ 0.266684] Spectre V2 : Enabling Restricted Speculation for firmware calls [ 0.446644] ACPI: [Firmware Bug]: BIOS _OSI(Linux) query ignored [ 0.471212] acpi PNP0A08:00: [Firmware Info]: ECAM [mem 0xf0000000-0xf7ffffff] for domain 0000 [bus 00-7f] only partially covers this bridge [ 2.457694] stage-2-init: removing obsolete symlink \xe2\x80\x98/etc/pki/fwupd/GPG-KEY-Linux-Vendor-Firmware-Service\xe2\x80\x99... [ 2.457807] stage-2-init: removing obsolete symlink \xe2\x80\x98/etc/pki/fwupd/GPG-KEY-Linux-Foundation-Firmware\xe2\x80\x99... [ 2.458508] stage-2-init: removing obsolete symlink \xe2\x80\x98/etc/pki/fwupd-metadata/GPG-KEY-Linux-Vendor-Firmware-Service\xe2\x80\x99... [ 2.963677] systemd[1]: Clear Stale Hibernate Storage Info was skipped because of an unmet condition check (ConditionPathExists=/sys/firmware/efi/efivars/HibernateLocation-8cf2644b-4b0b-428f-9387-6d876050dc67). [ 3.583833] Bluetooth: hci0: Found device firmware: intel/ibt-20-1-3.sfi [ 3.583850] Bluetooth: hci0: Firmware Version: 193-33.24 [ 3.583851] Bluetooth: hci0: Firmware already loaded [ 3.586003] iwlwifi 0000:28:00.0: loaded firmware version 77.30b1cbd8.0 cc-a0-77.ucode op_mode iwlmvm [ 7.518483] amdgpu 0000:2f:00.0: amdgpu: [drm] Loading DMUB firmware via PSP: version=0x02020021 [ 7.519058] amdgpu 0000:2f:00.0: amdgpu: Found VCN firmware Version ENC: 1.33 DEC: 4 VEP: 0 Revision: 13 [ 7.519154] amdgpu 0000:2f:00.0: amdgpu: Found VCN firmware Version ENC: 1.33 DEC: 4 VEP: 0 Revision: 13 [nika@nixos:~]$ sudo dmesg | grep -i eth [ 3.385813] r8169 0000:26:00.0 eth0: RTL8125B, d8:bb:c1:05:62:1b, XID 641, IRQ 126 [ 3.385818] r8169 0000:26:00.0 eth0: jumbo features [frames: 16362 bytes, tx checksumming: ko] [ 3.495388] r8169 0000:26:00.0 enp38s0: renamed from eth0 [ 5.823329] Bluetooth: BNEP (Ethernet Emulation) ver 1.3 [ 139.397738] usbcore: registered new interface driver cdc_ether [nika@nixos:~]$ ip -s link show enp38s0 2: enp38s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000 link/ether d8:bb:c1:05:62:1b brd ff:ff:ff:ff:ff:ff RX: bytes packets errors dropped missed mcast 62504 932 0 840 0 16 TX: bytes packets errors dropped carrier collsns 1816 22 0 0 0 0 altname enxd8bbc105621b
ChatGPT said:
Thanks for the detailed output! Based on the information you've provided, I can now clearly see what's going on. Here's the breakdown:
Key Findings:
NIC Model:
The NIC is a Realtek RTL8125 (2.5GbE), and the driver in use is r8169. This is one of the commonly affected drivers for Realtek NICs, especially with NixOS.
Firmware Loading:
Your logs show that there’s no specific firmware loading for the Realtek NIC. The dmesg output doesn't indicate any firmware-related issues directly, but this is a common cause for malfunctioning NICs, especially with Realtek drivers.
Driver:
The r8169 driver is loaded, but this does not always work well with the RTL8125 chipset. The RTL8125 often needs the r8125 driver, a proprietary driver, to function correctly in some cases.
No Transmission (TX):
In the ip -s link show enp38s0 output, the TX bytes are extremely low (1816), indicating that your NIC is receiving packets but is not transmitting anything — this strongly suggests that ARP requests (and other outbound packets) are being dropped or not transmitted properly.
Step 1: Use the Correct Driver
The r8169 driver is not ideal for the RTL8125 chipset. The correct driver for the RTL8125 is the r8125 driver. This can fix issues with ARP and packet transmission.
You can install the r8125 driver from source or use the r8168 driver (which is also compatible with this chipset). Here’s how to proceed:
Step 2: Install the r8125 Driver
Install the driver manually:
Since you don't have internet access right now, you'll need to get the driver offline. Here’s what you can do:
Download the driver from the Realtek website
.
Or, download it from another machine and transfer it via USB.
Compile and install the driver:
Once you have the driver on your system, you can compile and install it manually.
Extract the driver (if it's compressed):
tar -xvf r8125-x.x.x.tar.bz2
cd r8125-x.x.x
Compile the driver:
make
sudo make install
Unload the old r8169 driver (to avoid conflict):
sudo modprobe -r r8169
Load the r8125 driver:
sudo modprobe r8125
Ensure it loads on boot:
Add r8125 to your NixOS configuration:
boot.kernelModules = [ "r8125" ];
Then rebuild your system:
sudo nixos-rebuild switch
Step 3: Re-test the NIC
After you install the r8125 driver, check:
ip -s link show enp38s0
You should see TX bytes increasing, indicating that the NIC is now transmitting packets properly.
Additionally, test ARP and routing again:
ping <your_gateway_ip>
ip neigh show dev enp38s0
If ARP works and packets are transmitted, you're good to go.
Step 4: Check for Missing Firmware (if needed)
If you’re still facing issues, check that the firmware is installed. Sometimes, the r8169 driver may still require specific firmware to work with your RTL8125 NIC.
You can enable the redistributable firmware in your NixOS configuration:
hardware.enableRedistributableFirmware = true;
Then rebuild:
sudo nixos-rebuild switch
Conclusion
The key issue here is the driver mismatch (r8169 instead of r8125), and installing the correct driver should solve your ARP issue and enable proper transmission.
Let me know how it goes after following these steps! If you need any further assistance, feel free to ask.
ChatGPT can make mistakes. Check important info. See Cookie Preferences.
