There’s something that feels like a violation the first time you see it work: the machine is off — no operating system, no running process, no IP address — and yet a packet from across the house boots it. It isn’t magic (well, the packet is literally called a “magic packet”), it’s a small, elegant piece of hardware cooperation, and building a WoL gateway meant understanding every layer of why those 102 bytes work and where they get stuck.

The NIC Never Fully Sleeps

The trick lives below the OS entirely. When you “power off” a machine with WoL enabled, the network card stays in a low-power state on standby voltage — the reason your motherboard’s Ethernet LED often stays lit on a shut-down PC — running one tiny job: watch every frame that arrives and check whether it’s a magic packet addressed to this NIC’s MAC. When it matches, the NIC asserts the wake signal (PME# / the WOL header) and the PSU brings the system up. No CPU, no firmware execution, no IP stack — just a hardware pattern matcher on standby power. That’s the whole mechanism, and its simplicity is why it’s been in NICs since the late 90s.

The magic packet format is deliberately unmistakable so the matcher can be trivial:

text
  6 bytes of 0xFF   (FF FF FF FF FF FF)
  then the target MAC repeated 16 times:
  AA BB CC DD EE FF  AA BB CC DD EE FF  ... (16×)
  = 6 + 96 = 102 bytes, usually wrapped in a UDP broadcast to port 9

The 16 repetitions make the pattern astronomically unlikely to occur by accident, so the NIC can match with near-zero false wakes. Note what’s not here: any IP addressing that matters to delivery. The payload carries a MAC; the packet is typically sent as a UDP broadcast purely as a convenient envelope. Which sets up the one thing everyone trips over.

It’s Layer 2, and That’s the Whole Constraint

The sleeping machine has no IP address — the OS that would own one isn’t running. So the magic packet can’t be routed to it the normal way; it must reach the NIC as a broadcast on the local Ethernet segment, and the NIC recognizes itself by MAC. Every WoL limitation follows from this one fact:

flowchart LR
    P[wol sender] -- broadcast 255.255.255.255 --> L[local segment]
    L --> N[sleeping NIC matches its MAC]
    R[different subnet] -. routers drop broadcasts .-> L
  • Same subnet: trivial. wakeonlan AA:BB:CC:DD:EE:FF or etherwake sends the broadcast; the NIC on that wire sees it.
  • Across subnets: broadcasts don’t route. Routers drop 255.255.255.255 by design (or the internet would drown in broadcasts). You need a directed broadcast to the target subnet’s broadcast address and a router configured to forward it (usually disabled for good security reasons — directed broadcast is a classic amplification vector), or a static ARP entry pinning the MAC to an IP so a unicast reaches the wire.
  • From the internet: you need a relay. Port-forwarding a UDP wake packet to a subnet broadcast is fragile and insecure. The robust pattern — and exactly why my gateway exists — is an always-on low-power device inside the LAN (an ESP32, a Raspberry Pi, a router running a script) that stays awake, receives a command over something routable and authenticated (MQTT, HTTPS), and emits the local broadcast on the LAN’s behalf. The always-on tiny device is the standard answer to “wake my desktop from my phone.”

The reliability gotchas that generate homelab forum threads: WoL must be enabled in both BIOS/UEFI (often “Power On By PCI-E”) and the OS driver (Windows likes to disable it on the NIC’s power-management tab, and “fast startup” hibernation breaks it); some NICs only wake from certain sleep states (S3 vs S5/G2), so “works from sleep, not from full shutdown” is a state-support question; and Wi-Fi WoL (WoWLAN) is a separate, flakier feature — classic WoL is an Ethernet thing.

It’s a satisfying little system precisely because it’s honest about the stack: a hardware matcher on standby power, a layer-2 broadcast that can’t route, and a tiny always-on proxy to bridge the layers when you want to reach it from anywhere. Understand those three pieces and WoL goes from “sometimes works” to “reliable part of the homelab.”

Takeaways

  • The NIC runs on standby power as a hardware pattern matcher for a magic packet addressed to its own MAC — no OS, CPU, or IP involved.
  • The magic packet is 6×0xFF + the MAC repeated 16 times (102 bytes), usually in a UDP broadcast to port 7/9; the IP envelope is incidental.
  • WoL is layer 2: the target has no IP, so packets must arrive as a local-segment broadcast — which is exactly why they don’t route across subnets or the internet.
  • Cross-network waking needs directed broadcast + router config, a pinned ARP entry, or (best) an always-on in-LAN relay taking authenticated commands.
  • Enable it in both firmware and OS driver, mind sleep-state support and fast-startup, and don’t confuse it with Wi-Fi WoWLAN.