Wake-on-LAN Explained: Magic Packets, Directed Broadcasts and Security

Wake-on-LAN (WoL) turns on a sleeping or soft-off computer when its network card receives a "magic packet": six bytes of 0xFF followed by the card's own MAC address repeated 16 times. The card watches for that pattern on standby power and signals the motherboard to wake. To wake a machine remotely and safely, send the packet from a device already inside its network, reached over a VPN or SSH, rather than forwarding broadcasts in from the internet.

The format comes from a November 1995 AMD white paper written after AMD and Hewlett Packard set out to let administrators manage PCs that had gone to sleep to save power. The protocol has no authentication worth the name, its optional SecureOn password travels in clear text, and the router feature people reach for when they want to wake machines from another subnet, directed broadcast forwarding, was switched off by default in 1999 because attackers used it to amplify floods. This post goes one level deeper than our homelab UPS guide and our home firewall build, and sits next to our explainers on OpenBMC and Redfish for machines that have a real management controller.

Key takeaways

• A magic packet is a payload, not a protocol. The AMD white paper says the sync stream of six 0xFF bytes and the 16 copies of the MAC address can sit anywhere in a frame, so senders wrap it in a raw Ethernet frame or, most often, a UDP datagram to port 9 (discard) or port 7 (echo).
• The payload is 102 bytes. An optional SecureOn password adds 6 bytes (some tools also accept 4), sent unencrypted, so treat it as a filter against accidental wakes, not as authentication.
• Three layers must agree before WoL works: firmware must keep standby power on the network card, the operating system must arm the card before sleep, and the driver must have magic packet wake enabled. On Linux, ethtool shows the state in one line.
• Microsoft documents that Windows 10's default shutdown is a hybrid shutdown (Fast Startup) during which network adapters are explicitly not armed for wake. WoL is supported from sleep (S3) and from an explicit hibernate (S4). Some firmware can still wake from soft off without Windows being involved.
• RFC 1812 (1995) required routers to forward directed broadcasts by default. RFC 2644 (1999, BCP 34) reversed that: forwarding must default to off. Linux follows suit with bc_forwarding defaulting to 0. Do not turn it back on to make WoL cross subnets.
• The safe way to wake a machine from outside is to reach something that is already awake on the same LAN (the router, a small always-on host) over a VPN or SSH, and send the packet locally.
• For servers, a baseboard management controller using IPMI or Redfish gives authenticated power control that also works when the operating system is hung. Smart plugs and IP-KVMs fill the gap for hardware with neither.

A dated timeline of remote wake

Where did the magic packet come from?

The problem in 1995 was a conflict between two good goals. The US Energy Star programme wanted PCs to go to sleep soon after they fell idle. Corporate IT departments wanted to run backups and software updates overnight. If the PC fell asleep at half past five, the AMD white paper asks, how would IT manage it? And if a user cared more about a nightly backup than about saving power, they would switch power saving off and the Energy Star benefit would be lost.

According to the white paper, AMD and Hewlett Packard had been working on the problem for "almost 2 years" and proposed an industry standard: let the PC go completely to sleep, which they called Deep Green, but keep the Ethernet controller listening for one specific frame. When the frame arrives, the controller alerts the power management circuitry and the machine wakes.

The design choices in the paper explain most of WoL's behaviour today:

• It reuses address matching hardware. An Ethernet controller already compares incoming destination addresses with its own. Making the wake pattern a repetition of that same address meant the silicon only needed a counter and a reset path, not a general pattern matcher.
• It needs no protocol stack. A sleeping PC has no running operating system, so nothing above Ethernet can be relied on. The controller just scans bytes. That is why the payload can be carried in anything.
• It is designed to cross bridges. The paper argues that because a magic packet is a standard Ethernet frame, bridges forward it like any other, and a bridge that has forgotten which port a sleeping node lives on floods the frame to all ports. That is the reason WoL works well on a flat switched LAN, and the reason it stops at the first router.
• Enable and disable are explicit. The controller enters Magic Packet mode when power management sets a register bit or drives a SLEEP# pin, stops transmitting, and only scans. Any wake, whether from a magic packet or a keypress, must return it to normal mode. Modern drivers and firmware still do this arming and disarming, which is where most "it worked once and then stopped" problems come from.

