Why does a Wake-On-LAN packet contain 16 duplications of the target MAC address?

Question

The Target MAC block contains 16 duplications of the IEEE address of the target, with no breaks or interruptions.

Is there any specific reason for the 16 duplications?

score 29 · Accepted Answer · edited Oct 02 '14 at 16:28

In my opinion, the value has to be exactly 16.

Magic Packet Technology (whitepaper, publication #20213) was developed between AMD and Hewlett Packard circa 1995. From page 2:

"Since an Ethernet controller already has built-in address matching circuitry..." they propose reusing it, adding a counter "to count up the 16 duplications of the IEEE address".

They reason that WOL should be trivial to add, while leaving the actual implementation wide open. This doesn't appear to be historically arbitrary ("Oh, 16 looks long enough"), because:

Build on what you have / what you know. By example, let's assume we like powers of 2 and therefore hex digits. Conveniently, a hex digit (4 bits) holds positive values from 0-15. Our processor checks all math and sets an overflow "flag" if we try to add 1 to an already "max" value (like 15). Because that's pretty common, we may even have a special instruction for overflow conditions, so in pseudocode:
```
Initialize a single counter that holds values from 0-15.
Set it to 0.
Watch the network. When I see the signal:
Loop:
  Do I see my address at the right spot?
  Yes: Add 1 to counter.
    Did I just overflow? (15+1 = 0?)
    Yes: Jump out of loop to "wake up" code.
...otherwise
Loop again.
```
Chip signal lines. AMD's reference to "circuitry" leads to the deep end, so all you really need to know is that we can imagine a simple case where a "bit set to 1" corresponds to a "high" voltage somewhere in a chip, visible at a "pin".

Arduinos are a good example: set a memory bit to 1, and Arduino sets an output pin "high". This voltage change is often demoed by driving LEDs, but through the magic of transistors it can automatically activate, interrupt or "wake up" other circuits or chips.

Let's assume a more natural hex representation (two hex digits, like FF, often seen in IP, masks and MAC addresses) and tie "output pin 5" of our Arduino to "bit position 5" in our counter:

Memory      Value  Event
0000 0000   00     Nothing, so keep adding 1...
0000 1111   0F     Nothing, but add 1...
0001 0000   10     Arduino pin 5 high. New voltage interrupts other circuits.

Because the memory location is tied to that pin, it's elegant and all hardware: just keep adding 1, no need to interfere with driver or BIOS developer code. You're just a circuit maker anyway. You'll provide a pin that goes high, to be consumed by other chipmaker's silicon, which is what everyone's doing. In the real world it's a little more complicated (for example, the ENC28J60 spec lays it out in horrifying detail), but that's the gist.

After this, human obviousness seems more a side effect than the goal. For computers, 4 copies of your MAC should suffice, but now that counter won't overflow and it's no longer dead simple. So it seems more likely that the goal was to get it implemented by as many silicon, driver, and BIOS designers as possible, and 16 gives everyone a choice between "overflow" AND direct signaling, without re-architecting and retooling.

Playing devil's advocate for human detection, what about the next higher number with the same flexibility: 256? That doesn't work: The data segment alone produces a WOL packet that's larger than an Ethernet frame (at the time) could be.

So to me this means that 16 is the only value the WOL segment can be.

Shouldn't you also have a line in your pseudocode to reset the counter, if you don't see the address? Otherwise with enough time and noise, you'll always wake up eventually. — Luke, Oct 03 '14 at 04:09
@Luke Yes. I originally accommodated that, but during simplification removed it for the sake of the main thread. I just revisited (apologies for the very delayed response) and can fix, but I don't mind approving edits if that's useful in-network for you. — ǝɲǝɲbρɯͽ, Mar 16 '15 at 23:41

score 19 · Answer 2 · answered Oct 01 '14 at 22:12

Yes. It's simple and the chance that someone sends this data accidentally is effectively zero.

You want simple because a very low-powered microcontroller in the NIC has to be able to permanently watch the raw ethernet network traffic and act if it sees this pattern and you don't want to turn on systems by accident because a stream of random network data is the command to turn the system on.

score 9 · Answer 3 · answered Oct 01 '14 at 22:14

9

I think that it is mainly a way to make sure that only a magic packet will actually wake up the computer. As the packets are scanned for this sequence without looking at any protocol headers (e.g., IP addresses, port numbers), the packet needs to be easily identifiable and the number of false positives close to zero. The probability that a random network protocol is sending a packet containing 16 times the MAC address of a computer is close to zero, but the chance of a false positive is much higher if there was only a single repetition.

answered Oct 01 '14 at 22:14

Ale

1,613
17
25

1

With just one repetition, the probability of a false positive would be 1, as MAC addresses are sent over the wire all the time, with every packet. – Sven Oct 01 '14 at 22:18
@SvW indeed, but in this case they're not necessarily prefixed by six FF bytes -- although I didn't mention this point. – Ale Oct 01 '14 at 22:19

score 5 · Answer 4 · answered Oct 01 '14 at 22:19

5

16 because it's dead easy logic to count to 16. Repeating the MAC address because there is already address matching logic on the chip. AMD white paper

answered Oct 01 '14 at 22:19

richardb

1,206
9
14

Why does a Wake-On-LAN packet contain 16 duplications of the target MAC address?

4 Answers4