7

I just purchased a new computer running Windows 7 Professional x64. I'd like to save power by having it sleep after an hour, but I would also like to be able to Remote Desktop into it at my leisure.

I set up a static IP and have port forwarding set up on the router. If the computer is awake, the RDP connection works just fine.

I downloaded and installed Wake-On-LAN thanks to this article

If I put my new computer to sleep and send the magic packet from my old computer inside of my home network it wakes up. If I do the same thing, however, from my work computer outside the network it does not.

I figured the Firewall was blocking the incoming traffic, but nothing in the Windows Firewall logs points to this happening.

I'm wondering if anyone has any suggestions or any tests I can run through in order to narrow down what the problem might be.

Improve this question

6 Answers 6

Reset to default
2

I had a similar problem as yours, and I used a webpage on my server to send the magic packet.

I used the code and WolAsp.dll from Depicus:

Wake On Lan for Active Server Pages allows any IIS web browser with the ASP interpreter to send a Magic Packet to a remote machine

From their FAQ page:

Wake on Lan over the Internet (or why is it such a pain in the ****)

"IP directed broadcasts are used in the extremely common and popular "smurf" denial of service attack, and can also be used in related attacks.

An IP directed broadcast is a datagram which is sent to the broadcast address of a subnet to which the sending machine is not directly attached. The directed broadcast is routed through the network as a unicast packet until it arrives at the target subnet, where it is converted into a link-layer broadcast. Because of the nature of the IP addressing architecture, only the last router in the chain, the one that is connected directly to the target subnet, can conclusively identify a directed broadcast. Directed broadcasts are occasionally used for legitimate purposes, but such use is not common outside the financial services industry.

In a "smurf" attack, the attacker sends ICMP echo requests from a falsified source address to a directed broadcast address, causing all the hosts on the target subnet to send replies to the falsified source. By sending a continuous stream of such requests, the attacker can create a much larger stream of replies, which can completely inundate the host whose address is being falsified.

If a Cisco interface is configured with the no ip directed-broadcast command, directed broadcasts that would otherwise be "exploded" into link-layer broadcasts at that interface are dropped instead. Note that this means that no ip directed-broadcast must be configured on every interface of every router that might be connected to a target subnet; it is not sufficient to configure only firewall routers. The no ip directed-broadcast command is the default in Cisco IOS software version 12.0 and later. In earlier versions, the command should be applied to every LAN interface that isn't known to forward legitimate directed broadcasts."

Quoted from Cisco.

I wonder if somewhere along the line, the packet's being blocked. You can try Depicus' WoL on the Internet page and see if the packet will reach your computer.

Improve this answer
3
  • Jared, I tried the WoL Internet page to no avail, but do not see how it is any different than the client application. Should I be looking into a way to configure my router to not block ip directed broadcasts or is that a recipe for disaster?
    – Michael
    Nov 28, 2009 at 18:12
  • If that's not working either, it sounds like the packet is getting lost on the way to your computer. I never had any luck doing it over the internet, which is why I set up my own webpage on my server to do the WoL
    – Jared Harley
    Nov 30, 2009 at 0:55
  • The main reason that I'm interested in getting this to work is to save power and, in the process, extend the life of my PC. Getting a static IP, adding a server that is always on, etc, etc doesn't really fit those needs, but I do appreciate your input on this and I'm sure it will be valuable to anyone else who comes across this post.
    – Michael
    Dec 4, 2009 at 16:24
1

Instead of all this - you can try Device Manager - expand Network Adapters - Properties for the Network controller you are using - then go to Power Management tab - and UNCHECK the option to allow ONLY the Magic packet to wake your computer from sleep. OK OK OK - then test. This scenario (disabling the requirement for only the Magic Packet to wake the PC up) works in our case. One thing to keep in mind - sometimes when establishing Remote Desktop Connection while the PC is asleep - the first time you try the RDP will fail BUT it will wake the PC. The second time you try - it will connect just fine. Ping does not work while the PC is asleep. This is for HP 6000pro Desktops and not sure if this will be fixed in the future with OS patches or network card driver updates.

