What is the actual underlying mechanism used to deliver a wake on LAN (WoL) magic packet to the intended host computer?
I am very familiar with using WoL through LMI, so I am reasonably confident that this is not just an issue of correctly setting the myriad of different options in BIOS, Windows, device manager, etc. I have an entire office of people who have been almost exclusively working from home for the past 3.5 months, and I have had 10+ different models of host computers all successfully waking during that time *knock on wood*. But I needed to replace our primary hardware firewall/router 2 days ago, and have been experiencing seemingly random issues of the "switch on" button in LMI being grayed out for only a small % of host PC's. That is despite still being able to WoL all of the host PC's through another mechanism (separate from LMI).
Immediately after replacing the firewall, the option to remotely switch on was grayed out in LMI for all of the host PC's. That is probably to be expected, because the connection to LMI's servers was disrupted. After booting the host PC's through another method, most host PC's were then able to be remotely switched on through LMI. But the option is still grayed out for several host PC's, despite all of the host PC's being on the same VLAN/subnet and all accessible to each other. And despite all host PC's still being able to be remotely switched on using a separate WoL method.
I understand that LMI maintains a connection through the firewall as long as there is at least 1 host PC on the VLAN/subnet that is powered on. Is it the case that that particular host PC needs to have ARP cache entries for each and every other host PC in order for LMI to consider all of the other host PC's as able to be remotely switched on? Or something like that?
Update: It also seems to be the case that this situation varies depending upon which particular host PC's are currently powered on versus which are not. For example, the option to "switch on" through LMI is grayed out for both Computer A and Computer B. If I switch on Computer A using a separate WoL method, now Computer B is able to be switched on through LMI. If I then shut down Computer A again, now the option to switch on Computer B is grayed out again. This is again despite all of our host PC's being on the same VLAN/subnet and all accessible to each other.
@etb Since we store the MAC address on DB side, we likely don’t need the ARP cache. As long as another LMI host is present on the same LAN, that should be able to broadcast the magic packet with the WOLable host MAC.
Hi @AshC ,
Thanks for your response. What you said here was generally my understanding, but there were/are many of our LMI hosts present on the same LAN, yet only about half of them were able to WoL through LMI after the new hardware firewall was installed.
After my original post here, all but 1 of our other hosts have actually returned to being WoL-able through LMI. There was nothing I could figure to do to resolve the issue, so I really didn't do anything. I had tried restarting the hosts multiple times, shutting them down all the way and starting them up again, etc, but it did not seem to help. They seem to have just eventually resumed working on their own. As I mentioned, about half resumed working pretty much right away. Then all but 3 were working within about 1 day later. But as of today, I believe there is still 1 host that is not WoL-able through LMI.
So I am mostly okay right now, but I would like to know how to prevent or fix this in the future in case I need to take the network down again in the future. Is there some way that I can trigger LMI's DB to refresh and recognize that all of our LMI host computers are on the same LAN? Or something like that?
I'm not sure if illustrations might help. See a couple snips from my Central dashboard right now.
The following 2 images show the case of the 1 LMI host that I described is still not WoL-able. This is the only one that is still affected, though there was a point were about 50% of our hosts were like this.