How Wake-On-LAN works (2020) | Hacker News Reader

How Wake-On-LAN works (2020)

blog.xaner.dev

92 pointsswq11533 comments

Wow, that brings back memories. In 1995, I sat right next to one of the guys who invented what we called “Magic Packet” inside AMD and what became known as Wake On LAN. I was working on what later became WiFi. Those were fun times; lots of innovation in the networking space. We worked with HP and Microsoft on this since it needed OS support from Windows, too. Yea, it’s not sophisticated at all since the hardware needed to decode it before generating an interrupt and passing anything to the driver. It just needed to be something statistically unlikely to occur in a real network to avoid false positives. And it needs to be unique per NIC, because you don’t want a single packet waking up every machine. So, it just repeats the MAC address a few times. The original use case was for doing things like network backups late at night. The file server needed a way to wake up a machine that had gone to sleep. Almost everything in the computer can be asleep excelpt for the NIC and whatever power-on circuitry is necessary to power everything back up and resume. In other words, it can be a deep sleep.

Not wanting to install an OS package to do something as simple as sending some bytes a couple years back, I wrote a shell script to send WoL packets. Its only dependencies are netcat and bash so if you have busybox it should run almost anywhere. It just takes the mac address and interface as an argument and sends a WoL packet on that interface

  #!/bin/bash
  hex="\xFF\xFF\xFF\xFF\xFF\xFF"
  mac_hex="\\x`printf "$1" | sed 's/:/\\\\x/g'`"
  wol_string="$hex"
  for i in {1..16}
  do
      wol_string+="$mac_hex"
  done
  printf "$wol_string" | nc -u -b -w 1 "$2" 9

It took me a while to find an explanation of something so simple, I can't figure out why everyone relies on huge binary packages and libraries to do it. I just needed something on my router so that I could wake my machines from outside the house. I ended up just writing a couple shell scripts that called it and triggering them with nginx via FastCGI so I could click on a link to wake up my machines.

Here's an equivalent shell script that only uses bash builtins, so no other software required:

  #!/bin/bash 
  mac="\\x${1//:/\\x}" 
  wol="\xFF\xFF\xFF\xFF\xFF\xFF" 
  for i in {1..16}; do wol+="$mac"; done 
  printf "$wol" > "/dev/udp/$2/9"

I was kinda hoping to get the nitty gritty of how the NIC does the packet matching, how, it wakes up the system via PCIe and how switches route the frames to the port which has/had the client.

Nothing against the article though, but maybe someone knows a good writeup.

The original paper proposing the technology is actually very good (and surprisingly still online!): https://www.amd.com/content/dam/amd/en/documents/archived-te...

That's more useful. A big question is how much is really turned off in a computer waiting for the wake-up packet. "The power to the Ethernet controller must be maintained at all times, allowing the Ethernet controller to scan all incoming packets for the Magic Packet frame". So the full network controller is still alive. There's not some tiny Magic Packet detector hardware running off a rechargable coin cell or something, with the main power supply turned off. At least not in the original design.

A lot of sleep modes leave more running than you'd expect.

The Ethernet cards that wait for WoL packets use the "+5 V Standby" supply voltage, which is available on the PCIe slots, coming from the ATX power supplies.

"+5 V Standby" is provided by a separate voltage regulator, which continues to work even when the PC, including the rest of the ATX PSU, is shut down.

"+5 V Standby" typically can provide up to 2 A, i.e. up to 10 watt, though some old PSUs may be able to deliver only up to 5 watt and some of the bigger ATX PSUs may be able to deliver up to 15 watt.

Besides supplying the Ethernet cards, to enable WoL, "+5 V Standby" can be used by the USB ports if configured so in BIOS, to enable waking the PC with the keyboard, or to enable charging from USB even when the PC is shut down.

Exactly this. Many modern PHYs also integrate 802.3az (energy-efficient ethernet, a subset of Green Ethernet) but it's not super common.

I also finally found this old page of using an old dev board to construct a WoL listener for a mobo that didn't support it -- might be an interesting read for the curious: https://web.archive.org/web/20140525022112/https://hackingbe...

> In this script a fifo is created where the output of tcpdump is dumped. For whatever reason tcpdum | grep was not working properly, and would have a “miss” rate of about 50%. So tcpdump output is dumped in the fifo:

> tcpdump -i eth1 2>&1 | tee > /tmp/tcp_wol.fifo &

> and it’s grepped in a loop, when the magic packet (see http://en.wikipedia.org/wiki/Wake-on-LAN) is found , a led is triggered, thus powering-up the computer (with a driver and relay, will come back at this).

I have measured the powered off energy usage of my desktop computer at the wall, and it hovered about 5-6 W (resolution of the power meter was just whole watts). That would be split between losses in the PSU and WoL, and possibly other circuits. But I don't have any other such wakeups enabled (but that doesn't mean that the motherboard is designed super well to disable it fully if not needed). Turning off WoL made a difference of about 2 W (meter hovered around 3-4 W).

One thing I noticed is that if I connect to a gigabit upstream port, that the connection drops to 100 mbit/s when the computer is off, but if I connect to a 2.5 Gbit port, it stays at full speed. This is based both on LEDs on the connector as well as the OpenWRT dashboard on the router. If it made a difference it was too small to reliably measure with my simple meter.

If it makes a difference (potentially does for conversion losses I would guess), this is on 230 V mains.

It probably is done in hardware; I expect you'll end up with the TX side of the Mac/phy powered down but all the receive running. Miliamps at most.

