FreeNAS WOL: The Saga Continues...

[R.G.]

I have chased WOL on my FreeNAS server into another brick wall. Along the way, I debugged through the layers I documented in http://forums.freenas.org/index.php...it-works-why-it-doesnt-and-frustration.18354/.

For others trying to chase this down, the two commands you'll need to find out if your FreeNAS is set up to receive WOL and if the packet is getting there are:

ifconfig [name of your NIC driver here]
and
tcpdump -i (name of your NIC driver here) -v -x port (7 or 9)

I have an Intel PRO/1000 GT PCI bus NIC inserted to sidestep the issues with the Realtek 8111F onboard NI on my ASUS m5A97 R2 motherboard. Running these on my system in the shell and sending a WOL packet from another machine gets the following:

Code:

[root@freenas ~]# ifconfig em0                                                                                                     
em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500                                                         
        options=209b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC>                                                 
        ether 00:1b:21:48:26:b3                                                                                                   
        inet 192.168.0.6 netmask 0xffffff80 broadcast 192.168.0.127                                                               
        nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>                                                                       
        media: Ethernet autoselect (1000baseT <full-duplex>)                                                                       
        status: active                                                                                                             
[root@freenas ~]# tcpdump -i em0 -x port 9                                                                                         
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode                                                         
listening on em0, link-type EN10MB (Ethernet), capture size 65535 bytes                                                           
11:20:35.056823 IP 192.168.0.3.62834 > 255.255.255.255.discard: UDP, length 102                                                   
        0x0000:  4500 0082 57db 0000 8011 21e5 c0a8 0003                                                                           
        0x0010:  ffff ffff f572 0009 006e c886 ffff ffff                                                                           
        0x0020:  ffff 001b 2148 26b3 001b 2148 26b3 001b                                                                           
        0x0030:  2148 26b3 001b 2148 26b3 001b 2148 26b3                                                                           
        0x0040:  001b 2148 26b3 001b 2148 26b3 001b 2148                                                                           
        0x0050:  26b3 001b 2148 26b3 001b 2148 26b3 001b                                                                           
        0x0060:  2148 26b3 001b 2148 26b3 001b 2148 26b3                                                                           
        0x0070:  001b 2148 26b3 001b 2148 26b3 001b 2148                                                                           
        0x0080:  26b3                                                                                                             
^C                                                                                                                                 
1 packet captured                                                                                                                 
374 packets received by filter                                                                                                     
0 packets dropped by kernel                                                                                                       
[root@freenas ~]#    

So - do I interpret this correctly? WOL with magic packet receipt is set up in the em0 driver, so it should receive the packet??
And the magic packet I see has the magic packet format with six bytes of FF, followed by the MAC address sixteen times.

Does this indicate that the MP is getting to the machine correctly, it's just not waking on the packet?
[EDIT: I realized I'd pasted the wrong saved output from the ifconfig. I've corrected that and I think it does show WOL_MAGIC enabled.]

 

[R.G.]

... and the saga is nearly complete.

I got my first WOL by reverting to the RT8111F interface on the motherboard, with the same settings I had been using unsuccessfully with the (supposedly) works-every-time Intel PRO/1000.

 

[cyberjock]

And you created a separate thread on WOL despite there already being a WOL thread you've been using because???

Seems like you'd have been better off posting this info there and not in a new thread.

 

[R.G.]

Thank you for your concern. I think it's great that you would want to help me in this way, advising me on how to get more information back on my questions by narrowing the number of threads. It's a fine point, I guess. And I'm guessing that you had no direct information to add, so you tried to help in a less direct way. I appreciate that.

I did this because the information seemed to be useful to others being highlighted separately.

I made this decision not least based on there being no response from others and that made me think that the information was useful as an isolated statement that was easier to find, given that there were no comments on the topic. Information is easily buried in forums.

The issue of WOL appears over and over here, in many variants, this in spite of the repeated comments that FreeNAS is a pro-level tool, intended to be left on 24/7, and the implication that the issue of waking it ad hoc is a beginner/amateur's concern. That may be. To me it's a tool to get good, reliable data storage to meet my needs. I think others may see it that way as well. I personally believe that the more people who adopt FreeNAS, the better it is for FreeNAS. As WOL seems to be a topic of interest to a number of people, not just me, more information on how to get it running is useful, and in FreeNAS' best interest, in my opinion.

