Network Interfaces turn off on GUI Shutdown (*Critical issue* Many need help, see detailed post)

[Talha Ahmad]

**Parts List + Relevant command outputs at the end of post**

Problem:

My (and many others) network interface (mine=Intel embedded gigabyte LAN) turns off (LED Ethernet turn off), when the shutdown command from the webgui is executed. Because my network interface turns off when I shutdown freenas from the webgui, the magic packet for WOL doesn't get executed.


The Strange Part:

- All bios settings related to WOL (and PME) are already properly configured

- I know they are b/c WOL doesn't work **only** if I use the GUI to shutdown, however if I force shutdown using the power button right after bios post, the computer WILL wake on lan.

--> Because of this, I suspect freenas is the reason why this is occurring

Why WOL does not work **only** when FreeNAS shutdowns PC:

The LEDs on the Ethernet(network interface offline) seem only turn off when I execute the shutdown command from the WebGUI, however LED's do remain on when I force Shut down (pressing PW once) the PC right after BIOS Posts (before FreeNAS loads) and therefore WOL works.

Essentially FreeNAS is shutting down my network interface upon webGUI shutdown command which consequently mean WOL doesn't work.


Methods I (and several others) have tried in order to get the N.I to remain on:

1) Placing the network drivers, if_bge.ko, from the lasted release of NAS4Free onto the boot kernel directory and then setting up a turntable to load upon boot (if_bge_load="YES")

Doesn't Work B/C that driver is not for Intel N.I's

Reference (see HP Proliant N54L section) --> http://tinyurl.com/nfeb53v


2) Commenting out the line:
#/sbin/ifconfig -l | /usr/bin/xargs -n 1 -J % /sbin/ifconfig % down
in the /conf/base/etc/rc.shutdown file
Then rebooting twice to apply chances (b/c modified scripts are copied to the in-memory-filesystem)

Didn't work --> Not sure why?

Reference (see #16 post) --> https://bugs.pcbsd.org/issues/3764 (unsolved)


3) Adding the option for "wol_magic" in the network interface settings:

Reference (see #21 post) --> https://bugs.pcbsd.org/issues/3764 (unsolved)

Didn't work --> Not sure why?


4) Adding a sysctl variable for "dev.em.0.wake=1"

Reference (see #21 post) --> https://bugs.pcbsd.org/issues/3764 (unsolved)

Didn't work --> Not sure why?



Speaking on behalf of several users bug reports:

https://bugs.pcbsd.org/issues/3764
https://bugs.pcbsd.org/issues/4212

In both tickets, you will notice that the methods above have worked for a few, however the number of people still facing this issue far out way the few that have this issues resolved.

Please take a look at both tickets as they show this a deep analysis of the issue at hand, I do understand however that each person may have a different config problem.



Parts and commands outputs for my machine:

Parts:
Mobo: Gigabyte B-85
RAM: Crucial Ballistix 1600 DDR3 (non-ecc ram, please don't nag, I understand the consequences, this does not relate to the problem at hand)
CPU: Intel Pentium G3220 Haswell Dual-Core 3.0GHz
PSU: Corsair Builder Series CX 430 Watt
OS: FreeNAS 9.3 64-bit (updated to the lasted)

Several Diagnostic Command Outputs (after applying all the methods):

[root@NAS ~]# pciconf -l | grep ^em
em0@pci0:0:25:0: class=0x020000 card=0xe0001458 chip=0x153b8086 rev=0x05 hdr=0x00

[root@NAS ~]# ifconfig em0
em0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 150
0
options=40098<VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,VLAN_HWTSO>
ether 74:d4:35:81:eb:48
inet 192.168.0.100 netmask 0xffffff00 broadcast 192.168.0.255
nd6 options=9<PERFORMNUD,IFDISABLED>
media: Ethernet autoselect (100baseTX <full-duplex>)
status: active



Thank for reading, I appreciate the smallest bit of contribution that anyone can provide to help at least come a bit closer to solving the issue.

 

[Ericloewe]

Hold it, hold it, hold it...

You don't even have IPMI - and if you did, the OS would have nothing to do with the adapter being unavailable (especially because you'd probably have a dedicated NIC for IPMI).

What you have there is probably a BIOS bug. Make sure you don't have ethernet power saving options turned on and update the BIOS.

 

[Talha Ahmad]

Thx for the reply,

I edited that bit out now, my fault. I've learned that IMPI is a more sophisticated system then WOL and your right by saying that it would have had a higher chance of being supported on FreeNAS, irregardless my concern is solely with WOL.

Old implementations of WOL didn't rely on the OS. However it may be hard to believe but the new implementation requires OS support of WOL (a common misconception is that it doesn't).