Still troubleshooting why the PC won't wake up if goes in hibernation in couple of hours, rather than sleep mode.

Improve this answer
2
  • This is an option that I had forgotten about. My concern with this was that I read somewhere that disabling the Magic Packet only option means that random traffic that comes to your computer will wake it up. Do you guys notice that happening often with the ones you have set up this way? I feel like it would be better to have the computer always be on that having it constantly turning off and on ... thoughts?
    – Michael
    Dec 4, 2009 at 16:23
  • 1
    I implemented this as a test and, as I was afraid of, my computer is constantly waking up for random network traffic. I fear that having my computer falling asleep and starting up over and over again all day is worse than just leaving it on all day. With that said, I'm back to square one.
    – Michael
    Dec 8, 2009 at 23:03
1

Your router needs to be configured to accept and forward these packets. Unless you do that, there is no way for traffic to get from the outside to your sleeping computer on the inside.

Whether to actually do it or not is up to you. Forwarding traffic has some inherent risks.

Basic Steps:

  1. Forward UPD port 7 or 9 to the IP of the desired WOL computer. Which port you need to use will depend on the WOL client you are using. If the client allows it, you could probably get away with any random, high-numbered port.
  2. If you are on multiple private networks, you may need to add a static ARP entry of your WOL computer with FF:FF:FF:FF:FF:FF for the MAC. That should allow it to forward between switches.

The other thing you could do, is to install DD-WRT on your router if it is compatible. This would allow you to use the router as a WOL client, and you could simply telnet into it and issue the appropriate commands.

Great document from DD-WRT, (and where I found all this info) ==> DD-WRT WOL Page

Improve this answer
1
  • Confirming this: "And it ONLY works if the [machine] is on the same subnet as you are currently on (because most routers do not pass the magic packet in or out, beyond their confines). " hintsforums.macworld.com/showthread.php?t=52629
    – hawkeye
    Aug 6, 2011 at 13:15
1

The problem here is that once your computer has been offline for more than a while (5-10 min?), the mac address is removed from the arp cache and there is no link between the mac- and the ip address.

So the only way to wake your computer is to send a broadcast message. This is no problem on a LAN, but not directly possible over the internet.

What you need to do is port forward to ip ...255 which is the default broadcast ip.

On my D-link DIR655 it seems portforward doesn't work, but virtual server does... (Which is the same thing)? More info here: http://forums.dlink.com/index.php?PHPSESSID=78ba918bee8de38323a22f203df16195&topic=5934.15

Improve this answer
0

From what I understand, Wake on LAN only works if the magic packet is sent on the broadcast address from the same subnet as the machine you want to wake. From this, I'm curious if the solution would have to involve having a secondary computer to be the "waker" that sends the packet on your behalf.

I only have anecdotal evidence to verify. I wanted to do the same thing with our test machines at work; occasionally they get put to sleep and Wake on LAN would have been perfect. I could never wake a test machine from my development machine, but successfully woke test machines from other test machines. I could verify that the test machines were receiving the packets, but they wouldn't wake from my dev machine. I ultimately gave up and assumed that since my dev machine and the test machines were on different private networks, it would be impossible to implement.

Improve this answer
0

I would guess that your router / NAT box is blocking the magic packet. The magic packet has to be addressed to the broadcast address, your NAT box will either block it, or if you have a port forward you may have sent it to the specific address not the broadcast address. If this is the case then you could try changing the port forward so it sends to your LAN's broadcast address.

I woudn't be suprised though if you just can't make your home router forward the magic packet correctly. If this is the case then you will need some form of always on helper on your LAN. That could be your router if you can change its firmware to something that supports this, or a smaller PC that you can leave always on. You could even get/write a small app that could run on the always on PC, listening for a specific command and when it recieves it, it could send the correct magic packet for you.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .