[SOLVED] Can't perform Wake-On-LAN via UDP and I can't find the issue

Troubleshooting
1

Sourcecode: https://gist.github.com/Cilph/1635fc29c2031c17bb8e

I’m trying to create a simple Wake On LAN snippet that can boot my PC from the local network. WOL packets should be as simple as sending 6x 0xFF followed by 16x MAC over UDP.

However, nothing happens. Other WOL tools / phone apps seem to work and I’ve caught their packets and compared them - no error there. I suspect the issue might be with the UDP client included.

Could someone help me out here?

2

We are experiencing issues with UDP and @zachary has been looking in this.

For now, i think folks like @bko can help you modify the code and possibly get it working :wink:

3

Now flushing the UDP RX buffer in the loop, but I don’t appear to be having connection issues. There’s no flash of death.

EDIT: Trying to send entire packet in a single write. That didn’t work either.

4

I am assuming your destination is wired and not wireless. AFIK WOL is not supported over wireless networks. Extra info in the wireless frames disrupts the magic packet from being detected.

udp.beginPacket(ip, port);

for (int i = 0; i < MAGIC_HEADER_LENGTH; i++) {
    Serial.write(0xFF);
    udp.write(0xFF);
}
for (int i = 0; i < REPEAT_MAC; i++) {
    Serial.write(contents, sizeof contents);
    udp.write(contents, sizeof contents);
}

udp.endPacket();

You problem is associated with UDP not working as expected. There a lot of threads about this issue so I'll keep this brief (not in documentation though). Every time you call udp.write(char) it sends a udp packet. udp.endPacket does nothing. So basically you sent 6 udp packets each only containing 0xFF and then you sent an additional for each REPEAT_MC packet with the contents written out.

To fix I would suggest, making contents large enough to hold your 0xFF's and put them in the array first. Then add you mac address repeats. Then call one and only one udp.write.

Hope this helps!!

Good Luck

EDIT: Added it is also sending multiple packets on the repeat_mac for loop. You get the idea... one buffer for whole packet, write it out in one shot!

1 Like
5

Well, I did try sending it as a single packet. That didn’t work.

int wake(const char* mac) {
    uint8_t contents[MAGIC_HEADER_LENGTH + REPEAT_MAC * MAC_BYTES];
    uint8_t rawMac[MAC_BYTES];

    parseMacAddress(mac, rawMac);

    udp.beginPacket(ip, port);

    for (int i = 0; i < MAGIC_HEADER_LENGTH; i++) {
        contents[i] = 0xFF;
    }
    for (int i = MAGIC_HEADER_LENGTH; i < sizeof contents; i++) {
        contents[i] = rawMac[(i - MAGIC_HEADER_LENGTH) % MAC_BYTES];
    }

    Serial.write("Packet:");
    Serial.write(contents, sizeof contents);
    udp.write(contents, sizeof contents);

    udp.endPacket();

    return TRUE;
}

Destination is my desktop PC, hooked up via cable. Waking via various phone apps works just fine, but I can’t run those outside the network, so I wanted to use the spark core to broadcast it via an internet trigger.

6

So I don’t know much about WOL (but I can say it does not work over WiFi).

You already got good advice about sending one buffer with one write command–that is required right now for UDP.

I saw that you are using the same port on the Spark for source and destination, so you will be receiving your own packets and the receive buffer will need to be flushed eventually. I have seen other WOL implementations that use ports 9 and 7 as source and destination. It shouldn’t matter of course, but you never know.

One other thing is that your broadcast address looks a little out of the ordinary. What is the subnet mask for that network? This is just a class-C network with a 255.255.255.0 subnet, right?

Do you have a wireshark capture of the working WOL packets that you could refer to? That would be a big help. It could be a core firmware issue but I think it is more likely a router issue.

7

Resolved the issue. Had to use Wireshark to find that out - I used a much more basic utility that just gave me a hexdump.

Here’s the WOL packet capture:

After switching the source port away from 7 used for ECHO, it was correctly interpreted and managed to boot my PC from shutdown.

4 Likes
8

WOL does not depend on the physical layer of the comms stack. It would be possible to have WiFi hardware which does a WOL. And certainly, as is now confirmed by the OP, there is no problem with where the WOL UDP datagram originates. If the network card supports WOL, it does not matter that the packet has been bridged or routed or changed media.