Take a look at Intel's WOL page for reference regarding this matter:

"This early implementation did not require an OS that was aware of remote wake-up. APM provided BIOS-based power control. Newer computers feature Advanced Configuration and Power Interface (ACPI), which extends the APM concept to allow the OS to selectively control power by individual components"

http://www.intel.com/support/network/sb/cs-008459.htm


Also in regards to a potential BIOS bug, which can be true at any time, This board already has the latest version.

But if you take a look at the bug tickets in my post this problem seems to be occurring on multiple peoples mobos.

I've taken a look at all the power settings and have already disabled any modes that could potentially deal with turning the N.I off upon OS Shutdown.

 

[cyberjock]

I think you are confused, allow me to explain:

WOL needs 3 basic components to function properly:

1. The PSU must supply enough power even when not 100% on to keep the NIC alive.
2. The motherboard itself must support the ability to poweron by devices on the system. This is often enabled by a BIOS setting, if supported.
3. The NIC must support WOL along with the driver and OS that is being used.

Now for the clencher... WOL is typically considered an "advanced feature". Many manufacturers won't spend the time to make their NIC support WOL. Of those that do, many still won't spend the time to make the FreeBSD driver work because most FreeBSD installations are going to be on 24x7 and also going to use server-grade (shame on you for not doing this). If you are going with server-grade there's often alternative ways to power-on the box.

But you're now going to say "but what about when there's a loss of power at the datacenter!?" and the reality is that if you lose power at the datacenter it will also cause WOL to not function. At that point it still requires a user to intervene and start the box (unless you told the server to auto power-on on a loss of power, which I don't recommend).

