# Wake-on-LAN: How 102 Bytes Turn On a Sleeping PC

> A powered-off machine has no OS, no IP stack, no running software — yet a single crafted broadcast frame boots it. How the NIC stays half-awake watching for its own MAC, why WoL is a layer-2 trick, and the homelab plumbing to make it reliable.

URL: https://harshith.in/blog/wake-on-lan-magic-packets/
Author: Harshith Sunku (Staff Engineer) — https://harshith.in/about/
Tags: networking, embedded, systems

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](https://harshith.in/projects/esp32-mqtt-wol/) 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:

```mermaid
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.