# WOL worked for a year....and suddenly not any more

## Rinswind

Hi,

I was happily using Wake On Lan for about a year to boot my home box from work. Than suddenly it stopped working. I believe the last significant change I made was to upgrade the kernel to 2.6.28-gentoo-r5. Unfortunately I was on a 10 day home leave and detected the WOL problem only when I went back to work and at that point I did not remember everything I did. Also I don't keep the old kernel around any more. This is a windows dual-boot box and WOL works when I shutdown from windows but not when I shutdown from gentoo. The strangest thing is that after each boot ethtool reports that WOL is enabled. Even stranger is the fact that I did not have "ethtool -s eth0 wol g" in  /etc/conf.d/local.stop and WOL was working. Now I added it trying to fix the problem but it does not help. So frustrating. Here are some more details:

Output from "lspci -v"

04:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 01)

	Subsystem: Giga-byte Technology Device e000

	Flags: bus master, fast devsel, latency 0, IRQ 16

	I/O ports at c000 [size=256]

	Memory at f9000000 (64-bit, non-prefetchable) [size=4K]

	[virtual] Expansion ROM at 80000000 [disabled] [size=128K]

	Capabilities: [40] Power Management version 2

	Capabilities: [48] Vital Product Data <?>

	Capabilities: [50] Message Signalled Interrupts: Mask- 64bit+ Count=1/2 Enable-

	Capabilities: [60] Express Endpoint, MSI 00

	Capabilities: [84] Vendor Specific Information <?>

	Capabilities: [100] Advanced Error Reporting

		UESta:	DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSVoil-

		UEMsk:	DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSVoil-

		UESvrt:	DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSVoil-

		CESta:	RxErr- BadTLP- BadDLLP- Rollover- Timeout+ NonFatalErr-

		CESta:	RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-

		AERCap:	First Error Pointer: 00, GenCap- CGenEn- ChkCap- ChkEn-

	Capabilities: [12c] Virtual Channel <?>

	Capabilities: [148] Device Serial Number 68-81-ec-10-00-00-00-00

	Capabilities: [154] Power Budgeting <?>

	Kernel driver in use: r8169

	Kernel modules: r8169

Output from "ethtool eth0"

Settings for eth0:

	Supported ports: [ TP MII ]

	Supported link modes:   10baseT/Half 10baseT/Full 

	                        100baseT/Half 100baseT/Full 

	                        1000baseT/Half 1000baseT/Full 

	Supports auto-negotiation: Yes

	Advertised link modes:  10baseT/Half 10baseT/Full 

	                        100baseT/Half 100baseT/Full 

	                        1000baseT/Half 1000baseT/Full 

	Advertised auto-negotiation: Yes

	Speed: 100Mb/s

	Duplex: Full

	Port: MII

	PHYAD: 0

	Transceiver: internal

	Auto-negotiation: on

	Supports Wake-on: pumbg

	Wake-on: g

	Current message level: 0x00000033 (51)

	Link detected: yes

My /etc/conf.d/local.stop

# /etc/conf.d/local.stop

# Enable WOL upon shutdown

ethtool -s eth0 wol

And mu /etc/conf.d/rc contains:

RC_DOWN_INTERFACE="no"

----------

## BeteNoire

/etc/conf.d/rc isn't valid file anymore in baselayout 2 and openrc. It was moved to /etc/rc.conf, but default file does not provide option for wol.

Wol isn't working for me anymore too.

----------

## Rinswind

The only info on WOL I could find at openrc was this:

https://forums.gentoo.org/viewtopic.php?p=5753270#5753270

I am not familiar enough with either openrc or shell scripting to tease out what has to be done to keep the ethernet card up. Somehow I don't feel calling "net.eth0 start" from "local.stop" is the answer  :Razz: 

----------

## Rinswind

The remark about baselayout-2 made me check my baselayout and it is in fact 1.12.11.1. I was just about to migrate to baselayout-2 when I noticed that both baselayout-2 and openrc are marked as unstable. So...migrate or not-migrate that is the question!

----------

## Ivar_Y

I'm using sys-apps/baselayout-2.0.1 and sys-apps/openrc-0.4.3-r3.  Based on the /usr/share/doc/openrc/net.example, I added "ethtool -s eth0 wol g" to /etc/conf.d/net on the computer to be woken and a wakeonlan command from another computer worked.

----------

## Rinswind

Today I upgraded to baselayout-2.0.1 and openrc-0.4.3-r3 as well. Here is my /etc/conf.d/net

config_eth0="dhcp"

# Enable WOL

ifdown_eth0="no"

postdown() {

  # Enable WOL on eth0

  ethtool -s eth0 wol g

  # Return 0 always

  return 0

}

WOL still not working!  :Sad: 