It is however complex to get this running, and the documentation is scattered. I read and searched extensively on the topic before ever posting here even once. I think it was not unreasonable that someone else would follow a similar path to mine, and want to know the size of the problem, as well as the fact that even changing NICs could make the problem magically work or not. I was trying to make it easier for that person.

In my judgement, I was not doing this for my benefit, so I would be better off, at all; rather that it might help someone else. I reasoned that an excess thread was very nearly the same number of bits to be stored as the same message appended to another thread and that the benefit to someone else in being easier to find outweighed the costs of the extra complexity of the threads and extra storage of the overhead of a new title and pointer-chain overhead. In fact, your request for me to explain myself and my reply to your question have now doubled the number of posts in this second thread on the topic.

I do hope I have not offended you by highlighting the information in this manner. If you really think it's necessary, you have my permission to append this thread to the previous thread/title in the interest of general forum parsimony. Again, thank you for helping me be better off.

 

[cyberjock]

You are correct that I had nothing to add. As I've said in the other thread WOL is an ill-advised feature because FreeNAS expects your server to be up 24x7. You potentially break many things by choosing to do shutdowns and power-ups.

You didn't offend me. There's so many WOL threads I'm convinced that WOL support would be working for far more people if it wasn't spread out over the forums. All this information is lost when you start splitting up threads, which is why I made the comment I did.

 

[R.G.]

I'm good with that. Like any powerful tool, WOL has the potential for harm if used thoughtlessly. It shares that with things like ZFS and RAID technology in general. There are different ways to look at things. No harm, no foul.

However, I don't think WOL as a topic will go away. The genie is out and the bottle broken.

That being the case, it's good for the computing community in general and FreeNAS in particular to make the information on whether and how to use it fairly widespread.

It would make YOUR job easier if for every new WOL question, you could simply say "Look at this link" and have that link encapsulate the information. After a while, people would find your pointer and you might not eve have to write that. As it is, you're a Doberman besieged by Chihuahuas.

The hypothetical repository of info on WOL could also include the necessary warnings about FreeNAS being intended for 24/7 operation and WOL being a misuse, etc. Very efficient, I think. In many ways, a parallel of the suggestion to read the guide, right?

I would volunteer to write this, but it's much like the blind leading the blind. Even with broad experience, the detailed nature of the topic took me a couple of weeks to run down and kill, and then only for one case. Much better if an initiate with a rich background gathered up the pieces and did such a guide. Even soliciting experiences would be good as it would gather the sins up into one bucket easier to watch.

So - since there is a creek if not a river of WOL questions, how about making a clean-ish place to put them, and possibly a written up guide of the considerations, including why one would NOT choose to WOL?

 

[cyberjock]

That being the case, it's good for the computing community in general and FreeNAS in particular to make the information on whether and how to use it fairly widespread.

That's not necessarily true. How many users will ignore the forum warnings, ignore the manual warnings, ignore warnings in the IRC, and then when they lose data blame FreeNAS? I'll tell you.. too many. Unfortunately, these people are often very vocal because they felt that the warnings didn't apply because of their own ignorance. But, it still hurts FreeNAS' image to have people like that around.

It would make YOUR job easier if for every new WOL question, you could simply say "Look at this link" and have that link encapsulate the information. After a while, people would find your pointer and you might not eve have to write that. As it is, you're a Doberman besieged by Chihuahuas.

The hypothetical repository of info on WOL could also include the necessary warnings about FreeNAS being intended for 24/7 operation and WOL being a misuse, etc. Very efficient, I think. In many ways, a parallel of the suggestion to read the guide, right?

Sure, and see my comments above.

I would volunteer to write this, but it's much like the blind leading the blind. Even with broad experience, the detailed nature of the topic took me a couple of weeks to run down and kill, and then only for one case. Much better if an initiate with a rich background gathered up the pieces and did such a guide. Even soliciting experiences would be good as it would gather the sins up into one bucket easier to watch.

So - since there is a creek if not a river of WOL questions, how about making a clean-ish place to put them, and possibly a written up guide of the considerations, including why one would NOT choose to WOL?

You want a secret? I've gotten WOL working on my "spare" system with FreeNAS. But, you know why I didn't publish a guide? I didn't want to give even an iota of a hint that it is recommended or even preferred.

