I am seeing an odd problem with Wake on LAN packets on the
Mac.
We have some code to broadcast a WoL packet to wake up machines. We use a
UDP packet and put a 10 byte identification header, followed by the FF FF FF FF
FF FF, followed by the sixteen copies of the MAC address, followed by a
footer. The header and footer are there so other machines could track
these packets.
This wakes up machines just fine. Running tcpdump on the machine (awake,
of course) sees this packet, as do other machines on the same subnet.
Recently, we changed the header size of the packet to five bytes to slim down
the packet a bit. According to the WoL spec this shouldn’t make any
difference, as it just needs to see the FF FF FF FF FF FF and sixteen copies of
the MAC address anywhere in the packet. This works fine on Windows
machines, but not on the Mac. The machine doesn’t wake up, and when
we run tcpdump on that machine it never even registers the packet. Running
WireShark on a PC on the same subnet does see the packet when tcpdump on a Mac doesn’t.
We have gone as far as plugging in the network cable of the Mac to a PC to
confirm the packet does reach the end of the cable, and it does.
On a hunch, I even byte aligned the magic sequence by bumping the header size
to six bytes. Sure enough, all works well again.
Why would it be that the alignment of the magic packet data matters?
Further, even if it fails to wake the Mac, why wouldn’t we see this
packet with tcpdump when the machine is awake?
Is it possible magic packet processing is inappropriately
failing on non-even aligned magic packet data, and then even more inappropriately
dropping the packet at this point instead of pushing it back through the normal
stack?
It is reported that our code fails on all Macs, but I have specifically
confirmed on a Mac mini (intel) with 10.4 and a Mac mini (intel) with 10.5.
Thanks,
David Litwin
Big Fix, Inc.