Which table to check in db to see if there are pending wakeup entrys

[x23piracy]

@Quazz said in Which table to check in db to see if there are pending wakeup entrys:

@Tom-Elliott facepalms in Microsoft’s general direction

ACK! was a bad day for me

[Wayne Workman]

So Microsoft would let me send just a ping to… you know… the broadcast address of a mega-company in their internal network from… say a wifi connection outside the building, and I can literally wake up every single computer in the entire network, whether WOL is enabled or not, as long as Fast Startup is turned on? I guess that’d make port scanning and ‘penetration testing’ all the easier, right? I hope microsoft reads this.

[Tom Elliott]

@Wayne-Workman I suppose I should add more information to how I derived at this idea then, just in case they do read it.

So, as @x23piracy stated, Systems were turning on even after he removed them. However this wasn’t in the case of the host not existing. Ping and WOL only happen on “registered” hosts. However, in the case of Ping, the pinging would operate on “Pending” hosts as well. Removing the host from both register and pending hosts, and the problem would go away.

So we ran a few tests to figure out exactly what was causing it. First, we stopped fogscheduler service. He also has another node, so we also stopped fogscheduler on the node. I know the other node had nothing to do with it, as turning off the fog server itself the issues went away. This didn’t help. Well that blows the “WOL” theory right out the window because only taskings and FOGScheduler do any WOL stuff. To be exact, FOGScheduler only performs WOL on schedules of Powermanagement and taskings awaiting that are WOL enabled. Seeing as there was no Powermanagement items in the DB and there were no tasks waiting to be performed, that was enough proof that this was not a WOL problem at all. Add to that, stopping the FOGScheduler service didn’t fix the “hosts waking up randomly”.

So @x23piracy decided to see about FOGPingHosts. He stopped the service, shutdown one of the “problem” systems, waited some period of time and nothing at all happened. So we started FOGPingHosts and immediately the system that was shutdown started.

So, I added a quick test by only allowing FOGPingHosts to ping hosts that were approved. Initially I only had it checking of the value of the pending state was set to 0, but when fog approves a host, the value might be an empty string, or 0. I was initially searching for 0, and stopped and started the FOGPingHosts service. Nothing happened. In our case, it wasn’t returning any hosts , so I extended the “approved” host search to search empty strings and 0 as the value. At this point we restarted FOGPingHosts again, and immediately approved systems that were shutdown started turning on.