"Wake-on-LAN" became the generic name; "Magic Packet" is the name AMD used. The ethtool manual still marks both "MagicPacket" and "SecureOn" with trademark symbols.

What exactly is in a magic packet?

The AMD white paper defines the payload in two parts:

1. A synchronization stream of 6 bytes of 0xFF.
2. Sixteen consecutive copies of the target's 6 byte IEEE (MAC) address, with no breaks.

The paper allows the sequence to sit anywhere within the packet, and the frame itself must be valid for the network: source address, destination address and CRC. The destination can be the node's own address or a multicast address, which the paper notes includes the broadcast address.

Worked example: building the payload by hand

Take a NIC with MAC address 00:1A:2B:3C:4D:5E.

Carried in UDP over IPv4 on Ethernet, the frame on the wire is 14 bytes of Ethernet header, 20 bytes of IPv4 header, 8 bytes of UDP header, the 102 byte payload and a 4 byte frame check sequence: 148 bytes, comfortably above Ethernet's 64 byte minimum, so no padding is needed. With a 6 byte password it is 154 bytes.

Worked example: why the NIC does not care about IP

Suppose a sender on 192.168.10.0/24 sends the payload in a UDP datagram to 192.168.10.255 port 9. The IP layer turns that into an Ethernet frame to FF:FF:FF:FF:FF:FF. Every NIC on the segment receives it. A sleeping NIC armed for magic packets does not parse the IP header, check the UDP port or look at the checksum of the UDP payload. It scans the frame for 0xFF six times followed by its own MAC sixteen times. That is why port 9 and port 7 are conventions, not requirements: the IANA registry lists UDP 9 as Discard and UDP 7 as Echo, and senders picked them because a machine that happens to be awake will throw the datagram away (discard) or bounce it back (echo) harmlessly. The Debian wakeonlan manual puts it simply: the sequence "can be encapsulated in any kind of packet."

SecureOn: a password that is not a secret

Some controllers support a SecureOn password appended after the 16 MAC copies. Linux exposes it as ethtool -s DEV wol gs sopass xx:yy:zz:aa:bb:cc; the ethtool manual says the argument "must be 6 bytes in Ethernet MAC hex format". The etherwake manual accepts a 4 or 6 byte password and adds that "Only a few adapters need or support this." systemd and NetworkManager both store it as a MAC-formatted string.

Six bytes is 48 bits, which sounds respectable. The problem is not the length. The password is static, shared by every sender, and included in clear text in every wake packet. Anyone who captures one legitimate wake on the segment learns it. It reduces wakes from stray or malformed packets and from someone who has never seen your traffic. It does not authenticate a sender in any modern sense.

How does the NIC stay powered in S3, S4 and S5?

ACPI names the system sleep states. S3 is suspend to RAM: memory stays powered and the system resumes in seconds. S4 is hibernate: memory is written to disk and the machine powers down almost completely. S5 is soft off: the operating system has shut down but the power supply still delivers standby power. Devices have their own states, D0 (fully on) to D3 (lowest power).

WoL works only if four conditions hold at the moment the system sleeps:

1. Standby power reaches the network controller. In S3, S4 and S5 the main rails are off but the power supply keeps a small standby rail alive. The board must route it to the NIC. Many boards gate this with a firmware option, and some laptops cut it entirely when on battery.
2. The controller is armed for wake. The driver or firmware must put the controller in its wake mode before power drops, as the AMD paper's SLEEP# pin or register bit did.
3. The controller can signal the platform. On PCI and PCI Express a wake is a Power Management Event. The Linux wireless WoWLAN documentation, which describes the same mechanism for Wi-Fi, notes that a PCIe device sends a PME message or asserts the PCIE_WAKE_L signal, that the PME message needs the device's PME Enable bit set, and that "on PC platforms often BIOS support is required."
4. The platform honours the wake. The firmware or chipset must treat that event as a wake source from the state the system is in.

What firmware, operating system and driver must agree on

What Microsoft says about Windows

Microsoft's article on Wake on LAN behaviour is precise, and it is worth reading because it explains most Windows WoL failures. In Windows 7 the default shutdown is a classic S5 and all devices go to D3. Microsoft says WoL from S5 is not officially supported there, although some adapters stay armed if enough residual power is available.

In Windows 10 the default shutdown is a hybrid shutdown, also called Fast Startup, which puts the system in S4 with devices in D3. Microsoft states that in this case network adapters "are explicitly not armed for WOL", because users expect zero power draw after shutdown. So WoL is supported from sleep (S3) or from a hibernate the user explicitly requested. Windows disables WoL only for the hybrid shutdown transition, not for a real hibernate, even though both end in S4. Microsoft adds that firmware and hardware on some systems may arm the NIC for wake from S4 or S5 without Windows being involved, which is why the same Windows build can behave differently on two motherboards.

The practical consequence: if a Windows PC wakes from sleep but not from shutdown, Fast Startup is the first thing to check. Microsoft documents how to turn it off under Power Options, "Choose what the power buttons do", while noting that it does not recommend disabling it. You can also leave Fast Startup on and send the machine to sleep or hibernate instead of shutting it down.

What Linux does

On Linux the kernel exposes WoL through the ethtool interface (the netlink API has ETHTOOL_MSG_WOL_GET and ETHTOOL_MSG_WOL_SET), and the ethtool command lists the modes a card supports and the one it has armed. The modes are the same letters across tools:

Only g (with or without s) is what most people mean by Wake-on-LAN. The others are broader and less predictable: wake on unicast or ARP will wake a machine whenever something on the network looks it up, which can keep a box from ever staying asleep.

How is a magic packet sent?

There are four ways to get the frame to the sleeping NIC. They differ in reach and in how much they change your network's attack surface.

1. Layer 2 broadcast on the local segment

The sender builds a raw Ethernet frame to FF:FF:FF:FF:FF:FF, or a UDP datagram to 255.255.255.255. RFC 919 (October 1984) defines that address as a broadcast on the local hardware network that must not be forwarded, and RFC 922 extends the broadcast rules to subnets. Every NIC on the VLAN sees the frame. This is what etherwake does by default with a raw frame, and what wakeonlan does with UDP. It needs no router configuration and cannot leave the broadcast domain, which is a feature.

2. UDP to port 9 or 7 on the subnet broadcast address

Sending to the subnet's broadcast address (for example 192.168.10.255 on a /24) has the same effect as long as the sender is on that subnet. The datagram becomes an Ethernet broadcast.

3. Unicast to a remembered MAC

A sleeping machine cannot answer ARP. If the sender, or the router, keeps a static neighbour entry mapping the target's IP address to its MAC, a unicast UDP datagram to that IP is delivered as a frame addressed directly to the NIC, which the AMD design accepts. This is how some routers wake a single host without broadcasting. It also means that anything able to send a packet to that IP can now wake the machine, so only do it on a router interface you control and never as a port forward from the internet.

4. Subnet directed broadcast from another network

A subnet directed broadcast is a packet addressed to another network's broadcast address, for example a sender on 10.0.0.0/24 sending to 192.168.10.255. If the router in front of 192.168.10.0/24 is configured to forward directed broadcasts, it turns the packet into an Ethernet broadcast on that segment and the magic packet arrives. This used to be the textbook way to wake machines across a campus. It is also the reason a whole class of denial of service attacks existed.

Why RFC 2644 turned directed broadcasts off

RFC 1812, the 1995 router requirements document, said routers must receive and forward directed broadcasts, must offer an option to disable it, and that the option must default to permit. Four years later RFC 2644 observed that the use of directed broadcasts on the internet backbone "appears to be comprised entirely of malicious attacks on other networks."

The attack it had in mind was the Smurf attack. An attacker sends ICMP echo requests to a network's directed broadcast address with the source address forged to be the victim's. The router turns each request into a broadcast, every host on the segment replies, and the victim receives a reply from every host for every request the attacker sent. RFC 2644 calls networks that allow this Smurf amplifiers. NVD's record for CVE-1999-0513, published on 5 January 1998, describes the same condition: ICMP messages to broadcast addresses allowed, enabling a Smurf denial of service.

RFC 2644 made the fix a Best Current Practice, BCP 34. A router may have options to receive and forward network-prefix-directed broadcasts, but both options MUST default to blocking receipt and forwarding. The RFC also points back to ingress filtering (RFC 2267, later RFC 2827 and BCP 38) as the best way to stop the forged source addresses that make reflection work at all. Linux implements the same default: the kernel's ip-sysctl documentation describes bc_forwarding as the feature from RFC 1812 section 5.3.5.2 and RFC 2644, says both the all entry and the input interface entry must be set to 1 to enable it, and gives the default as 0.