I was distracted by the poor typesetting in parts of the page. The meaning of the text is overwhelmed by the distracting spacing used to justify the text:

> . I n o t h e r w o r d s , s i l i c o n - o r g a t e - l evel

Didn‘t know a whitepaper is allowed to be this readable.

Ditto, I clicked and was disappointed.

"How to send a magic packet in $LANG" isn't very interesting to me. There are plenty of guides for it, and I remember actually doing it 20+ years ago with a short PHP script.

Even at the time, the task didn't seem like "enough" for a show-the-world blog post. A dramatically shortened version (no validation, error handling, logging, etc.) for your amusement:

    // Given $macAddress and $addr and $port
    $macAddress = str_replace(":","",$macAddress);
    $macAddress = str_replace("-","",$macAddress);

    $header = pack('H12','FFFFFFFFFFFF');
    $payload = pack("H12",$macAddress);
    $packet = $header . str_repeat($payload,16);

    $sock = socket_create(AF_INET, SOCK_DGRAM, SOL_UDP);
    socket_set_option($sock, 1, 6, TRUE);
    socket_sendto($sock, $payload, strlen($payload), 0, $addr, $port);
    socket_close($sock);

To perhaps give a little insight into why this is on the front page by someone who upvoted it: I didn't realize it was so open and easy. Now I do. The Golang code simply serves as proof in how open and easy it is.

> Even at the time, the task didn't seem like "enough" for a show-the-world blog post.

Its an old (de facto industry) standard, but maybe more relevant than ever. I'm interested in moving more of my compute usage off-cloud these days, which is why this is of interest to me right now. I suspect many others feel the same way.

Might be a good time to post other tidbits of knowledge you have like this, targeted at software engineers that are starting to get more into infrastructure management. Standards that are ubiquitous and just work are awesome.

Shift registers. It's all done with shift registers.

All you need are NAND gates.

> how the NIC does the packet matching

This part, I don't know, but default magic packet has 6 bytes of 0xff, followed by the mac address sixteen times in a row, so it's a fairly simple state machine as the packet comes in. The AMD whitepaper others linked might have details?

> how, it wakes up the system via PCIe

Pci-e pin 11-B is wake#. PCI 2.2 added PME# on 19A which does the same job for PCI. Pull it high (I think) to wakeup the host. I don't think there's a pin for this on ISA, so you'd need some system specific connector to wakeup from an ISA nic.

> how switches route the frames to the port which has/had the client.

Ethernet switching is a whole different thing. You can send a broadcast frame and those should get flooded to all ports. If you send a unicast frame, the switch looks up the destination mac in its address table, if present, it sends only to the port where that address was seen, otherwise it floods to all ports.

I believe WOL brings it down to 10Mbit - at which point it'll process any received packets use a low power processor. Packets wouldn't be routed to it unless specifically addressed

> The computer that you are trying to wake up also needs to be connect with an ethernet cable as it is not possible to send a magic packet over wifi.

While WiFi adapters may not support waking up the computer from a WiFi signal, you absolutely can send magic packets over WiFi as they're normally just UDP broadcast frames. Convenient for waking up a desktop from a laptop!

[stub for offtopicness]

[2020] and wow, what a title. It looks like someone was trying to decide between "How Wake-On-LAN works" and "How does Wake-On-LAN work" and "How do Wake-On-LANs work" and just picked a random combination of words from those choices.

English is not the author's primary language.

I think they did a great job for writing in a secondary language.

Yea, now I feel bad. It's just kind of funny that there are so many ways to get English either right or wrong, seemingly randomly.

They did a much better job than a JavaScript developer writing Java.

This sort of thing is quite common for non-native speakers. The fact that you can say "how does X work" and "how X works" but not "how does X works" is not particularly obvious, and easy to mix up.

He's Norwegian and studied in Wales.

How good are you at blogging in your third language?

Ich? Nicht so gut, aber Ich kann veillicht ein bisschen posten auf Deutsch.

Agus co dhiù, bha Beurla an dàrnan cànan agamsa.

So if my posts in English (proper English, not North American "Simplified English") are a bit squint at times, blame that.

Somehow, the bad grammar gives something special by signifying an LLM didn't write it.

Then again, an LLM could probably help clean up the grammar.

I'm sure we'll start to get 'authentic' bad grammar LLMs that actually mussy up your grammar for that natural feeling.

You can do that now. Just ask it to use bad grammar and introduce spelling mistakes and it does.

This is one of those slippery slope things where Grammarly did "just" Grammar and then slowly got into tone and perception and brand voice suggestions and now seems to more or less just want to shave everything down to be as bland as possible.

All you have to do is prompt your AI with a writing sample. I generally give it something I wrote from my blog. It still doesn't write like I do and it seems to take more than that to get rid of the emdashes, but it at least kicks it out of "default LLM" and is generally an improvement.

It's fine. We can't have it both ways. I prefer bad grammar to Claude blandness, so I think the author should just write how they write.

I tried using an LLM to help me write some stuff and it simply didn't sound like I'd written it - or, it did but in a kind of otherworldly way.

The only way I can describe it is like when I was playing with LPC10 codecs (the 2400bps codec used in Speak'n'Spells, and other such 80s talking things). It didn't sound like me, it sounded like a Speak'n'Spell with my accent, if that makes sense.

No? Okay, if not, if you want I could probably record another clip to show you.

Reply on news.ycombinator.com