Wake-on-LAN Not Working: 12 Causes Ranked by Likelihood

Why Wake-on-LAN fails more often than it works

Wake-on-LAN is not a single feature. For a magic packet to turn a machine on, five independent layers all have to cooperate: the firmware must keep the NIC powered, the driver must advertise wake capability, the operating system must not fully power down the device, the switch must still deliver the packet, and the sender must address it correctly. Break any one layer and the machine stays asleep — with no error message anywhere.

That is why “Wake on Magic Packet is enabled but it still does not wake” is the most common WOL complaint. The checkbox is one of five conditions.

This page ranks the twelve causes we see most often, ordered by how frequently they are the actual culprit, and ends with a repeatable test protocol. If you already know that shutdown wake works but sleep wake does not, go straight to the symptom-first diagnosis for S5 works / S3 fails.

The 12 causes, ranked by likelihood

#	Cause	How often it is the culprit	How to check in 60 seconds	Fix
1	Wrong adapter configured	Very common	Disconnect the cable and watch which NIC drops link in Device Manager	Configure that adapter, not the first identically named one
2	Fast Startup enabled	Very common	`powercfg /a` — if “Fast Startup” is listed as active	Disable it in Power Options → Choose what the power buttons do
3	NIC not allowed to wake the computer	Very common	Device Manager → adapter → Power Management tab	Tick “Allow this device to wake the computer”
4	Magic packet sent to the wrong MAC/broadcast	Common	Compare the sender’s target MAC with `getmac /v` output	Send to the wired adapter’s MAC, on the same subnet
5	Test started from the wrong power state	Common	Note whether you used shutdown (S5), sleep (S3) or hibernate (S4)	Test each state separately — they use different paths
6	Link speed negotiation after shutdown	Common	S5 wake fails but S3 works	Set `WOL & Shutdown Link Speed` to `10 Mbps First`
7	Firmware WOL / power-on setting off	Occasional	BIOS/UEFI → power or wake settings	Enable WOL / wake by PCI-E; see the BIOS settings guide
8	ERP / deep power saving	Occasional	BIOS → ERP Ready or EuP setting	Disable ERP, or accept S5 wake will not work
9	State After G3 wrong after power loss	Occasional	Kill AC power, restore it, observe behaviour	Set State After G3 to Power On; see AC power recovery
10	Switch/router drops broadcast across VLANs	Occasional	Send from a device on the same subnet	Use a directed packet or a WOL relay on that subnet
11	Wireless adapter used as the wake target	Rare	Check whether the machine is on Wi-Fi	Most Wi-Fi adapters do not support WOL; use wired
12	NIC genuinely loses standby power	Rare	LEDs fully off in S5, no link light	Hardware limitation — no software fix

Ranks 1 and 2 together account for most real-world failures, and both are free to fix.

Decision tree: start from the symptom

Machine does not wake
├── LEDs on the NIC are completely off
│   └── Firmware is cutting standby power → causes 7, 8, 12
├── LEDs are on, but nothing happens on the packet
│   ├── Which power state did you test?
│   │   ├── S5 (shutdown) fails, S3 (sleep) works → cause 6 (link speed)
│   │   ├── S3 fails, S5 works → see the S3-specific guide
│   │   └── Both fail → causes 1, 2, 3
│   └── Does it work from another sender on the same subnet?
│       ├── Yes → cause 4 or 10 (addressing / network path)
│       └── No  → causes 1, 2, 3, 5
└── It wakes sometimes, not always
    └── Count the failures out of five runs → run the 5-run protocol below

If the machine wakes intermittently, do not treat a single success as a fix — that is exactly the failure mode we measured below.

The 5-run test protocol (and what ours returned)

Do not test once. Run each power state five times and record the result:

Test	Starting state	Result on our EQi12
Shutdown wake (S5)	Full shutdown	5/5 passed
Sleep wake (S3)	Sleep	4/5 passed
AC-loss recovery (G3)	Mains power removed	3/3 returned to previous state

The S5 result proves the NIC receives and acts on a magic packet after shutdown. The S3 result is the interesting one: one run out of five failed, which means sleep wake was not reliably reproducible even though the same configuration passed the shutdown test four times in a row. A single successful wake would have hidden that entirely.

Commands worth running

# Which power states does this machine actually support?
powercfg /a

# Is the adapter allowed to wake the machine?
powercfg /devicequery wake_armed

# List adapters with their MAC addresses (match this to your sender)
getmac /v

On Linux, check whether wake is enabled before blaming the network:

# Replace eth0 with your interface name
sudo ethtool eth0 | grep -i wake
# Look for: Supports Wake-on: g    Wake-on: g
# If Wake-on shows "d", enable it with:
sudo ethtool -s eth0 wol g

Note that ethtool -s does not survive every reboot by itself — persist it through NetworkManager (nmcli connection modify ... 802-3-ethernet.wake-on-lan magic) or a systemd link file.

Things that are genuinely not fixable

Some failures are hardware or topology limits, not misconfiguration:

Wi-Fi Wake-on-LAN is unsupported on most client adapters. If the machine is on wireless, move to wired.
Cross-subnet magic packets are frequently dropped. Switches do not forward L2 broadcasts between VLANs by design; you need a helper on the target subnet.
Deep sleep power states (S4/S5 with ERP enabled) cut standby power to the NIC entirely. Nothing can wake a chip that has no power.

If your case matches one of these, the honest answer is to change the topology, not to keep toggling driver settings.

Where to go next

Wake-on-LAN works from shutdown but not sleep — the symptom-first path when S5 passes and S3 is intermittent.
Realtek Wake-on-LAN on Windows — driver-level configuration, including the WOL & Shutdown Link Speed behaviour.
BIOS settings for home-server use — firmware-side WOL, ERP and State After G3.
Automatic recovery after AC power loss — when “wake” is really about returning after a mains event.
WOL troubleshooting wizard — interactive version of this checklist.
EQi12 review hub — every measured report for this machine, including the WOL cycles referenced above.

All WOL figures quoted on this page come from the test cycles recorded in the open eqi12-measurement-data repository.