Register for the iXsystems Community to get an ad-free experience and exclusive discounts in our eBay Store.

Wake On LAN (WOL): Why it works, why it doesn't and frustration

Western Digital Drives - The Preferred Drives of FreeNAS and TrueNAS CORE

R.G.

Member
Joined
Sep 11, 2011
Messages
93
I'm trying to get my latest FreeNAS machine to WOL. It's not there yet, but I have this whole new education on WOL, and I thought I'd share. I'd like to invite people who HAVE gotten it running to contribute what they did to get theirs to run. The more we know about this, the easier it is for someone who has a valid use for WOL to at least try it out.

First the warnings. I have been sternly advised by people with experience with FreeNAS and this forum that
FreeNAS is not intended to be woken and shut down on demand. It's intended to be run 24/7 and optimized for doing that.
I have been warned that indiscriminate shutdown and wake up endangers your data in myriad ways. This is probably dead accurate - if you do lots of shut down and wake cycles on your FreeNAS machine, and are not really skilled at what needs done and not done, you flirt with total loss of your data by your own actions and ignorance. Worse, because of your lack of education, you may do this without even knowing the dangers. You have been warned.

I have chosen to accept the risks. I have a long history with computers, back into the 70s, and have the scars to prove it. I fully accept that the data I lose is my own, and I will not blame FreeNAS for my fumbles. Think carefully about whether you know the things you don't know in enough detail. The data you lose may be your own, and it won't be the fault of FreeNAS.

The problem is, WOL needs eveything from the functions of the machine sending the WOL message to the entirety of the receiving machine to be working perfectly, and "perfectly" has a very long, very picky definition that is hardware and software dependent.

First some definitions, because I use acronyms a lot.
WOL = Wake On LAN, what we're trying to do.
WOW = Wake on Wide Area Net, which is WOL but sent from the wild, wooly internet. This is what many people want to do, but risky and even more of a fancy dance step than WOL Also called WOWLAN, WOWAN, other variants of the acronym.
NI = Network Interface; typically a chip set intended to receive ethernet, but can be optical fiber or some other versions of networking. It's job is to receive the magic packet and pull the "wake me up now" line on the motherboard..
NIC = Network Interface Card; as above, but plugs into a slot on the motherboard somehow.
MB = Motherboard
MAC = "A media access control address (MAC address) is a unique identifier assigned to network interfaces for communications on the physical network segment. MAC addresses are used as a network address for most IEEE 802 network technologies, including Ethernet." (copied from wikipedia) The MAC is a factory-burned-in hardware address that the NI recognizes as "that's me".
Magic Packet = specially formed packet sent to the NI to make it pull the "wake me now" line. This packet contains six bytes of FF (decimal 255) one after the other, followed immediately by sixteen repetitions of the MAC for the NIC. The NIC is to recognize the synchronization bytes of FF, and its own MAC six times as the "go now" signal. Magic packets have to be sent to a MAC address, not an IP address. A magic packet may be contained in any of the numerous formats of packets on the net, as all the NI looks for is the bit format. So it can be sent by TCP, UDP, or may others. Generally, a UDP packet is used, and is generally sent to a specific UDP port. Usually this is port 9, less frequently 7.
S5 = Sleep state 5, meaning powered off, but with the power supply still giving the NI enough power to recognize the magic packet. There are other sleep states.

WOL is hard because all, every, 100% of the following has to be right:

Network connection: Wired can be made to work (including fiber, etc.) but wireless does not (at this time, although they're working on it) because the extra bits and such on the over-the-RF-link muck up the special bit pattern.
Power supply: the computer power supply has to supply enough +5V Standby power to make the NI, whether on the motherboard or in a plug-in card, work while everything else is down. I've seen figures of 1A minimum needed. Check your power supply specs, as well as the specs for what's needed on the motherboard and NI, including card if you're not using the on-motherboard NI.
Motherboard: the motherboard has to support Wake On Lan. This is one of those well, duuh, kinds of things, but it has to be checked. Motherboard has to have a "power me on now" signal which when pulled causes a power on, and if the signal wires/traces are there, look at what the wire/trace is doing.
Older MBs will have a wired "wake me now" socket for a NIC, newer ones will have PCI or PCIe slots with the "wake me now" signal on the plug-in bus and don't need the flying wire. The motherboard *may* have an onboard NI that works with WOL. Pretty much all the popular (with motherboard makers!) chip sets say they work with WOL. For some of them, it's true. Others are picky.
BIOS: the motherboard's BIOS has to support WOL as well as the chip sets supporting it. "Support" generally means "enable the hardware NI to get power during S5, and perhaps other more mysterious enablements, at least one of which is a setting in either the boot or power sections that enables either "WOL", "Wake On LAN", or "Wake on PME event" or something similar. On some MBs, the BIOS does not let you set this, so even of the hardware will, the BIOS does not let you enable it.
Network Interface, whether plugin card or onboard chip, must (1) support WOL internally by design and (2) must cooperated properly with the motherboard signaling setup for WOL. Some NICs work with some motherboards, some don't. This is made more frustrating by the fact that some NI(C)s work faster or more reliably for the real task of network communications than others, and the good communicators may not be the ones that WOL well.
OS: the operating system has to let you WOL. This involves setting the operations of the NI driver to receive the magic packet while in S5. There is a series of dance steps in each OS to do this right. The steps are sometimes highly non-obvious. In Windows, you have to mess with the properties of the network.
Router: your router has to route the magic packet to the target machine. This ought to be a "Well, duuh", but isn't. Many consumer (that's me...) grade routers make this chancy. Some routers have to be re-flashed with special software to do this, or to route in internet packets if the desired result is WOL from the internet. The setup for getting this to happen depends on how your router handles packets sent to the broadcast address for the subnet. This is a detailed part of the specifications for packet routing and formation, and is not obvious to the uninformed consumer (that's me).
Certain magic subnet addresses are "broadcast addresses" and are recognized by all the machines on the subnet. Some of these are fixed, some are not, and depend on the DHCP setup in the router. Wake from the internet is even more devious. Generally, routers recognize a packet coming in from the internet with a broadcast address as being a hacker attack on the subnet, which it may very well be. They block these explicitly. Some routers allow you to define a special address, virtual host, forwarded port, or other fancy terms as "OK, take in those broadcast packets from this one special address/format, and broad cast them on the subnet". Many don't.
Broadcast packets are the network equivalents of shotguns. Every NI examines packets to the broadcast address for "do I do anything on this one?" You can use rifle shots too. If you send a WOL packet to the specific IP address of the target machine AND the router knows which MAC address to send this IP address to, the machine should wake up. The problem with this is the ARP cache. ARP is Address Resolution P(robably protocol). The router keeps a handy table of what IP address goes to what MAC, and this varies as machines go on and off the subnet. This can lead to a powered-off machine falling out of the ARP cache a few minutes after it's turned off.
You can sidestep this issue with some routers (including mine, which is how I found this out) by defining a fixed DHCP address for the powered-off machine in the router's DHCP setup. The reason broadcast packets are used is that a broadcast packet is sent to all machines on the net, including the ones that are S5 and cannot recognize an IP address. Broadcast packets go to to all of them.
You may also have to re-flash your router's firmware to a different level to get WOL/broadcast/WOW/etc. to work. In some cases new firmware levels break it when it used to work. I have found that my dLink DIR-655 does in fact work Fine - but it has its own set of highly picky settings to get this set up.
Magic Packet Sender: You have to have a way to get your magic packet sent to the router to send out. This ought to be simple, but isn't. There are several free magic packet sender programs on the network for download. I've now tried six of them, with varying results. Many of them also include a magic packet listener program so you have some clue what's happening other than the machine just sitting there not powering on. The problem with this arrangement is that magic packet senders and listeners may or may not be getting through the OS to the NI in the local machine to be sent to the net, and even if they're not, the "send" may be echoed back to the listener and look like it was sent when it wasn't.
Windows does this last behavior. The various levels of Windows probably do it differently; I've only messed with it on W7. Often you have to run the senders/listeners as an administrator to get the program through the OS and down to the NI driver level. It's worth noting that on W7 there have to be special compatibility settings for some sender/receivers; I generalize this to maybe other Windows levels need special compatibility settings too. This last issue cost me a full day.
FreeBSD I'm still studying works fine. In FreeBSD you can check directly whether your NI driver supports WOL or not, and whether it's configured to work by using the ifconfig command in a shell screen as well as configure it if it's not set. See the documentation on ifconfig at http://www.freebsd.org/cgi/man.cgi?query=ifconfig&sektion=8 . The command you want is
Code:
ifconfig [your network driver here]

which responds with a lot of info on that interface. My interfaces were em0 for the intel card, and re0 for the Realtek 8111F.
You can also see if the magic packet is arriving at your FreeNAS/FreeBSD box with the tcpdump command; in fact, this was the last door to break through for me. It's a signal that the correct packets are getting through the underlying stack of conditions to your FreeNAS box. The command I used was
Code:
tcpdump -1 [your network driver here] -x port 9

with the "port 9" being what selects only the WOL packets. You might have to use another port depending on the WOL sender software and your other tower of bits. This shell command causes packets to be echoed to the console, and you can see directly if the magic packet arrived on the network wires at your FreeNAS machine.

Firewalls: Firewalls are *supposed* to hinder the promiscuous exchange of packets in the interest of public health. If your firewall doesn't let your OS or packet sender/listener see packets, you're not going to see them. Your firewall has to either be turned off (BAD idea!) or set to allow your sender to get magic packets out and your listener to receive them if they are there.
Frustration: there is a big problem in telling whether you're making any progress or not. The only external symptom of something not working is the target machine sitting there doing what it was always doing while powered off - nothing. There is no partial progress indicator to be had.
The only partial-progress indicators that can be used effectively are network packet sniffers like Wireshark to see if the packet makes it out of the sending program onto the wires, and tcpdump or equivalent on the target machine to see if the packet can be received at the target machine's network interface.

Another reason that WOL is so frustrating, and also peppered with "what's the big deal? mine just works" notes on the various inter-fora. Sometimes someone gets lucky, and the magic of the internet is that the lucky ones think they're normal. The upshot of this is that internet research is not as much help as you'd like to think. The blind-men-and-elephant principle is at work here - people for whom it just worked think "This is simple, what's the big deal?"

For anything to work, there has to be a magic packet on the subnet, and I could never know that was true until I started looking at individual packets. I downloaded Wireshark, which is a massively good packet sniffer, and free! Then I found that I had to learn to use Wireshark, which involved learning enough packet protocols and networking stuff to tell it what I wanted to find, then enough packet filtering to separate out the packets I might want to find, and then to set the filters to find what I actually wanted. A 100MB or 1GB link has a LOT of packets on it, the vast majority of which are the network machines blipping back and forth with "who's that? are you there? anybody else there? yep, I'm here. yep, I'm still here." This is the case with two computers, one net printer and one router on the subnet and NO internet traffic off site.

Wireshark took me about two days to get to know well enough to find magic packets. But I did, not least because I've been casually aware of networking and computer setup for nearly three decades.

My motherboard has a Realtek 8111F NI that is supported by FreeBSD and hence FreeNAS at my current level for setup for WOL magic packets, but anecdotal evidence is that this is chancy. I bought an Intel PRO/1000 GT NIC which is anecdotally works-every-time. In the end, I found that the works-every-time Intel PRO/1000 GT doesn't work (at least yet) but with the same tower-of-cards settings the RT8111f does. And I can now do WOL to my FreeNAS machine.

Getting this to work requires that you either be lucky, experienced, or stubborn and studious. Or perhaps some of all three.

You also need to be responsible. Heed the warnings. FreeNAS WOL is at least a modest misuse in the views of some older and wiser heads. If you do it and lose all your data, it's ain't FreeNAS' fault - it's yours.
 

Joannaco

Newbie
Joined
Apr 21, 2020
Messages
1
Hi! I was strugling with my NAS with FreeNAS soft, no way to boot it with WOL, I was using some diferent wakeonlan functions, but al last I found the problem, command line was:
> wakeonlan -i 192.168.xxx.001 11:22:33:44:55:66 but nothing happens.
After looking with wireshark I try with:
> wakeonlan -i 192.168.xxx.255 11:22:33:44:55:66 and EUREKA NAS boot OK.
Cheers.
My best whises.
 

elorimer

Member
Joined
Aug 26, 2019
Messages
157
Easier if you are really going in this direction is to get a wifi ac plug. Configure the motherboard to start on restoration of AC power. Shut down FreeNAS. When you want to wake it up, cycle the wifi plug and in a few minutes it will be ready.

Course, all the snapshotting, cloud sync and replicating features have to recover.
 
Top