Believe it or not, there are many questions asked that are answered with "if you have to ask how to do X, then you clearly shouldn't be doing it." There are many questions here that I deliberately do not answer because I am 100% confident that the user has no grasp of how dangerous it is. Clear example: mention that you want to or have virtualized FreeNAS in a thread and all the experienced forum posters will immediately ignore you from that point on.

There are some things that just don't need to be discussed in the forums. Either you have the experience, knowledge, and wisdom to know what you are doing is stupid, or you probably shouldn't be doing it.

 

[Michael Wulff Nielsen]

I would love to know what nic is in that spare-system. I bought an Intel pro 1000 gt because somebody had some luck with it, but no luck for me. I am quite prepared to go through a few nics to find a solution here.

 

[cyberjock]

I would love to know what nic is in that spare-system. I bought an Intel pro 1000 gt because somebody had some luck with it, but no luck for me. I am quite prepared to go through a few nics to find a solution here.

Ug. Lemme see if I can find it. I know it was an Intel, i'm just not sure which card or what model it was.

 

[R.G.]

I would love to know what nic is in that spare-system. I bought an Intel pro 1000 gt because somebody had some luck with it, but no luck for me. I am quite prepared to go through a few nics to find a solution here.

I'd like to know as well. I bought my PRO/1000GT largely based on reading YOUR posts on WOL and the preceding ones which said the Intel PRO/1000 GT worked first time, everytime.

I can tell you that the PWLA8391GT did NOT work for me, and that removing it and flipping back to the Realtek 8111F is what made my system work, with the same BIOS settings and other hardware.

I hypothesize that this PCI bus card and the PCI bus on the ASUS M5A97 R2.0 have some undiscovered incompatibility in the signal on the PCI bus, even though they are nominally advertised to work with the right levels of PCI bus definitions. I have not delved into the actual signals on the bus to verify this (there's dust all over the logic analyzer... I'm no stranger to watching for pulses on buses, but it takes a large motivation to get me to do it. )

 

[jgreco]

Add-in cards may not magically work with WOL. The mainboard port is much more likely to. This has to do with things like whether or not standby power is being made available to the add-in cards, whether there are BIOS options like "Power On via PCIe", etc. Add-in cards are a great way to get a high performance network interface for FreeNAS data traffic, but are less likely to be friendly to WOL.

 

[R.G.]

Add-in cards may not magically work with WOL. The mainboard port is much more likely to. This has to do with things like whether or not standby power is being made available to the add-in cards, whether there are BIOS options like "Power On via PCIe", etc. Add-in cards are a great way to get a high performance network interface for FreeNAS data traffic, but are less likely to be friendly to WOL.

Thank you for taking the time to answer. I respect your opinions from the other posts from you I've read in my research.

Yes, I think you're correct. Synopsizing from my first WOL post http://forums.freenas.org/index.php?threads/wake-on-lan-wol-why-it-works-why-it-doesnt-and-frustration.18354/ , all of the following have to be correct:
- Network connection must be wired, not wireless
- Power supply must supply enough +5V Standby power to the NI or NIC
- Motherboard must support Wake On Lan from either PCI bus or onboard NI, in several flavors.
- BIOS: the motherboard's BIOS has to support WOL with proper settings
- OS: the operating system has to let you WOL by enabling setting drivers properly
- NI drivers have to be capable of setting the NI for WOL
- Router has to route the magic packet to the target machine. Some don't.
- You have to use the right Magic Packet Sender. Some say they work but don't.
- Your firewall must allow the Magic Packet out of the sending machine and into the target.
As I said, I took the collected advice of this and other forums on the RT8111F being flakey and the Intel PRO/1000 working rock-solid, and found that for me, the reverse was true, at least for WOL.

It reminds me of a computer game, where you have to complete many seemingly-unrelated tasks to get to some score or goal.

But I do expect the other anecdotal evidence to be right - the Intel card is probably a better choice for reliable high speed network operations for FreeNAS.

 

[jgreco]

Oh, never mind. Your list from that thread is much more comprehensive. Sorry, I've been working lots of hours for a client and I miss so much stuff that goes on here these days, I always seem to be missing out on the best threads.

 

[R.G.]

I was serious - thanks for the reply. It's dead accurate, and I only accidentally ran into the data first.

I've been in the line of fire with clients before, and it can be all consuming. Hang in there.

As an aside, I update the WOL Frustration post with the latest info, including the generalization of C.J.'s warnings and my latest experience with RT8111F and Intel.

 