BTW I am WOL-ing from a WRT54-GL router via the web interface of DD-WRT.

----------

## FluffyArmada

Just wanted to say I'm having the exact same problem. I don't think it's Gentoo specific either. I have the same issue in Debian *and* Fedora. Currently, I'm running a fresh install of Gentoo on the machine I want to wake-up... I always install Gentoo when stuff is broken everywhere else.  :Wink: 

----------

## FluffyArmada

I would also like to mention that I'm also using the same NIC, onboard an MSI motherboard, using the same kernel module. If it helps. :\

I'm at a total loss here.

----------

## Rinswind

BTW I have the habit of building a heavily customized kernel - only the stuff needed for my hardware. Also make it as modular as possible - almost only the stuff to mount the root partition is built in. My impression so far is that WOL is not supported by the kernel directly. But than again if anyone knows some critical twitch in the kernel config that breaks it now is the time to come forth and tell what it is!  :Smile: 

----------

## FluffyArmada

As far as my kernel goes, I'm actually running the kernel that pops out when you use genkernel with the --lvm2 option. 

2.6.29-gentoo-r5 . 

I didn't really feel like figuring out how to properly make my own initrd with lvm support...

So, if it helps to know what I've got basically every module *EVER* built, then I've at least made it known.  :Smile: 

edit: x86_64, btw

----------

## BeteNoire

Upgrade of sys-apps/openrc from 0.4.x to 0.5.x makes my WOL work again.

Is it a miracle?

Wow, it required more than 4 months to get my functionality back. Flawless.

----------

## FluffyArmada

Oh, gosh. I think a kernel update fixed this for me a long time ago. I started using an older kernel and it worked just fine. Then I waited for the next version to become stable and compiled it... WOL has been working for me ever since.  :Smile: 

----------

## mani001

Hi there,

I run into the same proble some months ago...and didn't solve the issue yet   :Sad: 

I'm using x86_64 stable (kernel 2.6.31). What kernel are you using FluffyArmada?

----------

## FluffyArmada

I'm not sure what version of the kernel I'm running, but it's probably at least about 6 months old. I can't get on the box right now, because I'm 2 hours away from it and its ethernet cable is unplugged. I can check when I go home next weekend. (I was using the cable for something else, and I forgot to plug it back in. Silly me.) But, I'm pretty sure what I did was install the version of the kernel that was stable before 2.6.29-gentoo-r5, and that fixed the problem for me. I think that, at least when I was having the problem, it was some issue with a kernel module or something. I kinda stopped caring to find out exactly what the problem was once downgrading the kernel "fixed" it. 

I'll see if I can call someone and have them plug it back in for me, but right now it seems like nobody's home. 

Also, I used the genkernel package instead of the normal kernel package, so there might be something that got built by that, that didn't get built when I just manually configured the kernel. (although I did check pretty thoroughly to make sure there wasn't anything I was forgetting to build, so I think it was an issue with the specific version of the kernel and not something I was doing wrong; BUT, it definitely isn't below me to mess up my kernel xD)

So, if you're trying to get yours working, you might give genkernel a try and see if it works. That might make it easier to decide whether its a matter of missing drivers or kernel bits or a kernel version specific thing.

----------

## mani001

sorry for the delay...and thanks for your reply  :Smile: 

We are talking about the kernel of the remote machine, not that of the local machine, right? Thing is: it stopped working without me changing the kernel of the remote machine, though I have changed the kernel of the local one several times since then...however it seems unlikely that a kernel issue results in the magic packet not being sent correctly (doesn't it?). I also tried sending the magic packet from webservices, like 

http://www.dslreports.com/wakeup

, but no way. So...I'm running out of ideas   :Sad: 

----------

## FluffyArmada

I guess it was a kernel issue in my case, because I can't imagine anything else having been the issue. After I installed the new kernel and it worked, I tried booting the old kernel and testing it just in case something else changed. The new (the older version actually) kernel worked, but the old (the newer version) kernel still wasn't working. 

But I had to do a lot of searching around to find a solution, and one thing that was often mentioned as a problem was your init scripts turning off the device when the computer was shut-down. I still can't get on the machine, but you might try checking the scripts that control the up-ing and down-ing of your network devices and see if they're turning it off whenever you shutdown. Maybe try shutting down with the option that lets you shutdown without going through init, and if WOL works after that, I'd guess something is disabling the WOL on shutdown. 

Otherwise, I'm not sure what else could be making it not work. I assume you've already checked your BIOS options, but just in case you didn't, I thought I'd mention it. 

Is your NIC on-board, or is it a PCI card? I don't really know if it makes a difference or not, but it might be useful. 

And yes, I'm talking about the kernel on the machine I wanted to wake up.

----------

