6

I have a PC behind a router with a dynamic IP address that I want to configure for wake-on-LAN.

How do I send the magic packet to the PC? Do I configure my router to forward UDP port 6 to the PC? How would I send the packet from another PC on the network? How about a PC outside the network?

Is this even possible?

Update: here is a pertinent configuration screen from my router. Any hope?

http://files.quickmediasolutions.com/router.png

7 Answers 7

3

Static ARP is completely unnecessary

You've got the first part right. To get the WOL packet into the network, forward the packet coming from a specific port to the broadcast address of the local network (255.255.255.255) or whatever subnet range you want WOL access to be enabled on.

The Destination MAC address of the packet should be set to ethernet broadcast or FF:FF:FF:FF:FF:FF. The ethernet type of the packet should be 0x0842 (Wake On Lan).

So, where does the MAC of the computer being woken up go?

In the magic packet itself. WOL packets were only really intended to be sent across a local network. They're blind to any protocol above the link layer. To get around this limitation, they broadcast (ethernet broadcast not IP broadcast) to all the computers on the network and each computer reads the magic packet to see if they're the one being called on.

The contents of the magic packet contain 16 copies of the MAC address of the computer being woken up.

The frame structure is as follows:

DA -> SA -> Type -> Magic Packet

Where:

DA = FF:FF:FF:FF:FF:FF
SA = [whatever the source MAC is]
Type = 0x0842
Magic = [The actual destination MAC repeated 16x]

If you want to test that the packets coming across are in the right format, use the following filter in Wireshark:

ether dst FF:FF:FF:FF:FF:FF and ether proto 0x0842

Basically, the WOL application needs to be capable of creating a packet that spoofs the Ethernet Destination address. There are tools online that can do such a thing but I'm not familiar with them.

Note: The reason I know so much about this is because I'm the author of the WOL parser for SharpPcap (pcap wrapper in C#). If there is sufficient demand, I could extend my console application to include packet sending (it currently only sniffs) and make it available as an OSS project.

Update: @Evan Anderson made a good point that I forgot to mention. Broadcasting incoming packets on a LAN is generally a bad idea. This solution will work but it's only a hack to circumvent the limitations of the Wake On Lan protocol.

The technique I've outlined will work for any computer on the LAN the way WOL was designed but could potentially open your network up to be used for as an attack (Smurf/Fraggle/Papasmurf) amplifier if someone were to send a specially crafted packet to the WOL port.

Evan Anderson's approach is technically more secure but is limited to unicast.

3
  • A router configuration that allows directed broadcasts to be forwarded in from the Internet isn't a good idea. That configuration is half of what it takes to allow "Smurf Attacks" to occur (en.wikipedia.org/wiki/Smurf_attack). I think it's a fairly good assumption that routers don't forward directed broadcasts, personally, and I wouldn't configure one to do so. Jan 13, 2012 at 22:11
  • @Evan Anderson I don't disagree. Broadcasting anything on a local network that comes from the internet is a bad idea. Until somebody modifies the router-level handling (ex. on openwrt) to forward WOL packets in a safe manner it will never be safe. For whatever reasons the designers of WOL only made it work on the first two layers of the networking stack. Any means to circumvent that limitation (like the one above) are just hacks. Jan 14, 2012 at 0:00
  • (cont) A 90% solution would be to add a 'Wake On Lan' feature to the router where it listens on a port, analyzes/verifies the packet, and forwards only the layer 2 portion of the packet to a specified subnet broadcast address. Validation would prevent Smurf attacks (ie. it would block ICMP/ping) but there's no guarantee that it wouldn't be abused by somebody sending a massive number of valid WOL packets in succession. Jan 14, 2012 at 0:00
6

It sounds like some reading-up on WOL is probably in order first. Some additional reading about Ethernet, ARP, and UDP/IP is probably in order, too.

The WOL behavior in a client is triggered by a "magic packet". The magic packet can be encapsulated in any type of transport (UDP over IP, IPX, etc). The magic packet byte sequence just needs to be in the payload of a packet that the NIC to be woken-up will receive.

Sending WOL requests on the LAN is easy. Get a utility to make magic packets (like mc-wol for Windows) and fire away.

Sending WOL requests from the Internet is more problematic. You're on the right track w/ port-forwarding a UDP port from the Internet to the LAN, but there are other concerns.

