Refactor iOS Wake-on-LAN to be more correct and less of a shotgun #668
Conversation
This patch simplifies the WOL logic, and now loops through all active IPv4 interfaces and sends 1 magic packet to the broadcast address for each interface's subnet. Effectively this amounts to just one packet to the wifi interface's broadcast. All the rest of the packets, to high UDP ports, unicast IPv4 and IPv6 addresses, 255.255.255.255, were not correct, even if they might sometimes wake a recently-awake PC that could still receive unicast packets by dumb luck.
This will break the ability to wake a PC over the Internet for networks configured to support that. Unicast IPv4 and IPv6 absolutely are correct for some network topologies where the router is configured to forward WoL packets to hosts behind it. Some routers natively support this, while others can be made to support it by adding a static ARP entry for the LAN host to allow it receive the WoL packet when it's powered off. Also systems that support Modern Standby may actually respond to ARP queries while asleep, which wouldn't require any special router configuration to support. I agree that it's not necessary to send to all UDP ports, but there is good reason to try sending to multiple ports. Some networks or ISPs may block incoming UDP 7/9 traffic to avoid random spam from the Internet or have those ports forwarded to a different host on the network. With the regular streaming ports, we can almost guarantee those are at least forwarded to the machine we are trying to wake up. The thinking behind the current "shotgun approach" is that WoL is an infrequent operation and the cost of sending a few extra tiny WoL packets is worth the benefit of potentially being able to wake a computer that wouldn't otherwise have worked. |
|
I think I'm going to implement WoL functionality in moonlight-common-c then I'd be happy to have you contribute your subnet-local broadcast code there to avoid needing to use 255.255.255.255 and pray it goes out the NIC we want. |
|
I always miss these notifications from Github. Thanks for looking at this. I'm surprised to hear you say it's possible to wake a PC using WOL over the internet. That shouldn't be possible right? I feel like anything that works that way is only accidentally working, and it's hard to try to support it when there is no standard. My intention here was to strictly support the WOL spec [1], which doesn't support unicast packets at all. The reason is that the machine has no IP address if it is sleeping. A switch wouldn't know where to send the packet. If there is a newer spec that would be great, but it feels like an artifact of late 90s history that no one has bothered to update. https://www.amd.com/content/dam/amd/en/documents/archived-tech-docs/white-papers/20213.pdf |
|
Would it not be possible to integrate @andygrundman 's code now with the other ports and unicast addresses, as a temporary measure, until WoL in moonlight-common-c can be fully implemented? |
3 participants
This patch simplifies the WOL logic, and now loops through all active IPv4 interfaces and sends 1 magic packet to the broadcast address for each interface's subnet. Effectively this amounts to just one packet to the wifi interface's broadcast.
All the rest of the packets, to high UDP ports, unicast IPv4 and IPv6 addresses, 255.255.255.255, were not correct, even if they might sometimes wake a recently-awake PC that could still receive unicast packets by dumb luck.