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

Ranks 1 and 2 together account for most real-world failures, and both are free to fix. For a full walkthrough of why Fast Startup changes the outcome and how to prove which power state your machine actually entered, see Windows Fast Startup and Wake-on-LAN: Was Your Shutdown Really S5?.

Owner reports: what recurs across community threads

Our five-run protocol produces a number for one machine. Community threads produce something different and arguably more useful: the frequency with which the same explanation keeps resurfacing. The table below summarises the recurring explanations in the third-party material listed at the end of this page. It is a summary of what those sources report, not a measured sample, and the “aligns with” column points back to the ranked causes above.

Two of those reports are worth acting on directly, because they change the order of the checklist. If wake works from a cold start but fails after a resume, go straight to the adapter’s power-management flag rather than the firmware. And if the NIC’s LEDs are dark while the machine is off, stop testing software: the firmware is not powering the adapter, and no driver setting will change that.

Why one failure in five matters. Our own measurement returned 5/5 for shutdown wake and 4/5 for sleep wake. The four passing runs would have been reported as a success by anyone testing once; the fifth is what identifies sleep wake as the weaker path. Treat an intermittent result as the finding, not as noise around a success.

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:

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.
• ACPI S5 wake sources: PME, RTC and PCIe wake — what each firmware wake option actually arms, state by state.
• Realtek r8169 driver troubleshooting — when the cause is the NIC driver itself: 100Mbps links, drops and WOL flags.
• 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.