There was no real indication as to what or why, but now I had a theory to try. So I had @x23piracy hard poweroff one of the problem systems. Once again, I restarted PingHosts and nothing happened. So we loaded into the windows system and ran powercfg -h off and shutdown the system. Now restarting the FOGPingHosts service also had no impact. Thus leading me to the conclusion it must be something with the ping. Remember, Pings don’t happen in the same way as normal with fog. We aren’t simply sending a ping command, we’re essentially scanning a port (# 445 by default) and getting the information from the socket opened so we can be more verbose about that systems status.

[Wayne Workman]

@Tom-Elliott said in Which table to check in db to see if there are pending wakeup entrys:

We aren’t simply sending a ping command, we’re essentially scanning a port (# 445 by default) and getting the information from the socket opened so we can be more verbose about that systems status.

I suppose a ‘penetration tester’ could easily leverage this new feature that Microsoft has implemented. Computers - whether fast startup or not, when they are ‘off’ (or whatever you want to call it) should only turn on if WOL is enabled in firmware, and by a WOL packet only. This is not FOG’s fault, it’s Microsoft’s fault.

[x23piracy]

I just found this…
https://communities.intel.com/thread/29566

I’m trying to refrain from celebrating until it’s been a few days with no wakes, but I think I FINALLY found the answer. I’ll document it in case some other poor soul has this problem and googles it.

In the BIOS menu there’s an option to display the Intel ME prompt during boot. It’s together with the options to display F2 to enter setup, F10 to enter boot menu, and so on. I enabled it just to see what it was. Upon restart, sure enough, right at the end of the POST there’s a prompt to press CTRL+P to enter Intel ME. I did. Apparently it’s kind of an extension to the BIOS menus. Among the few items inside, there was a “remote wake up” thing which was set to Enabled. I set it to Disabled. Now the computer doesn’t reply to pings when it’s sleeping. As I said, it will be a couple of days until I can be sure that I’ve solved the problem, but it does look promising.

I have to say, this Intel ME thing (I think it’s Management Engine) is not documented anywhere, nobody seems to know about it, and why Intel put those options there instead of in the BIOS menus with the rest, is beyond me. Even the prompt to enter Intel ME is disabled by default, I was lucky to stumble upon it after trying everything.

Anyway, I hope it works permanently. I would like to thank everyone for your suggestions, especially rseiler. I may have ended solving the problem by myself (hopefully!), but I appreciate the time you took to contribute. I’ll let you know if there are any news, or I’ll mark the question as answered in a couple of days.

I need to sleep now but the solution sounds interesting and the problematic pcs have intel nics.

Will try this on monday!

Regards X23

[george1421]

@x23piracy Just for some background information here, I can say that the ME (or actually vPro) is only on select model of computers. Its intended to be a software version of the light-out / RSA / iLo / DRAC / remote management adapter that you find in servers. When vPro is setup you can actually remote into a computer (via the Management Engine) and power it on/off change bios setting, reinstall an OS outside of what ever OS is running on the target computer. It is a really cool, and some what of a PITA to setup - technology. Typically if its not activated the software lays dormant and does not interact with or cause pain to the target OS. It is not part of the bios actually it has its own firmware and kind of runs outside of the traditional bios/firmware. This vPro is actually an add in to the CPU and not anything really to do with the network adapter or its interface. The reason why your network adapter remains operational even of the computer is powered down, is because of vPro is running on the computer in the background on the motherboard.

[x23piracy]

@george1421 look at this, found on the Computers that made Trouble (Intel nics)

The text means in englisch: Activate on pattern match!

i will now also check Intel ME…

Regards X23

[x23piracy]

@george1421 @tom-elliott

no need to disable hibernating (powercfg -h off) The intel I219 NIC’s support wakeup by pattern match (ping) that can de bisabled within the driver look to my post before with the screenshot.

The question is howto integrate that setting into the image, i think this is registry saved but howto import this before sysprepping? afaik the path in the registry can be different when it detects the nic lan-connection#2 #3 #4 etc.

Any idea?

Regards X23

[Tom Elliott]

@x23piracy Because what you’re referencing (from what I can tell) is individual device properties, I don’t think you’ll find a viable fix for imaging using that method. This is because even if every system has identical model of nic’s in them, the device between is different.

I’d still recommend using the powercfg -h off option as it’s a sure fire way to ensure it will work across the board.

[x23piracy]

@Tom-Elliott sure i will stick with -h off because we don’t do hibernating but i would like to share information about that behaviour maybe someone can use it

Regards X23

[Tom Elliott]

@x23piracy Of course, sharing information is always good, but a “here’s how to do it always all the time” is likely not possible doing the method you show below. (Unless you go one by one to every system lol).

[Quazz]

@Tom-Elliott Wouldn’t it be possible with the postdownload driver install script if you modify the associated config files for those drivers?

[Tom Elliott]

@Quazz Sure, I suppose, but not quite easily. You have to know exactly where the file is. I’m not 100% sure the file actually exposes the firmware configuration in that manner though.

[Sebastian Roth]

Should be possible to use windows scripting host (WSH) to check with number your NIC is and set the registry key. Have you found out about the registry key yet?

[george1421]

@Sebastian-Roth While I’ve been loosely following this, but setting nic properties has been problematic in the past since the nics are added based on a guid. The trick is that you have to find the right guid for the network adapter in question. You can typically do that by finding the network type (loopback, wireless, ethernet). Once you know the device guid then you can update the registry keys associated with that network adapter.

While I haven’t had to do this I think M$ extended netsh so that you can manage network adapters easier.

[george1421]

@george1421 Again be aware I did not read the entire post so there is a high possibility that this post is off point, but I did find a vbscript on Spiceworks that will set the wol function on the network adapters.

https://community.spiceworks.com/scripts/show/240-script-to-enable-wake-on-lan-windows

[x23piracy]

Hi,

i found out that intel offers a powershell module to manage their cards, but i have integrated the intel driver by rightclicking the inf and installed it into my base system but it seems that this will not install the ps module for it.

Lets say that module is installed we are able to set the card:

Get-IntelNetAdapter
Get-IntelNetAdapterSetting
Set-IntelNetAdapterSetting –Name "Intel(R) Ethernet Connection (2) I218-V" –RegistryKeyword "*WakeOnPattern"  –RegistryValue "0"

Sources:

https://atsoftware.de/2014/08/configure-adapter-settings-for-intel-nic-using-powershell/
http://www.potentengineer.com/intel-proset-powershell-module/

EDIT:

Damnit i downloaded the current Driver package from Intel but the module is missing!

Regards X23

[Wayne Workman]

@x23piracy A for effort.

[x23piracy]

@Wayne-Workman said in Which table to check in db to see if there are pending wakeup entrys:

@x23piracy A for effort.

Thank you Wayne but i cannot find that powershell module. Anyone who has it installed?
The Intel Cards we have are I219-LM ones.

Regards X23

[x23piracy]

Hi,

what should i say? ok lol, they removed the extra option for powershell module in current proset setups, but if i choose to use more time reading everything i can find this:

Ok more googling until here:

ftp://ftp.supermicro.com/CDR-X9_1.23_for_Intel_X9_platform/Intel/LAN/v18.8/PRO1000/DOCS/SERVER/prosetdm.htm

PS c:\> Import-Module -Name "C:\Program Files\Intel\IntelNetCmdlets\IntelNetCmdlets"

Ok lets try:

Wooo that sh** works

The corresponding registry values seems to be this @Sebastian-Roth :

[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Class\{4d36e972-e325-11ce-bfc1-08002be10318}\0001]
"*WakeOnPattern"="0"

[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Class\{4d36e972-e325-11ce-bfc1-08002be10318}\0001\Ndi\Params\*WakeOnPattern]
"ParamDesc"="Akt. bei Musterübereinstimmung"
"type"="enum"
"default"="1"

[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Class\{4d36e972-e325-11ce-bfc1-08002be10318}\0001\Ndi\Params\*WakeOnPattern\Enum]
"0"="Deaktiviert"
"1"="Aktiviert"

@Tom-Elliott said in Which table to check in db to see if there are pending wakeup entrys:

@Quazz Sure, I suppose, but not quite easily. You have to know exactly where the file is. I’m not 100% sure the file actually exposes the firmware configuration in that manner though.

i think you are absolutely right here because changing the pattern option via rdp interrupts the connection for ~5-6 seconds, seems to be a sign that the card reinitalizes (driver reload).

Regards X23