WOL not working consistantly

I was working late last night and noticed out of 25 clients I was attempting to wake, I was only able to wake 16 of the 25. The method I was using was, in the console I selected all 25, right clicked and selected “Send Wake On LAN Request”. Scheduling a WOL was not needed for this scenario. All 25 clients are on the same subnet, have “Wake from Standby…” enabled., have the 9.5.8 client and are laptops. These clients were reporting to either one of two relays that were on and configured as LMS. All clients in our environment are WOLFs.

This morning I performed some troubleshooting with a client laptop at my desk. This laptop reports in to a differently relay from the 25 the night before. I noticed sending a WOL request does not work every time. When attempting to wake this laptop, it will either wake it immediately, or not wake it at all. If I wait a few minutes, and attempt it again, it will sometimes work, or not at all. I noticed that the longer I wait before sending another WOL after an unsuccessful attempt, the chances are greater of it succeeding but still not 100%.

Does anyone have any ideas of why this could be? I’ve gone through the BigFix Wake-On-LAN troubleshooting guide and have found nothing wrong. One thought I had was that potentially, since these are laptops, BigFix is sending magic packets to the wireless adapter and those are failing and when it sends it to the wired adapter, it succeeds? I’m not sure how to troubleshoot this further.

Thank you,

Don

The wake packet should be a broadcast packet sent to the subnet address of the last IP the client used to register to the relay, and the data will contain several repeats of the MAC address the client registered. If you have the ability to packet sniff on the relay or another host on the subnet you should be able to see the packet. It’s a UDP, I believe on port 52311.

If the laptop registered with its wireless adapter I wouldn’t expect it to work.

If you are testing by sending repeated WoL, I believe there is a timer to prevent too much packet flooding - I don’t recall the value, but it may be one minute or ten minutes or something along those lines.