Inconsistant Wake-on-Lan

system · March 29, 2010, 11:30pm

(imported topic written by SystemAdmin)

We are experimenting with wake-on-lan for BigFix Power Management. We have enabled at the console, and have designated a wake-on-lan forwarder for the subnet.

Successfully waking a device appears to succeed randomly.

We are using the same target device(s) for testing, and have ensured that wake-on-lan support is enabled in BIOS.

Sometimes, the device will wake up almost immediately. Other times, the device does not respond to the request at all.

I looked at the KB article for implementation, and I believe we are set up correctly. The fact that the wake-up sometimes works should be an indicator that the basic configuration is accurate.

I saw mention in another thread about having many devices on the subnet act as WOL forwarders. Is there a recommended number of devices? What is the impact of having a device set as a WOL forwarder? What is the network impact of having multiple forwarders? If I use a BigFix relay local to the subnet as a forwarder, shouldn’t that be adequate?

BenKus · March 30, 2010, 12:51am

(imported comment written by BenKus)

Hey Mike,

There is a built-in limiter that prevents agents from sending out too many WoL packets to the same computer. So if you try to wake up the same computer twice in a short period (I think it is 10 minutes), then it won’t work until you wait for the timeout to expire. In testing, this issue comes up often but in production it is rarely hit.

Does this maybe describe what you are seeing?

Also, are you waking from standby or waking from power-off?

For your question about the WoL forwarders, our general advice is to make all the computers WoL forwarders unless you have big subnets (bigger than 255 computers)… The reason for this is that the WoL packets are very small and fast to transmit on the LAN and the agents have several optimizations/controls to prevent blasting packets unnecessarily… so you tend to have minimal downsides to making more WoL forwarders…

Note that if you have some very specific reason to be concerned about small amounts of broadcast traffic (such as if you had a subnet with your VPN clients and you wanted to minimize traffic across the VPN), you can designate fewer computers as WoL forwarders… And relays are great WoL forwarders in all cases (hopefully you have lots of subnet coverage).

Ben

system · March 30, 2010, 4:27pm

(imported comment written by SystemAdmin)

The symptoms may be similar.

I just tested again. The target device is sitting right next to me and is powered off - not standby. With only one request sent, the device is unresponsive. Link lights on the switch the device is connected to are indicative that the NIC is active and should be able to receive the WOL request.

I’ll wait 10 minutes and then try again.

It’s just odd that the response is either immediate, or not at all.

Is the WOL request a single packet? Is the request logged at the forwarders?

Our subnets are larger than 255, so I may look at identifying a group of clients to act as WOL forwarders. We have a relay on every subnet, so I’ll start from there.

BenKus · March 31, 2010, 4:16am

(imported comment written by BenKus)

Hi Mike,

The WoL request is a single broadcast packet.

So just to be sure, you have seen this computer wake-up from the powered-off state before?

You might try the “wake-from-web” report to try to wake up the system because it does some basic error checks on the WoL setup and it will tell you if it finds a problem.

Ben

system · August 11, 2010, 2:44pm

(imported comment written by SystemAdmin)

We are facing similar issues with Wake on LAN. The systems are in power-off state. We also have issues with the Schedule WOL feature. Our idea is to WOL PC’s at midnight so that patches can be applied during non-working hours and use a power profile to put the system in standby or hibernate mode.

What we see is something strange - we use the schedule WOL feature - advanced options for Execution Start time say 10 am. Current time lets say is 9 am. If we issue the WOL scheduler, what we see is that the PC powers on at 9 am itself while the BES Console shows Waiting. This state is observed till 10 am, before the PC replies back Not Relevant.

Our question is that the PC did receive the WOL - but why was this executed at 9 am instead of 10 am ? Secondly, does this advanced scheduler option for WOL work or are we missing something here.

<< Screenshots attached >>

BenKus · August 12, 2010, 5:52am

(imported comment written by BenKus)

This might be due to the agent with a different clock waking the computer up…

The new version of power management due out shortly has a much better mechanism for scheduled wake-on-lan and I think it will fix these things…

Ben

system · August 12, 2010, 11:28am

(imported comment written by SystemAdmin)

The timings are the same …

