Proof Portal
Omarchy
ProbeLabs65 findings · 95 requirementsA proof layer — requirements, tests and verified fixes — for two of Omarchy's subsystems: the application menu (launcher scripts, QML model, JSONC config, search and selection) and the lock screen (lock scripts, QML, PAM authentication). Scope is deliberately limited to those components of omacom/omarchy; the rest of the distribution is not covered.
Wired ethernet stopped getting a DHCP lease after upgrading to Quattro (RTL8125 NICs)
Reported by donutWolf · filed Aug 22, 2026 · open at source
At a glance
- 1 · What is claimed?
- Only the report text below — no validator has restated it as checkable claims yet.
- 2 · What does it affect?
- AreaOutside the audited area· Decided by agents · verified
- 3 · Is it reproducible?
- No validation has been run yet.
- 4 · What remains unclear?
- Not validated yet: no claims, no reproducer.
- 5 · What happens next?
- Decided by agents and verified by a second, independent agent — see the decision.
Original report
System details
AMD 9800X3D, RX9070 XT, OMARCHY 4.0
What's wrong?
TL;DR: After upgrading to Omarchy 4.0 "Quattro," my wired ethernet connection stopped picking up a DHCP lease entirely — link showed up, cable was fine, but no IP address, ever. Root cause turned out to be a checksum offload bug in the in-kernel r8169 driver for the Realtek RTL8125D 2.5GbE chipset, not anything network or router related. Fix is a one-line ethtool command made persistent via a systemd service.
Symptoms
Wired ethernet (eno1 in my case) showed link up, correct speed/duplex negotiation, cable and switch port confirmed good
nmcli/networkctl both reported DHCP timing out with no lease, every time, on every retry
WiFi worked fine
Nothing had changed on my router/network — confirmed by booting into Windows on the same machine, same cable, same port: got a clean DHCP lease immediately
What didn't fix it (ruled out, in case you hit the same symptoms)
Local firewall rules (ufw/nftables) — explicit DHCP-reply accept rule existed, 0 packets ever matched it
EEE (Energy Efficient Ethernet) — already correctly disabled via a prior fix
DHCP client identifier format (DUID vs plain MAC) — tested both, no difference
Switching between NetworkManager and systemd-networkd — both failed identically
PCIe ASPM — already disabled by the kernel by default for this driver
Link speed/duplex renegotiation — was flaky (see below) but fixing it didn't fix DHCP
The actual cause
The Realtek RTL8125D (and possibly other RTL8125 revisions) has a known category of driver bugs in the Linux in-kernel r8169 driver, separate from Realtek's own proprietary driver used on Windows. In my case, TX checksum offload was computing bad checksums on outgoing packets. tcpdump couldn't catch this because it captures packets before the NIC hardware finishes processing them — so every DHCP request looked completely normal leaving the machine, while the router silently dropped every one due to the corrupted checksum, and never sent a reply.
The fix
Disable TX checksum offload on the interface:
Bash
(swap eno1 for your actual interface name)
This doesn't persist across reboots on its own, so make it permanent with a systemd service:
Ini
Bash
Reboot to confirm it holds from a cold start. In my case, DHCP completed within a couple seconds of boot with checksum offload disabled — every time.
How to tell if this is your issue
Confirm link is actually up and negotiating correctly: sudo ethtool <iface> — check Link detected: yes and a real Speed: value
Confirm the DHCP request is actually leaving the machine: sudo tcpdump -i <iface> -n udp port 67 or port 68, then try to bring the connection up. If you see DHCPDISCOVER going out repeatedly with zero replies, and your firewall/router aren't the issue, this is worth checking
If you have another OS on the same machine (dual boot), test the exact same cable/port there. If it works cleanly on the other OS, that isolates it to the Linux networking/driver stack rather than anything external
Check your NIC chipset: lspci -k | grep -A3 Ethernet — if you're on an RTL8125 (or similar Realtek 2.5GbE chip) and using the in-kernel r8169 driver, this is a real possibility worth testing before spending hours on router/firewall/DHCP-client theories like I did
Hope this saves someone the few hours I spent on it.
View raw text
### System details AMD 9800X3D, RX9070 XT, OMARCHY 4.0 ### What's wrong? TL;DR: After upgrading to Omarchy 4.0 "Quattro," my wired ethernet connection stopped picking up a DHCP lease entirely — link showed up, cable was fine, but no IP address, ever. Root cause turned out to be a checksum offload bug in the in-kernel r8169 driver for the Realtek RTL8125D 2.5GbE chipset, not anything network or router related. Fix is a one-line ethtool command made persistent via a systemd service. Symptoms Wired ethernet (eno1 in my case) showed link up, correct speed/duplex negotiation, cable and switch port confirmed good nmcli/networkctl both reported DHCP timing out with no lease, every time, on every retry WiFi worked fine Nothing had changed on my router/network — confirmed by booting into Windows on the same machine, same cable, same port: got a clean DHCP lease immediately What didn't fix it (ruled out, in case you hit the same symptoms) Local firewall rules (ufw/nftables) — explicit DHCP-reply accept rule existed, 0 packets ever matched it EEE (Energy Efficient Ethernet) — already correctly disabled via a prior fix DHCP client identifier format (DUID vs plain MAC) — tested both, no difference Switching between NetworkManager and systemd-networkd — both failed identically PCIe ASPM — already disabled by the kernel by default for this driver Link speed/duplex renegotiation — was flaky (see below) but fixing it didn't fix DHCP The actual cause The Realtek RTL8125D (and possibly other RTL8125 revisions) has a known category of driver bugs in the Linux in-kernel r8169 driver, separate from Realtek's own proprietary driver used on Windows. In my case, TX checksum offload was computing bad checksums on outgoing packets. tcpdump couldn't catch this because it captures packets before the NIC hardware finishes processing them — so every DHCP request looked completely normal leaving the machine, while the router silently dropped every one due to the corrupted checksum, and never sent a reply. The fix Disable TX checksum offload on the interface: Bash (swap eno1 for your actual interface name) This doesn't persist across reboots on its own, so make it permanent with a systemd service: Ini Bash Reboot to confirm it holds from a cold start. In my case, DHCP completed within a couple seconds of boot with checksum offload disabled — every time. How to tell if this is your issue Confirm link is actually up and negotiating correctly: sudo ethtool <iface> — check Link detected: yes and a real Speed: value Confirm the DHCP request is actually leaving the machine: sudo tcpdump -i <iface> -n udp port 67 or port 68, then try to bring the connection up. If you see DHCPDISCOVER going out repeatedly with zero replies, and your firewall/router aren't the issue, this is worth checking If you have another OS on the same machine (dual boot), test the exact same cable/port there. If it works cleanly on the other OS, that isolates it to the Linux networking/driver stack rather than anything external Check your NIC chipset: lspci -k | grep -A3 Ethernet — if you're on an RTL8125 (or similar Realtek 2.5GbE chip) and using the in-kernel r8169 driver, this is a real possibility worth testing before spending hours on router/firewall/DHCP-client theories like I did Hope this saves someone the few hours I spent on it.
Validation
Not checked yet. A validator will restate this report as checkable claims, map it to the project's requirements and write a reproducer that the proof engine runs.
Linked
Not linked to any known issue, other report or change yet.
Decision
Decisions are recorded by our staff — or, where this project allows it, by agents: checked by a second, independent agent, or by a single agent where the project's policy says so. Any decision reached so far is shown below.
- Out of scopeDecided by agents · verified · 2026-10-09 08:24 UTC