Wake on Lan - Sent via
Our PDQ server is in a data center so obviously this is going to be an issue with WOL and probably more trouble than it's worth but I have set up and tested a computer with WOL. It works fine on the local subnet but does not work via PDQ.
The issue I have is that the packet is being sent via a computer that is not on the subnet of the WOL test computer. It's not even close.
Subnet of the test computer 192.168.110.0/24 Sent Via computer on 10.10.10.0/24
What?? Why?? How does it decide what the last subnet was?
Comments
I think you've run into a potential bug we found in a support ticket. When Inventory performs a WoL, it looks up the target's IP address and subnet mask from the NetworkAdapterIPAddresses table in the database. The problem is that this table keeps track of every IP address Inventory has ever seen for that target, and never cleans up that table. This can cause WoL to grab an incorrect IP address and subnet mask, which leads to an incorrect relay computer (Sent Via). At least, that's my theory 😃
Here's a SQL Report that shows what your NetworkAdapterIPAddresses table contains: https://gist.github.com/Colby-PDQ/a3ff5689108fd8553397c96ff18a1e61
I think you're right. Most of our computers are configured in our workshop so they're all going to have an IP from that subnet in the table...
Is there a way to clear the old IPs?
This is potentially dangerous, so please back up your database first.
DELETE FROM NetworkAdapterIPAddresses;
That worked! Cool thanks!
So here's the run down. This computer is on 192.168.110 It used to be on 10.10.10
1st Try: WOL sent via computer on 10.10.10
2nd Try: WOL sent via computer on 10.1.35 that used to be on 192.168.110
3nd Try: Finally found the right subnet
When I was testing this, the wake command would pretty much only attempt to send from one computer. After the first attempt fails should it try a different computer and never go back to the same one? Does it pick the subnet at random? Why would it pick 10.10.10 when the last known subnet is obviously 192.168.110. And why would it pick a computer that used to be on 192.168.110 when it's obvious that it's now on 10.1.35.
Maybe it should attempt to use the IP that's in the IP Address field first and if that doesn't work then use NetworkAdapterIPAddresses?
Yeah, the way WoL works right now is definitely a little funky. Hopefully it will get addressed within the next few releases.
Has this issue been resolved yet? I believe I'm having the same issue still with version 19.