Can't make UDP WOL packet work on windows

[AtmanActive]

sol.exe 1.0.1 on windows 7 x64 SP1

So, my Mikrotik is sending these:

ON:  tool wol interface=LAN mac=FC:AA:14:2B:58:EA
OFF: tool wol interface=LAN mac=EA:58:2B:14:AA:FC

sol.json: default as stated here: https://github.com/SR-G/sleep-on-lan

My machine wakes up alright, but sol.exe won't put it to sleep.
If I try the same thing via REST interface, then, yes it does work.

For now, I am using the workaround where my MikroTik can send REST commands as well, so I just added:
OFF: tool fetch url="http://192.168.173.18:8009/sleep" mode=http

and now it does sleep as intended.
But this is a workaround, not an intended behavior.

Thanks.

[AtmanActive]

Further debugging info:

By looking at sol.exe's output and sending magic packets from MikroTik and UDP packets from another machine, I have discovered that magic packets from MikroTik are not received at all.
On the other hand, if I try to send an ordinary UDP packet from my other windows machine to this machine's IP, then I can see that the packet is received.
But this sounds wrong.
My LAN's broadcast IP address should be 192.168.173.255, right (192.168.173.0/24)?
Then, why is sol.exe listening on my machine's IP 192.168.173.18?
This looks to me like sol.exe is listening on unicast IP address, not broadcast IP address.

Furthermore, judging by the XML output from REST interface, sol.exe's network calculation is wrong. It shows:
<host ip="192.168.173.18/16" mac="fc:aa:14:2b:58:ea:00:00"/>
But, my network is not /16 but /24.

Hope this helps.

[SR-G]

Have to investigate this further, but the "hosts" list in the REST dump (or in logs on start) is just what the go program is reading from the default network interfaces on the host (in order to easily retrieve the MAC address), nothing is computed / changed, and the program is just supposed to listen to everything broadcasted through UDP on :7 (or any other configured port).

[rkantos]

I think I know the solution to this issue, or at least why it doesn't work. I was just troubleshooting why I wasn't able to use etherwake to sleep a Windows using SleepOnLan.. After a while of troubleshooting I sent the same backwards-mac from an Android app, from which it worked. I then opened Wireshark and sent the same wol packets from both etherwake and the android app. What I noticed was that etherwake doesn't seem to send the wol to the actual broadcast address of 192.168.1.255.. Even if explicitly told to send to 192.168.1.255, the wol packet is only sent to the MAC? broadcast adress, but not the IP of .255? At least this is how it is displayed in Wireshark. In summary:

Using etherwake xx:xx:xx:cc:cc:cc:

• Wireshark lists destination as only being cc:cc:cc:xx:xx:xx
• Regular WOL works without issues
• SleepOnLan doesn't work

Using etherwake with -b 192.168.1.255

• Wireshark lists destination as "Broadcast"
• Regular WOL works without issues
• SleepOnLan doesn't work

Using Android-app:

• Wireshark lists destination as 192.168.1.255
• Regular WOL works without issues
• SleepOnLan also works

Using http://hostname:8009/wol/cc:cc:cc:xx:xx:xx

• Not displayed in Wireshark on another machine, and not on destination machine (Interface is shutdown before WOL packet is received by Wireshark).. Don't know if this should be the expected behaviour? The other machine with Wireshark was monitoring a wlan interface, which does receive regular WOL packets as normal.
• Regular WOL works as expected
• SleepOnLan also works

This leads me to think that sleep-on-lan isn't actually monitoring in, or at least not properly reacting to all of these cases, especially where the WOL packet seemingly isn't sent to broadcast at all, but only to the destination backwards MAC cc:cc:cc:xx:xx:xx.