[Michael Wulff Nielsen]

I'd like to know as well. I bought my PRO/1000GT largely based on reading YOUR posts on WOL and the preceding ones which said the Intel PRO/1000 GT worked first time, everytime.

I'm really sorry you threw money out the window, but if it helps, so did I. I actually read a bunch of the freebsd driver code and it looked like the driver had wake on lan support, but apparently not for that card or that card in a pci-e configuration.

I am a bit disappointed that the intel nics in my motherboard aren't supported, since it's a c216 chipset motherboard like a lot of the supermicros being used around here.

 

[R.G.]

Here's another one to add - you have the PCI-e configuration. I have the PCI (old parallel bus). Apparently neither of them are supported, or at least they're not supported in your and my unique house-of-cards configuration.

And I'm fine - I'll use the card one way or another. There are seven PCs within arm's distance here in the "home computing hub" :) and one of them will need a card at one point or another. It won't be wasted, never fear. Sorry to hear about yours with your new info on the driver code.

This makes me wonder indeed if there is some issue with the chip set support, as you may have ferreted out, or if it's an issue with the PCI/PCIe bus support on ASUS motherboards. Now I'm more curious than ever about those posts saying "just use the Intel PRO and it works!"

 

[ser_rhaegar]

It may cost more money but if you're dead set on turning it on and off regularly you would save time and effort to just get a motherboard with IPMI. If you're looking to script stuff, an IPMI with SSH or telnet access would be easy to script as well.

 

[cyberjock]

That's the same advice I keep giving in other WOL threads.. they don't want to hear it. The WOL word must be what they want and not necessarily the remote power-on function. :P

 

[R.G.]

It may cost more money but if you're dead set on turning it on and off regularly you would save time and effort to just get a motherboard with IPMI. If you're looking to script stuff, an IPMI with SSH or telnet access would be easy to script as well.

That's the same advice I keep giving in other WOL threads.. they don't want to hear it. The WOL word must be what they want and not necessarily the remote power-on function.

Just as either an angel's advocate or devil's advocate, don't know which for sure, when I first got into ZFS, back when Open Solaris was a possibility, I actually designed a remote power on button using a net enabled I/O adapter, which served as a remote control power on button presser. IPMI is great; I'd use it if it was more accessible and affordable. However, after a several-weeks-chase, I can now remotely power on my server, and I suspect that this small part of IPMI is enough for most people. If I had found my other post listing the string of things to check off to get it to work, I'd have had it running much sooner than I did. That's why I wrote that down.

Demeaning the idea of WOL as an inexpensive means to an end is not likely help lower the tide of incoming newbies who think "WOL - Kewl! I can do that..." I'm pretty sure that remote power on *is* what most of us are after. WOL is one way to do that. There may be even better ones, but they are hard to find.

I think that reasoned write up detailing the pitfalls of using WOL that's more detailed than "Here be dragons" and the relative advantages of IPMI, including some comparisons of the costs in money and time would be more effective at stemming the perceived tide of WOL fanatics. I personally would have loved to find that. It might even have convinced me to make the nominally "right" decision. As it is, I kept banging on it until I'd uncovered at least one path to do what I want. Pretty much, if one path is better in terms of cost, time, and danger, and the differences between paths are presented clearly, people will choose the cheaper, shorter, less dangerous path.

I used to manage both hardware and software design groups. I always found it was more effective and longer lasting to show people why doing the right thing was better than it was to tell them how silly doing the wrong thing is. But then, that may just be what worked better for me in an isolated circumstance. The wild, wild web may be different. :)

And so, @ser_rhaegar, tell me about the differences with IPMI, how much time and cost it would have saved me. I can still be taught.

 

[ser_rhaegar]

And so, @ser_rhaegar, tell me about the differences with IPMI, how much time and cost it would have saved me. I can still be taught.

Well I never said anything about saving money. I specifically said it would be more. If you bought it up front, the price increase on a motherboard with IPMI is marginal though. After the fact, replacing a motherboard is pricey.

Time wise... you would have saved:

However, after a several-weeks-chase, I can now remotely power on my server

Scripting a telnet or SSH login and single command to power up a system takes a few minutes. Even if you never used Python, Ruby or Perl you can google it and come up with many examples of SSH/telnet.

Difference wise you would have had remote system monitoring, IP KVM (most valuable, IMO), remote power management and probably email alerts depending on the IPMI.