I have a Linux server on my local network that is set up to use wakeup on lan. I copied this script verbatim, just replacing the MAC address in the example use. When I run this script on a Mac, the server wakes up. When I run it from Windows 7 (32-bit Ultimate) it doesn't do anything (note that the script DOES run, I added a debug raw_input() to confirm).
I rarely have found WOL to be reliable even for machines that were USA EPA Energy Start Certified to be.
In some cases, depending on whether the device driver is processing the WOL or the BIOS or something in between, the MAC address is case-sensitive. Try sending two frames, one all uppercase and one all lowercase. Call
Does the MAC happen to be a PowerPC MAC or is it Intel? Could be a Big-Endian vs Little-Endian bug where the convert to network byte format is not done. Consequently, the MAC address is not recognized by the receiver. So instead of receiving 0A:1B:F5:..., it receives A0:B1:5F:...
Again, put in the third and fourth MAC address into the script:
What made me think of it - I have a HPdc7800 with Intel vPro. Much of the identifying information appears backwards in each byte depending on what I am using to view the MAC or GUID. At the vPro console, from the vPro webpage, using the BIOS, using an OS - makes it very difficult to preallocate a machine active directory by GUID.
It should only take a few moments to edit this script and add the following:
In the script, the example is carefree whether the entire byte is explicitly defined or not, ignoring any leading zero bytes. I would explicitly type in leading zeros. Who knows who wrote the code that a NIC uses to identify itself and at what level of a management firmware, a plain bios, or device driver is processing it.
This could be the firewall.