Now, you've made a choice not to use server-grade parts, and FreeNAS works best with server-grade parts. So you are kind of outside of the design envelope, so I wouldn't be surprised if FreeNAS is totally incapable of enabling the WOL feature on your NIC no matter what you try. Even if you did have server-grade and it didn't work, there's an even better alternative to WOL. Powering on your box via IPMI. IPMI comes on and is fully capable of starting the server remotely, even on the other side of the world (yes, I've done this).

So in the bigger picture, companies have less of a reason to care about WOL and, while people might want to call this a "bug", I don't. WOL is something that I've seen not work despite allegedly being supported in Windows. So you can get upset about the fact that WOL is broken, but it's not going to matter.

Also you blaming FreeNAS is inappropriate because powering off before the OS had taken the hardware proves absolutely nothing at all.

Not to bash your attempt (you are welcome to give this a try and you are probably going to learn a few things even if you never get this to work), but the if_bge.ko is for Broadcom NICs and there was a 0% chance that by hacking in some driver for Broadcom NICs would affect your Intel NIC. This does make it sound like you are doing stuff with no clue how any of this works, so you're even less likely to get an outcome that is satisfying.

FreeNAS was designed to be powered on 100% of the time. Not surprisingly you are in a very small minority that don't want to follow this designed expectation. So you shouldn't be surprised that it's not working quite 100% the way you want with your hardware. If you really want WOL you should consider taking that desktop hardware and going back to Windows. Hate to say it, but that's the shortest way to use that hardware with an OS that was designed for it.

 

[jgreco]

There are so many interactions between things like green ethernet, crappy ethernet chipsets, and drivers that have to support those chipsets, that it's amazing anyone tries to make WOL work anymore.

If you want your NAS to restart after a power loss at the data center, perhaps you should set the NAS to restart after a power loss. If your BIOS doesn't support that, I'm going to go out on a limb and say the board is sufficiently craptacular that the WOL implementation probably sucks too.

 

[Talha Ahmad]

I think you are confused, allow me to explain:
WOL needs 3 basic components to function properly...............

First off Cyberjock I cannot thank you enough for the detailed and very informative post.
I should have made it clear in the first post, but I'm definitely confused, however I feel as tho that's one of the beauties of open-source, it lets me learn. I've been spending a lot of time understanding and reading the user guide, so I'm getting smarter every day.

I really did need to understand why theirs wasn't support for my on-board NIC WOL functionality, and your justification does seem fair as well as logistics of it all. :(

I didn't know that IMPI works completely differently then WOL, thx for that.

To be honest, I'm less concern about how FreeNAS doesn't support my WOL but why my N.I(LEDs=OFF) turn off only when I shutdown using FreeNAS but the LED's remain on if I showdown manually (using PW after BIOS is done posting but before FreeNAS loads).


Why doesn't powering down my machine before freeNAS loads and noticing WOL works, enough to prove that FreeNAS is the cause? (i meant blame in the lightest possible way).

Didn't know that the "if_bge.ko driver" was only for Broadcom NICs, nowhere I read said that explicitly, thx for letting me know.

Honestly you right tho, switching OS's which make all my problems go away, but I've invested so much time (ZFS HD's) and found this stuff quite enjoyable to learn.

Hopefully Ill figure something out to compensate (like using a networked controlled power switch). At the end of the day I understand the reality of the situations and appreciate your help. :)

 

[jkh]

To be honest, I'm less concern about how FreeNAS doesn't support my WOL but why my N.I(LEDs=OFF) turn off only when I shutdown using FreeNAS but the LED's remain on if I showdown manually (using PW after BIOS is done posting but before FreeNAS loads).

Because FreeBSD is obviously going to a little extra trouble, at shutdown-to-poweroff time, to enumerate every device attached to it and say "Hey, you - we're turning out the lights! Turn yourself off!" and they do.

Maybe in the WOL case, where FreeBSD is really clear that it needs to do something a bit different and both the driver, card, and configuration settings both tell and allow it to do so, it turns off the NIC a little less aggressively into some WOL mode - one would have to look at the source code to see (that's a hint: The beauty of open source means that anyone who is genuinely curious enough should do so). Evidently back in the 9.1.x days, FreeBSD even did that, but then something changed and that ability went away. Who knows, maybe the support was just too spotty and non-deterministic enough to work properly. Maybe FreeBSD itself didn't come up properly in all of the wake cases, or having a NIC be WOL-aware caused other things to stay awake and eat power - again, this is all speculation and without looking at the code (and it's history) it will remain speculation.

Here's what we know for sure to be true:

1. FreeNAS has never explicitly supported this. If it had, there would have been a WOL enable/disable option in the Interfaces UI. The fact that it worked at all before seems to be largely coincidental / accidental. This is further supported by the fact that:

2. FreeNAS has never even documented this feature as "optionally" supported.

It just seems to have come along for the ride with FreeBSD and, just checking the interface flags for FreeBSD with more modern drivers like igb(4) and cxgbe(4), one sees that WOL_UCAST,WOL_MCAST,WOL_MAGIC aren't even supported by them. Just looking at hardware we support at iXsystems, only the older Intel em(4) driver seems to support WOL, which suggests it's pretty far behind the power curve as FreeBSD features go.

In any case, we're rapidly moving towards a model where we want to keep features we support working, and that means checklists and QA. That is a good thing, for obvious reasons, but that also means that any features we do NOT explicitly support may drop away at any time and we want to get to a place where FreeNAS's exact feature-footprint is documented and committed to. I don't think it's likely that WOL is going to make that list.

 

[Talha Ahmad]

There are so many interactions between things like green ethernet, crappy ethernet chipsets, and drivers that have to support those chipsets, that it's amazing anyone tries to make WOL work anymore.

If you want your NAS to restart after a power loss at the data center, perhaps you should set the NAS to restart after a power loss. If your BIOS doesn't support that, I'm going to go out on a limb and say the board is sufficiently craptacular that the WOL implementation probably sucks too.

Yup I think its too "hardware intensive" IMO.

Good News tho ---> I think I found a way to get this to work by enabling "Legacy OS Wakeup Support" --> Which doesn't rely on OS, in theory it should work.

The problem is that my"Intel Boot Agent" doesn't have that option b/c its out of date, and I'm not sure how to update it with the Linux version of their Flash update Utility(PREBOOT) but ill do some outside reading and try to figure out how to update it. I don't wanna discuss that here b/c that would be outside the topic of this forum.

Reference to the update utility for any one else watching this fourm "PREBOOT" --->
http://www.intel.com/support/network/sb/cs-008459.htm

Thxs again guys.