A magic packet itself does not amplify: a sleeping machine does not reply, and an awake one sends nothing back to UDP port 9. The danger is in what you turn on to deliver it. A router interface that forwards directed broadcasts forwards them for every protocol, not just WoL, and for every source that can reach it. If you must wake hosts across subnets, run the sender inside the target subnet instead.

How do you wake a machine across the internet safely?

Never expose a broadcast address to the internet. A port forward from WAN UDP 9 to 192.168.10.255 either fails (many routers refuse it), or works and lets anyone on the internet send broadcast frames into your LAN. A port forward to a unicast address backed by a static ARP entry is narrower, but it still means anyone who finds the port can switch your machine on, and it advertises that something listens there.

The pattern that works is to reach something that is already awake inside the target LAN, authenticate to it, and send the packet from there:

Two habits make this safer. First, keep the always-on relay boring: a minimal OS, automatic security updates, SSH keys only, no other services. Our home firewall post covers the VLAN layout that keeps a management host separate from guests and IoT devices. Second, log wakes. A relay that records who sent which wake and when gives you an audit trail the protocol itself never will.

Wake on Wireless LAN, wake on pattern and out-of-band alternatives

Wake on Wireless LAN (WoWLAN)

Wi-Fi complicates WoL because a sleeping station must stay associated with the access point and keep its encryption keys current. The Linux wireless documentation lists WoWLAN triggers including reception of a user specified pattern while connected, reception of a magic packet while connected, disconnection from the access point and finding a network while not connected. It notes that the station hardware still acknowledges frames without the host CPU, and that multicast and broadcast frames can cause trouble under WPA or RSN when the device cannot handle rekeying while the host sleeps. You configure it with iw before suspend, and the kernel tells the driver which triggers to arm.

In practice WoWLAN is far less dependable than wired WoL, especially from S4 or S5, where the radio usually has no power at all. Laptops that support it typically wake only from sleep, and only while still connected to the same network.

Wake on pattern and other filters

Beyond the magic packet, modern controllers can match arbitrary byte patterns. On Linux this appears as the f (filters) mode in ethtool and as pattern triggers in WoWLAN. On Windows, the Set-NetAdapterPowerManagement cmdlet exposes -WakeOnMagicPacket and -WakeOnPattern as separate switches, alongside offloads such as ARP and Neighbour Solicitation offload that let the NIC answer address lookups without waking the host. Pattern wake is what lets a sleeping machine wake for an incoming remote desktop connection or a file share request. It is also the most common cause of machines that wake for no visible reason, which is why many administrators enable magic packet only.

ASF, IPMI and Redfish: real management controllers

A magic packet can only turn a machine on. It cannot turn it off, reset it when hung or tell you whether it is on. For that, platforms grew management controllers.

The DMTF's Alert Standard Format (ASF), DSP0136, defines out-of-band management for client systems. Version 2.0, dated 23 April 2003, is marked Final. It defines the Remote Management and Control Protocol (RMCP) over UDP, with RMCP "ASF" message types for Reset (10h), Power-up (11h) and Power Cycle Reset (13h). It reserves two UDP ports: 026Fh, the compatibility port (623 decimal), and 0298h, the secure port used with the RMCP Security-Extensions Protocol. IANA registers them as asf-rmcp on 623 and asf-secure-rmcp on 664. (The ASF 2.0 PDF prints 0298h as "644 decimal", which is a typo: 0298h is 664, matching IANA.)

On servers the same role is played by a baseboard management controller (BMC). IPMI over LAN plays the same role for servers. The ipmitool manual distinguishes the older IPMI v1.5 lan interface from the IPMI v2.0 lanplus interface, warns that a password changed over the v1.5 interface crosses the network in clear text, and advises keeping IPMI on a dedicated, secure management network. Its chassis commands include chassis power status, on, off, cycle, reset, diag and soft. Redfish, the DMTF's newer REST API, models power control as a ComputerSystem.Reset action with ResetType values such as On, ForceOn, ForceOff, GracefulShutdown, GracefulRestart and ForceRestart. Both require credentials, both can report power state, and both work when the operating system is wedged. Both also put a powerful, network reachable computer inside your server, which is why our Redfish and OpenBMC posts spend most of their length on hardening.