You have a problem with unicast WOL requests from the Internet as follows: The MAC address of your WOL client computer won't be in the router's ARP table because, as the WOL client is powered-off, such an ARP entry would have aged out. When your router receives an IP packet port-forwarded to the WOL client's IP address while the WOL client is powered-off and its MAC address is aged out of the ARP table the router will not be able to deliver the packet to the client. You will need a router with static ARP capability to make this work.

The broadcast route is even less likely. Since you likely don't have a public subnet behind your router, but rather are using NAT to share a single public IP address on your LAN, there's no way to remotely address a packet to the subnet-broadcast address of your LAN subnet such that the router (if it could forward directed broadcasts) would generate a layer 2 broadcast with the WOL packet to allow the WOL client to "see" it.

WOL on your LAN will be easy. WOL across the Internet isn't so simple.

5
  • 1
    My router can assign static IP addresses based on MAC addresses. Does that help? Jul 18, 2010 at 21:37
  • 1
    Also, you mention that any protocol will work... will any port work? Is there a preferred port? Jul 18, 2010 at 21:39
  • 1
    @George Edison: You need static ARP entries. Assigning IP addresses based on MAC addresses (typically referred to as DHCP reservations) has nothing to do with ARP. You can use any UDP port you want. The Wikipedia article mentions some possible "preferred" ports, but I'm not aware of an IANA-registered port. Jul 18, 2010 at 21:46
  • I updated the question with a screenshot from the router config. It mentions "If adding a PC which is not connected and ON, you must provide the MAC (hardware) address." Won't this give the router the IP-to-MAC correspondence it needs to wake the PC? Jul 18, 2010 at 23:16
  • I stand corrected. I've never seen that particular router before, but it certainly looks like they've got a static ARP configuration there. Looks like you're in business. Jul 19, 2010 at 2:50
1

Rather than repeat why you are going to have problems I'll simply describe how I overcame those problems Evan has already explained.

My firewall/router is Linux based, which means I'm able to run commands on it. To wake up machines on the LAN I first SSH into the firewall and then run a Perl script which creates the magic packet and sends it out to the LAN. The MAC address of the target can be either passed as a command line parameter or hard coded, as appropriate.

Of course if you are unable to execute commands on your router you will need to find an alternative means.

2
  • 1
    It's a bit of a catch 22 if the router won't support arbitrary command functonality. I'd say "leave a PC turned on behind the router that you can access remotely and send the magic packet from" but, then, that kinda defeats the purpose re: trying to save power by turning things off. Jul 18, 2010 at 21:47
  • Unfortunately this is not possible, as the only other PC connected to the network is usually off. Jul 18, 2010 at 23:17
0

As Evan and John already covered, WoL over the internet is unlikely to work.

You need some sort of device inside of the firewall that can send the packets on your behalf. We use a web application hosted on our intranet. Sounds like that's not an option, so there's really only three other options that come to mind:

  • Leave a low-powered device, like a Linux-based thin client from ebay powered up for your PC wakeup needs.
  • If you happen to have an Intel-platform PC with vPro, buy a certificate and you'll be able to wake up PC via the service processor instead of WoL.
  • I haven't done this myself, but I believe that some UPS (Uninterruptible Power Supply) units provide the ability to power on and off ports. Not sure what a unit that is capable of doing that costs, but it is probably worth looking into.
0

I recently found that port forwarding a UDP port to x.x.x.255 worked on one router, but not another.

I added a static ARP entry on the router through telnet arp add x.x.x.y FF:FF:FF:FF:FF:FF for an unused internal IP x.x.x.y to FF:FF:FF:FF:FF:FF (the broadcast MAC) as noted here and port forwarded the WOL UDP port to that unused IP instead, that works for me for WOL from the Internet.

1
  • The second method works fine if you've got a router that supports adding arbitrary static ARP entries. Many don't, though, which was the crux of all the hand wringing in the earlier answers. Oct 27, 2011 at 0:54
0

This is what I did on my raspberry pi which I use for an openvpn server

iptables -A PREROUTING -p udp --dport 9  -d x.x.x.255 -j DNAT --to-destination x.x.x.255
0

Some (cisco) routers are able to forward directed UDP broadcast.

Linux kernel since circa version 5.0 is able to do this. You just need to specify a parameter for particular network interface:

sudo sysctl -w net.ipv4.conf.eth1.bc_forwarding=1

(Note: it seems the option net.ipv4.conf.all.bc_forwarding doesn't work)

And you need to do DNAT with iptables on the router, if your PC is behind NAT.

You must log in to answer this question.

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