Wake-On-LAN (WOL) is one of those technologies that can both enlighten and infuriate. It has so much to offer but there are often so many external dependencies to having it be successful that many sysadmins finally just give up.
Generally there are two circles of IT hell: Technical and Political. WOL is often able to maintain a perfect horse stance over both.
Assuming you have a utility that can send wake up packets to target computers there are usually three technical external dependencies for WOL.
Enabling WOL in the BIOS or UEFI
Enabling WOL in the NIC drivers
Allowing WOL broadcasts to traverse your routers
There is usually only one political hurdle and it has to do with item 3 above: Disabling WOL broadcasts at the router. Now, it is definitely considered best practice to disable forwarding broadcasts at the routers however there are ways to apply some intelligence to blocking broadcasts. One popular way is to allow what are generally known as “Directed Broadcasts”. These are broadcasts from a different subnet that are sent only to a particular computer in (obviously) a particular subnet.
Even more intelligence can be applied such as only allowing directed broadcasts from a particular IP address (such as your PDQ Inventory console). I’ve been in environments where the gods of networking allowed this because if there was ever a broadcast storm they’d immediately know the culprit computer.
How PDQ Inventory Sends WOL Packets
Taken directly from this KB article on our support site I am going to explain how PDQ Inventory sends WOL packets as well as explain how we can get around the most popular hurdle, which is routers stopping broadcasts. Steps 1 and 2 have been in place since version 1 (with an additional change in Inventory 5.2). Step 3 is introduced in PDQ Inventory.
PDQ Inventory sends a “general broadcast” UDP packet to ports 9 and 12287 and 40000 (Port 40000 was added in Inventory 5.2). The General Broadcast packet is USUALLY blocked by a company’s routers. Therefore this packet is generally useful to wake up machines on the same subnet. This involves sending the magic packet addressed to a specific MAC address.
We also send a directed UDP packet to the IP Address (and subsequently the subnet) of the target through Ports 9 and 12287 and 40000. This means PDQ Inventory grabs the last known IP Address, determines the subnet of the target and sends a broadcast to only that subnet which then broadcasts the MAC Address.
In PDQ Inventory 6 we are introducing an additional step to achieve higher success rates with WOL. Pro and Enterprise modes will also attempt to contact an online computer in the last known subnet of the target that you are waking up. A command will be sent to that last known computer to wake up the target. This should increase the success rates for those environments where WOL broadcasts (directed or otherwise) are blocked by your routers.
I will break down step 3 a little more. Let’s say you have to wake up a computer on a different subnet. This computer is called Homer. The original steps (steps 1 and 2 above) are still attempted. After sending out those packets PDQ Inventory will look for an online computer on the same subnet as Homer. PDQ Inventory will effectively send out a Remote Command to that online computer telling it to send out the magic packet to the MAC address of Homer. This last step should overcome those limitations in environments that disallow any WOL traffic from traversing routers since Step 3 will send out a WOL packet that will never need to cross a router.
Below is a simple diagram of Step 3 where the online computer Smithers is used to send the WOL to Homer.
You may ask “How does PDQ Inventory know which online computer to use?” Well, the answer is that, for Step 3, PDQ Inventory will find an online computer with the most recent successful inventory scan (and that is, obviously, on the same subnet as Homer) and use that computer to send out the WOL packets. At this point there isn’t a way for you to specify a particular computer to act as a WOL relay.
Here are some considerations:
WOL still must be enabled at the BIOS / UEFI and NIC properties level of each target
If the “online” computer has gone offline or no longer available to fulfill step 3 above then WOL will fail (assuming steps 1 and 2 failed)
There you go. Please try this out and let us know if you run into any problems.