Comparison: WoL, BMC power control, smart plugs and IP-KVM

The decision is mostly about what you need besides "on". If you only want a desktop or NAS to be available on demand, WoL plus a relay host is enough. If you need to recover a hung server, you need a BMC or an IP-KVM. If the hardware has no WoL and no BMC, a smart plug and the firmware's "power on after AC loss" setting is the blunt fallback, and pairs naturally with the UPS shutdown logic in our homelab UPS guide.

What are the risks?

WoL is a small feature with a small blast radius, but its risks are real and mostly come from what people build around it.

Unauthenticated wake. Anyone who can put a frame on the segment can wake any armed machine on it, and the magic packet reveals the target's MAC address to everyone who sees it. On a shared office floor, a dormitory or a flat guest VLAN, that is a lot of people. Waking a machine is rarely harmful in itself, but it brings up a full network stack and every listening service on a machine its owner thought was off.

The SecureOn password is weak by design. It is static, it is in clear text, and few NICs support it. Treat it as a guard against accidents.

Directed broadcast amplification. Turning on directed broadcast forwarding to make WoL cross subnets re-creates the amplifier that RFC 2644 removed. It applies to every protocol, not just your wake packets, and to every source that can route to the interface.

Internet exposure. A port forward that turns internet traffic into LAN broadcasts, or a WoL web dashboard published to the internet, adds an attack surface whose only benefit is saving you a VPN connection.

Overnight wake without overnight patching. The original purpose of WoL was to let IT wake machines for backups and updates. The inverse problem is common in homelabs: a machine that sleeps most of the time and is woken briefly for a single job never stays up long enough for its updates to install, or wakes, runs an old container image and goes back to sleep. A machine that is rarely on is a machine that is rarely patched. Schedule a regular wake for updates, and check that they actually applied.

Wakes you did not ask for. Wake on unicast, ARP, PHY or broad patterns turns every scan, lookup or link flap into a wake. Beyond the power bill, it makes "the machine was on at 3 a.m." hard to interpret during an investigation. Use magic packet only, and record why a machine woke (powercfg /lastwake on Windows, the kernel log on Linux).

Step by step: enable, send and verify Wake-on-LAN

The commands below configure a Linux host and a Windows host, send a magic packet from a small relay, and confirm delivery with a packet capture. Replace interface names and MAC addresses with your own. None of these steps erase data.

Step 1: turn it on in firmware

Enter firmware setup and look for an option such as Wake on LAN, Power on by PCI-E or Resume by LAN, and enable it. If the board has a deep sleep or energy saving mode that cuts standby power in S5, disable it. Save, shut down, and check that the link light on the NIC and on the switch port stays lit while the machine is off. No link light usually means no standby power and no WoL.

Step 2: inspect the NIC on Linux

# Find the interface and its MAC address
ip -br link

# Show supported and current wake modes
sudo ethtool enp3s0 | grep -i wake
#   Supports Wake-on: pumbg
#   Wake-on: d

Supports Wake-on lists the letters the driver can do. Wake-on: d means disabled. If g is missing from the supported list, the NIC or driver cannot wake on a magic packet and nothing else in this guide will help.

Step 3: enable magic packet wake for this boot

sudo ethtool -s enp3s0 wol g
sudo ethtool enp3s0 | grep 'Wake-on:'
#   Wake-on: g

This setting is lost on reboot on many drivers, so make it persistent.

Step 4: make it persistent with systemd.link

systemd-udevd applies .link files when a device appears. The systemd.link manual documents WakeOnLan= with the words phy, unicast, multicast, broadcast, arp, magic and secureon, or off.

# /etc/systemd/network/50-wol.link
[Match]
MACAddress=00:1a:2b:3c:4d:5e

[Link]
NamePolicy=keep kernel database onboard slot path
AlternativeNamesPolicy=database onboard slot path
MACAddressPolicy=persistent
WakeOnLan=magic

The systemd.link manual is explicit that the first matching file in lexical order is applied and all later files are ignored, even if they match. systemd ships a 99-default.link, so your file needs an earlier name (hence 50-), and because it replaces the default for this NIC it should repeat the default naming and MAC address policies. The three policy lines above are the ones the manual shows for the shipped 99-default.link; check your distribution's copy in /usr/lib/systemd/network/ and match it so the interface keeps its usual name. Rebuild the initramfs if your distribution copies link files into it, then check which file applies and reboot:

sudo SYSTEMD_LOG_LEVEL=debug udevadm test-builtin net_setup_link /sys/class/net/enp3s0 2>&1 | grep -i 'config file'
#   Config file /etc/systemd/network/50-wol.link applies to device enp3s0
sudo reboot
# after reboot
sudo ethtool enp3s0 | grep 'Wake-on:'

If you want SecureOn, systemd 250 and later accept WakeOnLanPassword=, which can point to a file instead of holding the value inline, and with WakeOnLan=secureon and no password set it reads the value from a systemd credential. Keep the file readable only by root, and remember that the value goes out in clear text in every wake packet.

Step 4b: or let NetworkManager manage it

On desktops where NetworkManager owns the interface, set WoL on the connection profile instead:

nmcli -f NAME,DEVICE connection show
sudo nmcli connection modify "Wired connection 1" 802-3-ethernet.wake-on-lan magic
sudo nmcli connection up "Wired connection 1"
sudo ethtool enp3s0 | grep 'Wake-on:'

NetworkManager's settings reference lists the same flags (phy, unicast, multicast, broadcast, arp, magic) plus default and ignore, where ignore tells NetworkManager to leave WoL alone so another tool can manage it. Do not let NetworkManager and a .link file fight over the same NIC; pick one.

Step 5: check Windows

Open an elevated PowerShell prompt:

# Which adapters support and have magic packet wake enabled
Get-NetAdapterPowerManagement | Format-Table Name, WakeOnMagicPacket, WakeOnPattern

# Allow only a magic packet to wake the machine
Set-NetAdapterPowerManagement -Name "Ethernet" -WakeOnMagicPacket Enabled -WakeOnPattern Disabled

# Which devices are armed to wake the system right now
powercfg /devicequery wake_armed

# After a wake, what woke it
powercfg /lastwake

Microsoft's powercfg reference defines wake_programmable as devices that are user configurable to wake the system and wake_armed as devices currently configured to wake it, and documents /deviceenableawake, /devicedisablewake and /lastwake. If the adapter is armed but the PC still does not wake from shutdown, remember Microsoft's note on Fast Startup: test from sleep first, then decide between disabling Fast Startup and using sleep or hibernate instead of shutdown.

Step 6: send a magic packet from the relay

Packaged tools work well. On Debian based systems:

sudo apt install wakeonlan etherwake

# UDP to the limited broadcast address, port 9 by default
wakeonlan 00:1a:2b:3c:4d:5e

# UDP to a specific subnet broadcast address and port
wakeonlan -i 192.168.10.255 -p 9 00:1a:2b:3c:4d:5e

# Raw Ethernet frame on a chosen interface (needs root)
sudo etherwake -i eth0 00:1a:2b:3c:4d:5e

If you prefer something you can read in a minute and audit, the payload is simple enough to build yourself:

#!/usr/bin/env python3
"""Send a Wake-on-LAN magic packet.
Usage: wol.py 00:1a:2b:3c:4d:5e [broadcast_address] [port]
"""
import socket
import sys

mac = bytes.fromhex(sys.argv[1].replace(":", "").replace("-", ""))
if len(mac) != 6:
    sys.exit("MAC address must be 6 bytes")
target = sys.argv[2] if len(sys.argv) > 2 else "255.255.255.255"
port = int(sys.argv[3]) if len(sys.argv) > 3 else 9

payload = b"\xff" * 6 + mac * 16          # 102 bytes
with socket.socket(socket.AF_INET, socket.SOCK_DGRAM) as s:
    s.setsockopt(socket.SOL_SOCKET, socket.SO_BROADCAST, 1)
    s.sendto(payload, (target, port))
print(f"sent {len(payload)} bytes to {target}:{port}")

Run it from a host on the target's subnet. Pass the subnet broadcast address if the relay has more than one interface, so the kernel picks the right one.

Step 7: wake from outside, through the relay

With the relay reachable over your VPN and SSH keys in place:

ssh relay.lan 'wakeonlan -i 192.168.10.255 00:1a:2b:3c:4d:5e'

