Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Or: Why don't my PCs wake up every time I send the Magic Packet?

I do have 2 PCs with similar hardware settings, similar software (OS is Windows 7 x64 Professional) and both connected to the same network. I use some random WoL-Tool (http://www.gammadyne.com/cmdline.htm, sending the Magic Packet to the MAC address) to start the PCs up, whenever I need them.

What I experienced is the following: About 95% (or even higher) of the time, Wake On Lan is working just great on both of the PCs. But sometimes one or the other (never head both so far) does not wake up, after the package has been sent. It so, even re sending the packet multiple times (even after some hours or days) does not help. If I start up and shutdown the affected PC manually, it will wake on lan without problems.

I already

  • did check the BIOS settings for the LAN adapter (WoL is enabled)
  • did check Advanced Device Settings ("Wake from Shutdown" is on)
  • did check the Device Power Settings ("Allow this device to wake the computer" is checked)

Is this a know problem that Wake On Lan is not 100% reliable? Any further things I might want to check?

Update: Fixed wording.

Update: Some points that were mentioned:

  • Both PCs are set to automatically start up after a power loss.
  • Both PCs are on a power supply that is not switched off.
  • Both PCs are directly connected to the same router.

Update I managed to "provoke" one PC to not start on WoL by just Waking them and shutting them both down repeatedly. The LEDs on the LAN adapters on both PCs are blinking (about 1 green blink per second). I tried unplugging and replugging the wire at that PC, but it didn't help.

share|improve this question
add comment

3 Answers

By the way, it's a "packet" not a "package" :)

The same happens to me sometimes. It's a repeatable problem.

When a PC is configured to wake on LAN, it MUST continue to have standby power, and network connectivity all the time. If there is a power failure, or a network outage (restarting a switch or router is enough, it acts like disconnecting the network cable from the PC's NIC), then the PC will not respond to magic packets until after being booted into Windows and gracefully shutdown again (as you mentioned you are doing).

This is a well-documented limitation in Wake on LAN. I'm not sure if this is by design, or just something that couldn't be avoided for some reason- but I can repeat the problem on my PCs too.

Try this: look at the LED corresponding to the network jack on the switch/router these Wake on LAN PCs are connected to. The light will be on when the PC is in a state where it will respond to network wake requests. Now try disconnecting and reconnecting either the power or network cable from that system for a few seconds, then reconnecting it. Now the switch's corresponding activity LED is off. So the PC's NIC is basically shutting down completely during this brief interruption. Maybe it thinks there's no point staying on, so it does this to save a fraction of a watt of power. I'm sure it's something crazy like that.

I set the BIOS in some customer PCs (where reliable remote access is critical) to "return power to ON" after power interruption. This will turn a PC on after a power failure, even if it was shutdown when the power failure occurred. A PC which is on and ready to accept remote connections is a lot better than one which is off and will not respond to wake on LAN requests- forcing someone to go to the office just to press a button.

Most people using LogMeIn to remotely support PCs who use the "Switch on" feature will have seen this a few times (it basically incorporates wake on LAN and suffers from the same problem you described).

I'm guessing what's been causing yours to stop working was momentary environmental power issues. It's hard to be sure though. Perhaps you can work it out knowing the things that cause this problem.

share|improve this answer
    
Thanks for the answer (and the correction of the wording - will fix that)! I did set both PCs so they are booting up, as soon as the power is back. Both PCs also are on permanent power supply. This should not cause the problem... –  Birgit_B Feb 23 '13 at 16:48
1  
You might want to leave the computers on for a while, set a non-terminating ping to your router and pipe that to a log file. I've noticed many home routers may get flaky and automatically reboot. Unless you are using the router at the time, you might not notice it. –  Russell S. Pierce Feb 23 '13 at 17:06
    
But shouldn't a rebooting router affect both PCs the same way? –  Birgit_B Feb 23 '13 at 17:09
    
@Birgit_B: Good point, if they were shut down at the same time, then both PCs should be affected in the same way. If they weren't shut down at the same time, then the one that was shutdown first should be more likely to be affected than the one that was shutdown later. –  Russell S. Pierce Feb 23 '13 at 17:11
    
By permanent power supply do you mean a UPS? –  Russell S. Pierce Feb 23 '13 at 17:12
show 5 more comments

I manage a network with ~500 computers. I use WOL all the time, and also find these problems. I have found that the biggest culprit is windows going into sleep or hibernation.

When I image machines, I run a batch file on them like this.

powercfg.exe -s scheme_min
powercfg.exe -h off

The first line should stop the computer from ever going to sleep, and the second turns off hibernation with saves a few GB of hard drive space by also removing hyberfile.sys(on reboot)

share|improve this answer
add comment

It might also be something to do with the router that you are using. Some by default block a lot of 'strange' traffic, which the manufacturer might not think that a normal user will be using. Just a thought

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.