Can't WOL PCs

[Sebastian Roth]

@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?

[JRA]

@Sebastian-Roth

It used to work from the gui in the “regular” way too, but the previous NM also had a script arrangement yes.

[Sebastian Roth]

@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 WOL in your new FOG server and post output here.

[george1421]

@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.

[JRA]

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…

[george1421]

@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.

[JRA]

@george1421 You are a gentleman thank you for staying with me on this. I’ll give it a go and let you know…

[Sebastian Roth]

@george1421 @JRA Did we actually see the WOL packets in the PCAP dump?

[george1421]

@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:

1. The target computer will wake WOL from a just plugged in and powered off state.
2. Once you boot into windows the system no longer WOL until you unplug the system again.
3. This happens for both FOG server WOL and third party WOL.

@JRA please confirm that I understand the conditions correctly.

[JRA]

@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.