To limit what that key can do, give it a forced command in the relay's authorized_keys so it can only run the wake script for a fixed list of MAC addresses, and nothing else.

Step 8: confirm delivery with a packet capture

On a third machine on the same VLAN, or on the relay itself, capture the wake traffic:

# UDP magic packets on ports 7 and 9, printing frame bytes
sudo tcpdump -ni eth0 -XX 'udp and (port 9 or port 7)'

In the hex dump you should see ffff ffff ffff followed by the target MAC repeated. If you see the packet but the target does not wake, the problem is on the target: firmware, standby power, driver arming or Fast Startup. If you do not see the packet, the problem is on the sender side: wrong interface, wrong broadcast address or a router in the way. Raw frames from etherwake are not UDP, so capture those with sudo tcpdump -ni eth0 -XX ether dst ff:ff:ff:ff:ff:ff.

Step 9: check the router is not forwarding directed broadcasts

On a Linux based router:

sysctl net.ipv4.conf.all.bc_forwarding
# net.ipv4.conf.all.bc_forwarding = 0

Zero is the documented default and the value you want. On other router platforms, look for an interface option named after directed broadcasts and confirm it is off on every interface, especially the WAN.

Where Safeguard fits, honestly

Wake-on-LAN lives in NIC silicon, motherboard firmware and operating system drivers. Safeguard does not manage devices, does not scan firmware, does not inspect network traffic and does not control power. The indirect fit is the software around the wake: the relay host's packages, the container image of a home automation or dashboard tool that sends wake packets, the scripts in a homelab repository, and the services that come up on a machine that has just woken after a week asleep. Those are ordinary open source dependencies and container images, and Safeguard can scan them (safeguard scan --dir . for a repository, safeguard scan --image followed by an image name for an image), show which projects carry a given component version, and, when you switch it on, open fix pull requests for vulnerable dependencies.

Common mistakes

• Testing from shutdown on Windows 10 or 11 with Fast Startup on. Microsoft documents that adapters are not armed in that state. Test from sleep first.
• Enabling WoL in the OS but not in firmware, or leaving a deep sleep mode on that cuts standby power. Check the link light with the machine off.
• Forgetting persistence on Linux. ethtool -s DEV wol g works until the next reboot. Use a .link file or NetworkManager, not both.
• A .link file that renames the interface. A matching file replaces the default one; copy the naming policy across.
• Turning on directed broadcast forwarding so a wake crosses a router. Put a relay in the target subnet instead.
• Port forwarding UDP 9 from the internet to a broadcast address or a static ARP entry. Use a VPN and a relay.
• Expecting SecureOn to be a security control. It is a static clear text value.
• Expecting Wi-Fi to behave like Ethernet. WoWLAN usually works only from sleep, only while associated.
• Enabling every wake mode. pumbg wakes on almost anything. Use g.
• Machines that wake only for minutes. They miss updates. Schedule a longer wake window for patching and confirm it worked.
• Putting a BMC or IP-KVM on the general LAN because it is "just for power". It is a full management plane; give it its own VLAN.

FAQ

What port does Wake-on-LAN use?

None, strictly. The magic packet is a byte pattern the NIC finds anywhere in a frame. By convention, UDP senders use port 9 (registered as Discard) or port 7 (Echo), and raw Ethernet senders use no port at all. The sleeping NIC does not check the port.

Does Wake-on-LAN work over the internet?

Not directly, and you should not make it. Routers do not forward the limited broadcast address, and since RFC 2644 they must not forward directed broadcasts by default. Connect to the LAN over a VPN or SSH and send the packet from a device that is already on.

Does Wake-on-LAN work over Wi-Fi?

Sometimes, from sleep, through Wake on Wireless LAN. The radio must stay associated and able to keep up with key changes. Waking a laptop from hibernate or shutdown over Wi-Fi is rare. Use Ethernet for anything you rely on.

Why does Wake-on-LAN work from sleep but not after shutdown in Windows?

Because the default Windows 10 shutdown is a hybrid shutdown (Fast Startup), and Microsoft states that network adapters are explicitly not armed for wake in that state. Some firmware arms the NIC on its own anyway, which is why results vary between machines.

Is Wake-on-LAN a security risk?

