Hi, I find myself in a position that seemingly many others are facing: I can't get wake on lan (wol) to work. I think my bios and motherboard are not the problem (the bios gives me an option to power-on by pme event, the nic is onboard), and so I presume it is a linux issue.

I have read and tried many solutions, e.g ...

http://www.linuxquestions.org/questi...thtool-708836/
http://www.linuxquestions.org/questi...er-off-719354/
http://www.linuxquestions.org/questi...l-work-712283/

... and have had no luck.

I presume my problem somehow relates to the state the system goes into when I shut down. For example, when I "shutdown -h now", the computer simply shuts off, even though what I need is for some things to still run, specifically the NIC (e.g. the led should stay on, and it never does). Is "shutdown -h now" wrong? I have read about others using it with wol.

So far, I have not even looked into trying to configure acpi and setting up things like sleep, suspend, hibernate, etc. It seems to me that they might be useful things to consider. It is just that I haven't seen much discussion about them in the context of this problem. does anyone have any experience with acpi and how it interacts with this wol problem?

thanks for any advice.
-mark

Hi,

All 3 of those links have the same basic solution which is to execute (as root)

ethtool eth0 -s wol g

sometime after the computer boots. Those posts suggest different locations, but it doesn't really matter where it goes, just that it does get executed (sometime after the ethernet driver loads). I do it in /etc/rc.local, which works fine.

Before further search or trying anything complicated I suggest the following:

su to root (or use sudo with the following commands).

Start by running ethtool eth0 and look for the line starting with Wake-on:. It probably says "d" for "disabled."

Then run ethtool eth0 -s wol g. Check what happens by running

ethtool eth0

again. The Wake-on: line should have changed to "g". Now power off and try to wake-on-lan. If this works, you just need to add the magic line somewhere where it will get executed each time you boot. (Again, I put it in /etc/rc.local.) If this doesn't work even with the Wake-on line showing "g" before powerdown, you probably need to do a search for your specific hardware. Or post back and let us know what the output of

lspci

is.

Hi - Thanks for your help. I think the ethtool trick is not helping. As per instructions, I have a file /etc/init.d/wakeonlanconfig which has

#!/bin/bash
ethtool -s eth0 wol g
exit

and when I do "ethtool eth0", I get (amongst other things)
Supports Wake-on: pg
Wake-on: g

Yet, when I powerdown the led for the nic goes off and wol does not work. I use "wakeonlan -i 192.168.0.2 -p 8 00:16:E6D:B9D" from another computer on my lan (the IP and MAC are correct according to ifconfig on 192.168.0.2, i.e.
$ ifconfig
eth0 Link encap:Ethernet HWaddr 00:16:e6:dd:b9:dd
inet addr:192.168.0.2 Bcast:192.168.0.255 Mask:255.255.255.0
)

So maybe this is something specific to my hardware. I listed the output of lspci below. I have two other types of machines that I can experiment with to see if I can get wol working. That might be a useful exercise to narrow down the possibilities.

thanks for your help,
Mark






00:00.0 Host bridge: Intel Corporation 82P965/G965 Memory Controller Hub (rev 02)
00:01.0 PCI bridge: Intel Corporation 82P965/G965 PCI Express Root Port (rev 02)
00:1a.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #4 (rev 02)
00:1a.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #5 (rev 02)
00:1a.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #2 (rev 02)
00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 02)
00:1c.0 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 1 (rev 02)
00:1c.4 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 5 (rev 02)
00:1c.5 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 6 (rev 02)
00:1d.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #1 (rev 02)
00:1d.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #2 (rev 02)
00:1d.2 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #3 (rev 02)
00:1d.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #1 (rev 02)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev f2)
00:1f.0 ISA bridge: Intel Corporation 82801HB/HR (ICH8/R) LPC Interface Controller (rev 02)
00:1f.2 IDE interface: Intel Corporation 82801H (ICH8 Family) 4 port SATA IDE Controller (rev 02)
00:1f.3 SMBus: Intel Corporation 82801H (ICH8 Family) SMBus Controller (rev 02)
00:1f.5 IDE interface: Intel Corporation 82801H (ICH8 Family) 2 port SATA IDE Controller (rev 02)
01:00.0 VGA compatible controller: nVidia Corporation G72 [GeForce 7300 LE] (rev a1)
03:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8056 PCI-E Gigabit Ethernet Controller (rev 14)
04:00.0 SATA controller: JMicron Technologies, Inc. JMicron 20360/20363 AHCI Controller (rev 02)
04:00.1 IDE interface: JMicron Technologies, Inc. JMicron 20360/20363 AHCI Controller (rev 02)
05:06.0 FireWire (IEEE 1394): Texas Instruments TSB43AB23 IEEE-1394a-2000 Controller (PHY/Link)

