Can't WOL PCs
-
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.
-
@george1421 You are a gentleman thank you for staying with me on this. I’ll give it a go and let you know…
-
@george1421 @JRA Did we actually see the WOL packets in the PCAP dump?
Web GUI issue? Please check apache error (debian/ubuntu: /var/log/apache2/error.log, centos/fedora/rhel: /var/log/httpd/error_log) and php-fpm log (/var/log/php*-fpm.log)
Please support FOG if you like it: https://wiki.fogproject.org/wiki/index.php/Support_FOG
-
@Sebastian-Roth I don’t think we ever got a valid pcap of the wol at the OPs location.
I just setup a test in my lab and I was able to capture a WOL pcap using this wireshark
ether proto 0x0842 or udp port 9
As you can see the FOG server sends out 2 sets of broadcast messages. It sends a subnet broadcast and a ethernet broadcast.So at least for FOG 1.5.8 its sending WOL correctly.
In the case of the OP I think this is where we are at:
- The target computer will wake WOL from a just plugged in and powered off state.
- Once you boot into windows the system no longer WOL until you unplug the system again.
- This happens for both FOG server WOL and third party WOL.
@JRA please confirm that I understand the conditions correctly.
-
@george1421 Hi folks - so sorry huge influx of users back today, had to get on with other bits.
All three of your points correct though George yes. Although I’d add in on point 2 that it won’t WoL until power is unplugged for about 20 secs and also, following that, the PC is then booted to BIOS for a few seconds or paused at the polling for DHCP part of POST, and then shut down again. That will “prime it” for WoL and WoL will work thereafter until Windows is booted, then it won’t until you repeat the above “priming” process.
Thanks again everyone.
At this stage it’s not looking like a FOG problem strictly, so if you’re getting sick of it it’d be fair to say it’s outside you folks’ remit but I do appreciate the help muchly.