A small one by itself: anyone on the same network segment can wake an armed machine. The bigger risks are what people add to make it work remotely, such as directed broadcast forwarding or port forwards from the internet, and machines that are woken briefly and never stay up long enough to patch.

What is a SecureOn password?

An optional 4 or 6 byte value appended to the magic packet that some NICs check before waking. It is static and travels in clear text, so anyone who captures one wake packet learns it.

Can Wake-on-LAN turn a computer off?

No. A magic packet can only wake. To shut down remotely you need the operating system (SSH, a remote shutdown command) or a management controller such as IPMI or Redfish.

What is the difference between Wake-on-LAN and IPMI power on?

WoL is an unauthenticated pattern the NIC watches for. IPMI and Redfish talk to a separate management controller that requires credentials, can report power state, and can also power off and reset. Servers usually have a BMC; desktops usually only have WoL.

How do I find which device woke my PC?

On Windows, powercfg /lastwake reports what woke the system from its last sleep, and powercfg /devicequery wake_armed lists devices currently allowed to wake it. On Linux, check the kernel log and journalctl -b around the resume time, and whether the NIC is enabled as a wakeup source, for example with cat /sys/class/net/enp3s0/device/power/wakeup.

Do I need directed broadcast forwarding to wake machines on another VLAN?

No. Run a small relay (a router feature, a container or a tiny host) with an interface in that VLAN and send the packet locally. That keeps RFC 2644's safe default in place.

Fix it without waiting for upstream

Wake-on-LAN is a firmware and NIC feature, so the dependency work here is indirect, but the relay host, the dashboard container that sends wake packets and every service that starts on a freshly woken machine are built from open source components. A machine that sleeps most of the week runs stale images and packages when it wakes, which makes knowing and fixing what those components contain worth the effort.

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo is a real Safeguard CLI session asked to fix a lodash CVE in a repository. It reads the finding and the advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, prints a summary and pushes nothing. The same flow applies to a Node.js based wake dashboard or home automation add-on kept in a homelab repository.

Click through it at your own pace, or open it full screen.

The second demo sets up the Safeguard runner on your own machine, approves it with its device code and then scans from the terminal. In a homelab, that machine can be the always-on relay host, so scans of your compose files and images run on hardware you already keep awake.

Click through it at your own pace, or open it full screen.

The third demo is a real Android session that sends work to a computer running the CLI and approves the command on the phone with Allow once, Allow for turn or Deny. It does not wake anything: the computer must already be on, for example after you have woken it through your relay, and then every command still needs your approval.

Click through it at your own pace, or open it full screen.

To try it on your own repositories, download Safeguard and follow the CLI documentation.

Quick check

Sources

• AMD, Magic Packet Technology white paper, publication 20213 rev A (November 1995)
• RFC 2644 (BCP 34), Changing the Default for Directed Broadcasts in Routers (August 1999)
• BCP 34 information page
• RFC 1812, Requirements for IP Version 4 Routers (June 1995)
• RFC 2827 (BCP 38), Network Ingress Filtering (May 2000)
• RFC 919, Broadcasting Internet Datagrams
• RFC 922, Broadcasting Internet Datagrams in the Presence of Subnets
• NVD, CVE-1999-0513 (Smurf, ICMP to broadcast addresses)
• CISA, UDP-Based Amplification Attacks, alert TA14-017A (last revised 18 December 2019)
• IANA, Service Name and Transport Protocol Port Number Registry
• Microsoft Learn, Wake on LAN (WOL) behavior in Windows
• Microsoft Learn, Powercfg command-line options
• Microsoft Learn, Set-NetAdapterPowerManagement
• ethtool(8) manual page
• Linux kernel documentation, Netlink interface for ethtool
• Linux kernel documentation, IP sysctl (bc_forwarding)
• systemd.link manual (WakeOnLan=, WakeOnLanPassword=)
• NetworkManager, 802-3-ethernet settings
• NetworkManager, nm-settings-nmcli
• Linux wireless documentation, Wake on WLAN
• DMTF, Alert Standard Format Specification 2.0, DSP0136 (23 April 2003)
• DMTF, Redfish Specification DSP0266 version 1.21.0 (1 August 2024)
• Debian manpages, wakeonlan(1)
• Debian manpages, etherwake(8)
• Debian manpages, ipmitool(1)

Last reviewed: 24 October 2026.