The Symptom Tells You Where to Look
Wake-on-LAN either works or it does not, and the useful diagnostic information is in exactly when it stops working. Before changing anything, place your failure in one of these rows:
| Symptom | Almost always |
|---|---|
| Never worked at all | WOL disabled in BIOS or NIC driver |
| Works from sleep, not from shutdown | Fast Startup, or "wake from S5" not enabled |
| Worked, then stopped after a power cut | NIC lost standby power / BIOS setting reset |
| Works for a while, fails after hours idle | NIC deep power-saving, or the ARP/switch entry aged out |
| Works from the same room, not from the server room | Different subnet — broadcast not routed |
| Works to one PC, not the identical one next to it | MAC typo, or that machine's BIOS differs |
These map to genuinely different causes, and the order you check things in should follow the row you are in — not a generic checklist.
What a Magic Packet Actually Is
Understanding the packet removes a lot of mystery:
6 bytes of 0xFF + the target MAC repeated 16 times
FF FF FF FF FF FF AABBCCDDEEFF × 16
= 102 bytes totalThat is the entire protocol. It is sent as a UDP broadcast, normally to 255.255.255.255.
Three consequences follow directly, and they explain most of the confusion:
- There is no reply. WOL is fire-and-forget. Your control system cannot tell you whether it worked — it can only tell you the packet was sent. "The software says it succeeded" means nothing more than "the broadcast left the building".
- There is no authentication and no addressing beyond the MAC. Any device on the segment can send it.
- Because it is a broadcast, it does not cross routers by default. This is the single biggest architectural gotcha, covered below.
Port 9, or port 7?
The port is essentially arbitrary — the NIC listens for the magic pattern, not for a port. But the sending stack still has to pick one, and devices differ in which they accept: port 9 is the common default, some hardware only listens on port 7.
The robust approach is to send to both. SoftControl's WOL driver does exactly this: it broadcasts on the configured port (default 9) and, if that port is not 7, sends a second broadcast on port 7 — because the cost of an extra 102-byte packet is nothing and the cost of a projector PC that will not wake is a site visit.
If you are using a tool that only sends on one port and a machine refuses to wake, try the other port before assuming the NIC is at fault.
The Big One: Fast Startup Breaks Wake-from-Shutdown
This is the most common cause of "wake works from sleep but not after shutdown" on Windows.
Windows Fast Startup does not really shut down. It hibernates the kernel session, and on many NIC drivers that path does not arm the wake filter, even though the same NIC wakes correctly from sleep.
The symptom is precise and reproducible: sleep → wake works; shut down → dead.
Fix: disable Fast Startup (Control Panel → Power Options → Choose what the power buttons do → Change settings that are currently unavailable → uncheck "Turn on fast startup"). On a signage or exhibition PC you want this off anyway — Fast Startup also causes stale-state problems that a genuine cold boot would clear.
Related, on the NIC itself: Device Manager → network adapter → Power Management → enable "Allow this device to wake the computer", and on the Advanced tab enable Wake on Magic Packet. Some drivers additionally expose "Wake on pattern match" and a "Shutdown Wake-On-Lan" or "Wake from S5" option — S5 is the full-off state, and if that option exists and is disabled, wake-from-shutdown will never work no matter what else you configure.
After a Power Cut
WOL requires the network card to keep receiving standby power while the machine is off. After a mains failure or after the machine was unplugged, two things commonly change:
- Some BIOS/UEFI implementations reset the "Wake on LAN / Power on by PCI-E" setting, or the CMOS battery is flat and the whole configuration reverted.
- The NIC may not re-arm its wake filter until the OS has booted once. A machine that lost power and was never manually booted afterwards may not be wakeable at all — there is nothing armed to listen.
This is worth designing around in an exhibition hall: if the building cuts power at night, WOL alone is not a reliable morning start. Use the BIOS "restore on AC power loss" / "power on after power failure" setting so the machine boots itself when mains returns, and use WOL for the ordinary day-to-day case.
"Checking Media Presence" — Lenovo and Friends
A machine that shows Checking Media Presence… / Media Present / Start PXE over IPv4 on boot and then hangs or falls through has woken up and tried to network boot instead of loading Windows.
This is not really a WOL fault — the wake worked. The boot order is wrong: the NIC is ahead of the SSD in the boot priority, which frequently happens when a wake event triggers a network-boot path.
Fix: in BIOS, put the SSD first in boot priority, and disable PXE / Network Boot entirely if you do not use imaging. Also look for "Network Stack" and turn it off. The machine will then wake and boot locally.
On some Lenovo models the same symptom appears after enabling WOL because enabling WOL also enables the network stack. Turning off PXE while leaving WOL on is the correct combination.
Waking Across Subnets
A broadcast to 255.255.255.255 never leaves its subnet. Routers drop it. This is why WOL works from a laptop on the same switch and fails from the control server in the rack room.
Three options, best first:
1. Put the sender on the same VLAN. If your control PC and the target machines share a subnet, the problem disappears. In exhibition work this is usually achievable and is the least fragile answer.
2. Directed broadcast. Instead of 255.255.255.255, send to the target subnet's broadcast address — for 192.168.10.0/24 that is 192.168.10.255. This packet is routable, but the router must be configured to forward directed broadcasts (on Cisco gear, ip directed-broadcast on the destination interface). Many networks disable this by default for security reasons, so it needs the network owner's agreement.
3. A relay on the target subnet. A small always-on device (or one of the signage PCs that stays on) receives an instruction over TCP and issues the local broadcast. This is the most reliable option in networks you do not control.
Note also that switches age out MAC address entries. A machine that has been off for hours may no longer be in the switch's MAC table, meaning a unicast WOL packet has nowhere to go — which is another reason the protocol uses broadcast, and another reason directed broadcast is preferable to unicast-to-IP.
Wi-Fi
Plain WOL over Wi-Fi generally does not work. The magic packet mechanism assumes a wired NIC holding a link while powered down; Wi-Fi adapters drop association when the machine powers off. There is a separate standard (WoWLAN) with patchy support.
For anything unattended, use Ethernet. This is not a limitation worth fighting.
MAC Address Formatting
The MAC is the only addressing the packet has, so a typo is fatal and silent. Formats accepted by most tools — and by SoftControl's driver, which normalises all of these — include:
AA:BB:CC:DD:EE:FF
AA-BB-CC-DD-EE-FF
AA.BB.CC.DD.EE.FF
aabbccddeeffUse the MAC of the interface that will be connected, which on a machine with both Wi-Fi and Ethernet is not always the one shown first. ipconfig /all lists them per adapter; take the one labelled Ethernet.
The Full Checklist, In Order
- BIOS/UEFI: Wake on LAN / Power on by PCI-E enabled; PXE/Network Boot disabled; boot order SSD first.
- BIOS: "Restore on AC power loss" set to On, if the hall cuts power at night.
- Windows: Fast Startup off.
- NIC driver: "Allow this device to wake the computer" on; Wake on Magic Packet on; "Shutdown Wake-On-Lan"/S5 on if present.
- Cable: wired Ethernet, link LED lit while the machine is off — if the LED is dark when powered down, the NIC has no standby power and nothing else matters.
- Same subnet as the sender, or directed broadcast configured.
- Correct MAC, of the correct adapter.
- Try both port 9 and port 7.
Step 5 is the fastest single test. Shut the machine down and look at the network port. No link light means WOL cannot possibly work, and you have narrowed it to BIOS/hardware in ten seconds without touching software.
With SoftControl
SoftControl supports Wake-on-LAN natively alongside TCP, UDP, PJLink, serial and Modbus, so powering up the media PCs and then controlling the projectors is one sequence in one interface. Its WOL driver normalises any common MAC format and broadcasts on both the configured port and port 7.
One honest caveat worth repeating: WOL is fire-and-forget, so no control system can confirm a wake. The right pattern for an unattended hall is to send the magic packet and then poll the machine — a TCP connection attempt or an HTTP request to the player — to confirm it actually came up, rather than trusting the send. See the SoftPlayer and player control approach for how the power-up and the readiness check fit together.