Can't WOL PCs
-
Hello all,
Not sure why. Replaced a very old FOG server with a newer one (new on is 1.5.7) and the old one would wake up the domain fine, but the new one just won’t do it.
Any good places to start looking?
Thanks everybody.
-
Looked at IP helper options in my core switch (dear old HP ZL it is) and IP helpers are set to the two DHCP servers, as I’d expect.
Very much out of ideas here. Anyone got anything I might try?
-
How old was your old fog server (what version)?
Have you tried another 3rd party WOL tool like WakeMeOnLAN https://www.nirsoft.net/utils/wake_on_lan.html This would tell us if the issue was the fog server or outside of FOG in your infrastructure. Right now its not clear where the root of the problem is.
Are your target computers on the same subnet as the FOG server and they are still not waking correctly?
Understand that windows 10 takes over the wol function. To test removed the power cable from the target computer for 10 seconds and then plug it back in. See if the computers WOL correctly from state G3 hardware powered off. ref: https://docs.microsoft.com/en-us/windows/win32/power/system-power-states
-
Thanks george1421!!
Old one was 1.2.0, new one is 1.5.7
Have tried those yes, no joy.
Most if not all aren’t on the same subnet/vlan no.
Didn’t know that in fact! Tried pulling the power out for a test but still no, nothing will WOL.
-
@JRA said in Can't WOL PCs:
It would help if you quoted the questions but we can work with that.Understand I’m looking at this from a truth table perspective and not judging your responses.
Old one was 1.2.0, new one is 1.5.7
OK that is fine. AFIK the code for WOL has not changed since the 1.2.0 days. If you were running something from the early days (0.29 etc) it probably has.
Have tried those yes, no joy.
Ok if you have tried a different product and still no WOL, then we might rule out FOG as being faulty. I’m not saying it isn’t at fault but you have software from different vendors acting the same way.
Most if not all aren’t on the same subnet/vlan no.
OK WOL uses a directed broadcast. So your network infrastructure can control the WOL ability to work properly. I would suggest that you put a test computer on the same subnet as the FOG server and test to see if WOL works here from a cold boot of the target computer.
Didn’t know that in fact! Tried pulling the power out for a test but still no, nothing will WOL.
OK so windows probably isn’t stepping on WOL in your case.
The key to solving this is to find out where the problem isn’t so you can narrow in on where the problem might be. Its possible in your core router’s ip helper service you have an access list hard coded to the old FOG server’s IP address in an access list, firewall rule, or something. That is why the directed broadcasts of WOL are failing.
Also understand there are at least 2 standards on how WOL works. The utility I mentioned before supports both methods.
From the FOG server you can capture the WOL packets if you install the tcpdump program and run this command. Understand you will need to change the network interface name to match what your fog server’s interface name is (can be found with
ip a scommand and then pick the right interface). Replace eth0 in this command with your interface name.sudo tcpdump -i eth0 '(udp and port 7) or (udp and port 9)' -x | tee wol.logRun the above command and then generate a WOL packet either from FOG or the WakeOnLAN program. To see if its actually generating the WOL magic packet. The output will be saved in the wol.log.
Here is a wiki page on WOL forwarding that may help: https://wiki.fogproject.org/wiki/index.php/WOL_Forwarding
-
Thanks much for sticking with me George.
Okay, so ran that command (on eth0 as the output of the first command gave me) but nothing seems to be captured in wol.log. Do I need to change the wording of it anywhere?
Start that command running, sent a WOL request to a random PC, confirmation in the FOG web page, then ctrl+c out of it and see:
0 packets received by filter
0 packets dropped by kernelCat it and it’s indeed empty.
I’m guessing from that it’s not spitting out magic packets.
-
@JRA said in Can't WOL PCs:
(on eth0 as the output of the first command gave me)
As I said you need to change
eth0to match what is installed in your fog server for its network adapter.If you use the command I provided
ip a syou will see an output that looks like this.
In my case ens192 is the right answer. That needs to replace eth0 in the command I gave you.
-
Hi there - yes did so. Eth0 in the example you put up for me and also eth0 in “real life” if you see on this FOG server.
-
@JRA How old is this host OS? What OS is this fog server using? That hasn’t been a standard for years.
-
It’s on Ubuntu 18.04.3 LTS
-
@JRA OK I just tested in my network, same subnet as fog server the system WOL correctly from a G3 state.
So you now test same subnet can FOG WOL a system that is configured in the firmware to wake up via the network?
-
Okay, it did twice, and so did wakeonlan from the FOG server.
However, it won’t do it or not do it consistently BUT I have clues…
It seems to be when it’s allowed to boot as far as the BIOS (with keypress and actually enter the BIOS,) or into POST when it’s looking for DHCP. If I power it off there then it’ll WoL from FOG every time after that. If I let it boot into W10 though and turn it off with a momentary power button press it’ll not WoL until I remove the power cable whilst it’s off, count to 20, put the cable back in and then go into the BIOS or wait for that part in POST just once more.
This works the same across different subnets/VLANs too, happily!
This does also seem a LITTLE dependent on the amount of time it’s just in a “pre-Windows” state. As in, for a test, I turned on 4 machines. Two of them I just left to boot as far as the searching for a DHCP server and then turned them off, the other two I actually went into the BIOS - didn’t change anything but exited and turned them off. The “BIOS pair” would WoL but the “DHCP off” pair did not. I then went to the next two and got them to the DHCP polling bit and then paused them for thirty seconds - again not letting W10 boot - then turned them off and these two ALSO would WoL after that.
It seems like if they spend around 40 seconds in a “non-Windows10-but-powered-on” state they then become receptive to WoL packets, but if you let Windows boot up you’ll need to power them off at the wall/pull the power cables out for 30 seconds before you can try again, and get another chance to “prime” them in this way.
I’m sure there’s a clue in there… hope that long old story is some help! Thanks much again for sticking with me also.
-
@JRA Interesting. So I am wondering, did WOL work with the old FOG server?
-
(First of hi and thanks much for popping in. It’s 8pm and I appreciate all help much <3)
Yes it did, worked a treat, although what brought on it’s retirement was it wouldn’t take the W10 image, so I started over with a new FOG server. Had a python script on the go that’d wake the domain up if I wanted. Anyways, yes last time that was confirmed working was indeed the old W7 days. Now we have W10 I am fairly sure I can say didn’t work any longer at that point, although it was still around for a little while (both FOG servers had different IPs, just changed the DHCP options to the new one.)
-
@JRA said in Can't WOL PCs:
Had a python script on the go that’d wake the domain up if I wanted
So you mean WOL was triggered by an external tool?
-
It used to work from the gui in the “regular” way too, but the previous NM also had a script arrangement yes.
-
@JRA But was this FOG or a third party tool? Just wondering because it could possibly be the other software used a somehow different WOL packet or even the very old FOG version did. That was way before I joined the team.
Please run
ps ax | grep WOLin your new FOG server and post output here. -
@JRA said in Can't WOL PCs:
I’m trying to digest this, but it is consistent with what I know about how win10 breaks WOL.
It seems to be when it’s allowed to boot as far as the BIOS (with keypress and actually enter the BIOS,) or into POST when it’s looking for DHCP. If I power it off there then it’ll WoL from FOG every time after that.
This is consistent WOL from ACPI state G3.
If I let it boot into W10 though and turn it off with a momentary power button press it’ll not WoL until I remove the power cable whilst it’s off, count to 20, put the cable back in and then go into the BIOS or wait for that part in POST just once more.
This works the same across different subnets/VLANs too, happily!This is also consistent with S1-S4 sleep state where Windows has control of the WOL function. Pulling the plug, waiting, and then repowering it resets it state to G3.
This does also seem a LITTLE dependent on the amount of time it’s just in a “pre-Windows” state. As in, for a test, I turned on 4 machines. Two of them I just left to boot as far as the searching for a DHCP server and then turned them off, the other two I actually went into the BIOS - didn’t change anything but exited and turned them off. The “BIOS pair” would WoL but the “DHCP off” pair did not. I then went to the next two and got them to the DHCP polling bit and then paused them for thirty seconds - again not letting W10 boot - then turned them off and these two ALSO would WoL after that.
It seems like if they spend around 40 seconds in a “non-Windows10-but-powered-on” state they then become receptive to WoL packets, but if you let Windows boot up you’ll need to power them off at the wall/pull the power cables out for 30 seconds before you can try again, and get another chance to “prime” them in this way.Still consistent with Win10 in charge of the network interface.
On a test computer go into Device Manager -> Network adapter -> Advanced Tab (at least on intel nic). Make sure all of the WOL options are enabled. It appears this nic supports magic packets and pattern match (both methods of WOL) so you need to turn them on independently.
-
Cheers again both.
@Sebastian-Roth Thanks much. I ran that but got nothing from it.
@george1421 Yes I’ve seen that, thanks. Had a look and didn’t find those WoL options, even updated the driver and still don’t see those options in the tab. Horrid thing…
-
@JRA Ok then in the network driver setting (same neighborhood) How about these settings.
Turn off allow computer to disable this device to save power
Turn on allow to wake leave the second one off or only magic packet method will wake it. At this point I don’t know what is the right answer. I don’t use WOL in my environment, and if I do its only for imaging computers in our dev lab.
