TIL: you can wake on lan from full shut down
I bought a JetKVM recently along with an ATX power controller board -- the kind that has leads that go into your motherboard's front panel pins so the KVM can cycle power and reset the machine remotely. It's a neat piece of hardware. I've been running home servers for a while and figured it'd close the last gap: being able to turn the machine back on when it's fully off even when I'm miles away since I have the JetKVM running on my Tailnet.
I couldn't get the ATX board to work though. Even though the extension is loaded in JetKVM and it's clearly delivering power over the RJ11 connection (meaning that at least the physical link is fine) -- clicking on Power on the JetKVM interface did nothing. I tried replugging the pins, double checking that I've got the proper pinouts, and after some fiddling and a fair bit of annoyance, I figured maybe I'd just set it aside and accept that some machines are just gonna need a physical finger-press on the power button now and then.
Then I was staring at the JetKVM UI when I noticed something: it has Wake on LAN built in. You just send it a magic packet and it wakes the machine. No ATX controller needed.
I'd honestly assumed WoL was one of those "works from sleep" things. I knew it could wake from suspend -- you close your laptop at home, come into the office, send a packet, and it's awake. But from full shut down? S5, where the OS is gone and the machine is essentially a cold block of glass? I genuinely thought that was out of scope.
Turns out I was wrong.
The rabbithole
I figured I'd check whether my Arch-based home server was already wired for this. Turns out it was, in a very Linux-y way where the feature is half-enabled across three different subsystems and nobody thought to tell you.
After a bit of digging and telling my Hermes Agent to do some deep research, I have a pretty good map of how to test it out.
First, ethtool told me the NIC (a Realtek RTL8125 2.5GbE controller) supports WoL from the factory -- pumbg, which means physical link change, unicast, multicast, broadcast, and magic packet. But it was set to d -- disabled. So I flipped it:
sudo ethtool -s enp10s0 wol g
That's step one. Except of course that doesn't survive a reboot. The setting lives in driver state, which vanishes when the kernel unloads the module.
Step two was NetworkManager:
sudo nmcli connection modify "Wired connection 1" ethernet.wake-on-lan magic
That persists across reboots since NM reapplies connection profiles on interface activation. But I also threw in a udev rule as a belt-and-suspenders move, in case something else touches the driver between boots:
ACTION=="add", SUBSYSTEM=="net", KERNEL=="enp10s0", RUN+="/usr/bin/ethtool -s enp10s0 wol g"
Step three was the part that actually matters for S5 wake: the ACPI wakeup chain. WoL from full shutdown requires the PCI Express path from the root complex down to the actual NIC port to be armed in firmware. On AMD boards this shows up as a cascade of bridge nodes in /proc/acpi/wakeup -- things like GPP7, UP00, DP18, and the NIC slot itself.
They were all already *enabled. So in theory, the entire hardware path was open and waiting for a magic packet.
The BIOS question
There's no way to read BIOS settings from the OS -- no dmesg line, no sysfs entry, nothing that says "ErP: off" or "Wake on LAN: on." The OS only sees what the firmware produces after applying those settings. And I was too lazy to shut down, try spamming F12 over the JetKVM stream, and reboot again if I didn't get into BIOS so there wasn't a direct way for me to see whether I could WoL from power off on the BIOS level.
The one thing that could prevent WoL from S5 is ErP (Energy-related Products) or EuP mode in BIOS. It's a power-saving feature that cuts standby power when the machine is off. And WoL needs standby power to keep the NIC listening. If ErP is on, the ethernet port LED goes dark on shutdown and the machine is effectively dead until you press the button.
So there was only one way to test it -- a full shutdown. So I just... shut it down.
And sent a magic packet from my laptop via JetKVM.
It worked. Full S5 to booted Linux, no physical contact required.
So what's the point?
I'd been carrying this assumption for years that Wake on LAN was a "from sleep" feature. Like it needed enough power state to keep the OS or at least the kernel around. But the NIC firmware handles it entirely independently -- a tiny state machine in the ethernet controller that listens for a specific packet pattern and asserts the PME signal when it sees one. The OS doesn't even need to exist for it to work.
The JetKVM ATX controller is going in the drawer, I guess. Not useless -- it still gives hard-reset capability for when the machine is crashed and not even listening on the network, if I ever do decide to want that sometime in the future. But for normal remote power-on, the NIC was enough all along.
Pretty nifty what JetKVM and Tailscale let you pull off!