The WOL magic packet almost instantaneously hits the system, though the Action tab says that the system is Waiting (for the scheduled time).

The moment the scheduled time is over, the system comes out of Waiting and becomes Not Relevant.

When is the new Power Management module due ?

system · September 28, 2010, 9:44pm

(imported comment written by SystemAdmin)

Ben - is there any way to see the 10 minute timer? Is it per machine, per agent, etc?

system · September 28, 2010, 10:14pm

(imported comment written by SystemAdmin)

The 10 minute timer is registered on the WoL Forwarder (WoLF) for each machine targeted to wake up. Basically the WoLF’s keep a table of all machines that they (or some other WoLF in the subnet) have tried to wakeup within the last 10 minutes.

By default you will not see any logging data about WoL. You can enable logging by setting this client setting:

_BESClient_Comm_WakeOnLanForwardingDebugLogging with a value of 1.

Note that this debug logging doesn’t show up in the normal bes log, but in our “emsg” log (with a detail value of at least 100 i believe), which you also have to have enabled. You can learn how to enable that log here:

http://support.bigfix.com/cgi-bin/kbdirect.pl?id=186

Once the logging is enabled, the emsg log on the WoLFs will note when they receive a WoLF Packet, and whether it is issuing a magic packet or if it is ignoring it because its in its cooldown table. Here is a list of possible WoL messages i pulled from out internal documentation:

Receive wake on lan forwarding packet

'Recv wolf packet(already in table)

, pending

,sent

’

'Recv wolf packet(add)

, pending

,sent

’

‘Recv wolf packet(ignore table full)’

Receive magic packet.

‘Recv magic packet(ignore subnet mismatch)’

‘Recv magic packet(ignore self)’

'Recv magic packet(change to not pending

, pending

,sent

’

'Recv magic packet(from lower IP so delay)

, pending

,sent

’

'Recv magic packet(from higher IP)

, pending

,sent

’

'Recv magic packet(add not pending)

, pending

,sent

’

‘Recv magic packet(ignore table full).’

Sending magic packet

'Send magic packet

, pending

,sent

’

Throwing away the list

‘Inactivity timer cleanup.’

The regular log will also contain one of the following:

SetupListener as wake-on-lan forwarder(AdapterInfo=)

SetupListener failed to initialize as wake-on-lan forwarder(AdapterInfo=…)

SetupListener

ShutdownListener

-Zak

system · September 28, 2010, 11:09pm

(imported comment written by SystemAdmin)

Zak, I posted a similar question here (http://forum.bigfix.com/viewtopic.php?id=5764). Is there a way to see the status of a WoL request in the console? How does one know if an agent sent it or ignored it due to the 10 minute rule?

system · September 30, 2010, 10:59pm

(imported comment written by SystemAdmin)

Hey jspantiz,

The platform’s WoL mechanism is UDP based (and is very similar to the “refresh” notification you can send to clients). Because of this, the sender of the wake up request (either the BES Console for the right click, or the WoLMedic for scheduled) doesn’t get any feedback about where the request was forwarded to (each relay determines if it has a WoLF reporting to it in the same subnet as the target computer) or whether it was successful.

If you are trying to debug the situation, the best method is to use the logs, as mentioned above. The emsg logs on the WoLFs will tell you whether they have received the wakeup request, and whether they have ignored it because of the 10 minute cool down.

system · October 1, 2010, 5:43pm

(imported comment written by SystemAdmin)

Zak - I guess what I was asking for was this - When a WoL is issued through the BES Console via the Scheduled Task or through Web Reports, that WoL is forwarded to a relay which forwards it to a client agent. That client agent knows if it is going to forward it out or not based on the 10 minute rule. We’d like to see which client agent handled the task and if it sent out the WoL or ignored it due to the 10 minute rule, understanding that there is no way of knowing if the client got it since it is UDP and the client is either in Standy or Off. We’d like some functionality built into the agent to report back to the relay / server when it gets a WoL request that it is supposed to broadcast out.

Digging through logs on WoL forwarders could take some time, depending on how many forwarders there are on a subnet and since there is no way of knowing which forwarder even got the request, it makes it all that more difficult.

If this could be added to the feature request list, that would be nice. Thanks.