and the verbose listing for ethernet is
03:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8056 PCI-E Gigabit Ethernet Controller (rev 14)
Subsystem: Giga-byte Technology Unknown device e000
Flags: bus master, fast devsel, latency 0, IRQ 2299
Memory at f8000000 (64-bit, non-prefetchable) [size=16K]
I/O ports at 9000 [size=256]
[virtual] Expansion ROM at f9300000 [disabled] [size=128K]
Capabilities: <access denied>

ps... in my previous post, those smileys in the mac address where a pure accident, caused by the colon and D occurring next to one another.
-m

"Code tags" will prevent that. See the comment/link in my signature for more info.

From what you've posted, I am guessing the problem is something hardware specific. When I get some more time I'll take a deeper look at it.

wakeonlan uses UDP broadcast. etherwake generates a raw ethernet packet. you might test with each of these to see if the card's implementation is a good one.

grepmasterd's post caused me to go back and re-read the ethtool man page a little more closely. (It's been almost 2 years since I've seriously looked at this -- back when I was getting it to work for me.) The g Wake-on-Lan option wakes in response to a "magic packet" such as ether-wake sends. That is what I use for WOL. So if your software is sending UDP packets (or anything other than "magic packets") then I don't think you'll get a response with just the g option. If you have another Linux system on your LAN (or any other computer that can run ether-wake) I suggest you try that program. (My memory has grown hazy, but I seem to recall when I did this I found that there are versions of ether-wake where the command doesn't have the hyphen in the name. My copy does. Just make sure it can send the magic packet. The magic packet is mainly just the MAC address repeated over and over. I've posted the hex output of tcpdump for it below. The x's are where I've obfuscated the MAC address.) The only other option your card seems to support is p -- "wake on physical activity." I've never tried that, but it might be worth playing around with just to see if you can make anything work.

BTW, I've noted what you said about the NIC's LED going off when you power down. I just don't have enough experience with this to know whether or not to be confident that that is a reliable indicator.




Here is the obfuscated output from tcpdump for a "magic packet" to wake MAC address 00:18:F3.xx.xx.xx:

Thanks for your help and suggestions.
I have made some progress on the problem, but not completely resolved it.

I have experimented with two machines with different hardware to the machines I am primarily interested in waking with lan. I am able to wake these two machines with either wakeonlan or etherwake, even though both of them use the "g" setting in ethtool. Interestingly, neither will wake from a "shutdown -h now" but only when I issue the "hibernate" command, which suspends the state to disk. I'd prefer not to use the latter, but because it does go into a seemingly completely powerless state, it is sufficient for what I need (by the way, the issue of wake-on-lan arises as I am trying to remotely turn on and off a set of 7 monitor-less and keyboard-less computing nodes that I can't leave on 24/7 because of the heat they produce).

So, the problem seems to be more-or-less specific to a certain hardware. In particular, I think it might be due to the driver (sky2) for the nic.

There is a long discussion here describing trouble with this driver and wol...
http://kerneltrap.org/mailarchive/li.../578534/thread

and there is a kernel patch. I have yet to apply it but that will be my next step.
-m

Actually it shouldn't matter if it's UDP, raw ethernet, some arbitrary IP-proto, whatever. It can even be TCP. hence the term "magic packet".

I'm no expert on the client side implementation, but yes I've encountered this too. My server at home can wake from a 'poweroff' event, but my laptop has to be hibernating (and on AC power! -- which makes sense, if you think about it). I believe that this behavior is determined by the BIOS (and not generally configurable), and not so much NIC-specific. But I could be wrong about that.

I should really look into this someday...

So have you had a chance to try that patch yet?

The diffence in results between shutdown -h and hibernate is interesting. Since both result in a power-off it would seem to inidicate that shutdown is doing or not doing something that is causing the problem. Would it be feasible to compare the respective scripts that execute prior to power-off? Perhaps one is doing something with the ethernet driver the other is not?

hello i have applied these changes and WOL is working fine when i used it to wake my machine from turn off mode....

But it is not working when i switches my machine to sleep mode. My machine is not responding to magic packet sent , if it is in sleep mode. Also this all happens with ubuntu only .....If i go to sleep mode through Windows 7 ultimate. Then my machine can detect the magic packet and resume all the state of machine as earlier.

Can WOL for sleep/suspend/hibernate is possible in ubuntu......if yes do we require some more changes and what are those changes required.

please reply.

it seems that some these issues may also vary by motherboard. I have three types of machines. Small differences in their motherboard hardware mean that they behave differently when it comes to wol. If you know what you are doing, patching kernel drivers may fix these quirks.

In short, these types of wol problems are general ubuntu problems. I hav e successfully used ubuntu to wol from hibernate state. However, it may be that the default kernel you are using with ubuntu is not ideal with respect to your hardware and hence problems arise.

-m