Sigh. Don’t I feel silly.
tcpdump was indeed capturing the unaligned
WoL packet, but my search for it wasn’t finding it because, as you might
expect, there was space between the bytes I was searching for in the display
(because it was unaligned).
The problem still remains that unaligned
(i.e. starting at odd address) WoL signatures are not waking up Mac computers,
but at least now I can confirm the packet is seen by the machine.
David Litwin
BigFix, Inc.
From: macnetworkprog-bounces+david_litwin=email@hidden
[mailto:macnetworkprog-bounces+david_litwin=email@hidden] On Behalf Of David Litwin
Sent: Thursday, July 31, 2008
12:15 PM
To: email@hidden
Subject: Dropped WoL packet
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.