Differences between revisions 10 and 11
Revision 10 as of 2009-02-14 19:32:16
Size: 6447
Editor: FranklinPiat
Comment: add linux to another Howto.
Revision 11 as of 2009-02-15 01:09:35
Size: 6556
Editor: GeoffSimmons
Comment: Minor spelling and formatting, remove Kernel 2.4 notes, add categories.
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
''Some notes on getting the Wake On Lan (WOL) feature to work with a Debian system.'' #language en
||<tablestyle="width: 100%;" style="border: 0px hidden">~-[:DebianWiki/EditorGuide#translation:Translation(s)]: none-~||<style="text-align: right;border: 0px hidden"> (!) [:/Discussion:Discussion]||
----
= Wake On LAN =
Some notes on getting the Wake On LAN (WOL) feature to work with a Debian system.

[[TableOfContents(2)]]
Line 4: Line 10:
Your first step towards booting your computer from over the network is to make sure your ethernet card and mother board support some type of wake on lan feature. Notably 3com's -NM (non managed) cards do not support WOL while their -M (managed) cards do. Your first step towards booting your computer from over the network is to make sure your Ethernet card and mother board support some type of Wake On LAN feature. Notably 3Com's -NM (non managed) cards do not support WOL while their -M (managed) cards do.
Line 6: Line 12:
There are two main systems. The older method uses a wake on lan three pin connector between your ethernet card and your main board. Both headers are usually labled 'wol'. The newer system uses a wake on lan pin on the PCI bus, negating the need for the cable. Some main boards support both and only provide the header for backwards compatibility with ethernet cards that don't support the PCI pin. There are two main systems. The older method uses a Wake On LAN three pin connector between your Ethernet card and your main board. Both headers are usually labelled 'wol'. The newer system uses a Wake On LAN pin on the PCI bus, negating the need for the cable. Some main boards support both and only provide the header for backwards compatibility with Ethernet cards that don't support the PCI pin.
Line 8: Line 14:
Recent motherboards with onboard NICs support wake on lan without the need for any pins/cables. Recent motherboards with onboard NICs support Wake On LAN without the need for any pins/cables.
Line 11: Line 17:
In a nice BIOS under power management you will have a clear, intuitive option labled "wake on lan". Unfortunatly my system wasn't so clear and has a couple options available. One seems to always work, the other sometimes works. I built upon the information shared by Mark Ivey since I also have a Shuttle Xpc ["SK41G"] and am using the "!PowerOn by PCI Card" option with success. In a nice BIOS under power management you will have a clear, intuitive option labelled "Wake On LAN". Unfortunately my system wasn't so clear and has a couple options available. One seems to always work, the other sometimes works. I built upon the information shared by Mark Ivey since I also have a Shuttle XPC SK41G and am using the "!PowerOn by PCI Card" option with success.
Line 17: Line 23:
After activating Wake On Lan in hardware it is also necessary to activate it in software. This is done using ethtool, which tells the interface to respond to the magic packet. Replace eth0 with your network interface device name. After activating Wake On LAN in hardware it is also necessary to activate it in software. This is done using DebPkg:ethtool, which tells the interface to respond to the magic packet. Replace eth0 with your network interface device name: {{{
sudo apt-get install ethtool
ethtool eth0 -s wol g
}}}
Line 19: Line 28:
{{{
 sudo apt-get install ethtool
 ethtool eth0 -s wol g
}}}
This can be automated by editing /etc/network/interfaces

{{{
This can be automated by editing {{{/etc/network/interfaces}}}: {{{
Line 28: Line 31:
        post-down ethtool -s eth0 wol g}}}         post-down ethtool -s eth0 wol g
}}}
Line 34: Line 38:
I installed the etherwake package in the controlling system for the etherwake command to send the "Magic Packet" to my computer to wake it up. The program must be run as root (I guess it could be suid root) to send the packet. I use sudo to execute it. I installed the DebPkg:etherwake package in the controlling system for the etherwake command to send the "Magic Packet" to my computer to wake it up. The program must be run as root (I guess it could be suid root) to send the packet. I use sudo to execute it: {{{
etherwake <mac address>
}}}
Line 36: Line 42:
{{{
 etherwake <mac address>
DebPkg:wakeonlan is also available, a program that uses UDP packets not TCP, and hence does not need to be run as root. It is also slightly more configurable. {{{
sudo apt-get install wakeonlan
wakeonlan <mac address>
Line 39: Line 46:
wakeonlan is also available, a program that uses udp packets not tcp, and hence does not need to be run as root. It is also slightly more configurable.
Line 41: Line 47:
{{{
 sudo apt-get install wakeonlan
 wakeonlan <mac address>
}}}
Line 46: Line 48:
I found that I __didn't__ want any of the Wake On Lan settings except Wake on "Magic Packet" (g). I only wanted my machine to turn on when I specifically told it to, not on unicast messages (u), broadcast messages (b) or multicast messages (m). I found that I __didn't__ want any of the Wake On LAN settings except Wake on "Magic Packet" (g). I only wanted my machine to turn on when I specifically told it to, not on unicast messages (u), broadcast messages (b) or multicast messages (m).
Line 48: Line 50:
=== WOL Persistance === === WOL Persistence ===
Line 54: Line 56:
With a 2.6 kernel we're using /etc/modprobe.d. You may be using /etc/modprobe.conf, but if it's not including /etc/modprobe.d you're probably getting told about that each time you boot and some stuff may not be configured properly. I'm using /etc/modprobe.d and I added a file install.local into the directory. It says: With a 2.6 kernel we're using {{{/etc/modprobe.d}}}. You may be using {{{/etc/modprobe.conf}}}, but if it's not including {{{/etc/modprobe.d}}} you're probably getting told about that each time you boot and some stuff may not be configured properly. I'm using {{{/etc/modprobe.d}}} and I added a file {{{install.local}}} into the directory. It says: {{{
install 8139too /sbin/modprobe -i 8139too; ethtool -s eth0 wol g
}}}
Line 56: Line 60:
{{{
 install 8139too /sbin/modprobe -i 8139too; ethtool -s eth0 wol g
ethtool comes from the DebPkg:ethtool package, so you'll need to install that unless your card supports a load option to set WOL. If that's the case I'd make an {{{options.local}}} file with the appropriate options line, maybe something like: {{{
options 3c59x enable_wol=1
Line 59: Line 63:
ethtool comes from the ethtool package, so you'll need to install that unless your card supports a load option to set wol. If that's the case I'd make an options.local file with the appropriate options line, maybe something like:
Line 61: Line 64:
{{{
 options 3c59x enable_wol=1
While I was messing with these settings, I noticed that both 8139too and 8139cp were loading, but loading just 8139cp alone failed since my chipset isn't new enough so I [:KernelModuleBlacklisting:blacklisted] it.

Testing on another machine with a C3905B-TXNM and a 3C905C-TXM that uses the 3c59x module to drive them both I found that ethtool was unable to query them or set the WOL setting, but that the {{{enable_wol=1}}} setting did work and was required.

The forcedeth driver in Kernel 2.6.18 (in Etch) does something strange and [http://www.ussg.iu.edu/hypermail/linux/kernel/0609.3/1337.html you have to send a reversed MAC address]. If your MAC address were 00:11:22:33:44:55, you would type: {{{
etherwake -D 55:44:33:22:11:00
Line 64: Line 71:
While I was messing with these settings, I noticed that both 8139too and 8139cp were loading, but loading just 8139cp alone failed since my chipset isn't new enough so I blacklisted it.

Testing on another machine with a C3905B-TXNM and a 3C905C-TXM that uses the 3c59x module to drive them both I found that ethtool was unable to query them or set the wol setting, but that the {{{enable_wol=1}}} setting did work and was required.

The forcedeth driver in Kernel 2.6.18 (in Etch) does something strange and [http://www.ussg.iu.edu/hypermail/linux/kernel/0609.3/1337.html you have to send a reversed mac address]. If your mac address were 00:11:22:33:44:55, you would type:

{{{
 etherwake -D 55:44:33:22:11:00
}}}
==== Kernel 2.4 ====
I believe you just need to modify /etc/modutils/actions (or maybe add an actions.local) to include post-install hooks for your ethernet card module to call ethtool and then re-run update-modules to have /etc/modules.conf re-written with your changes to /etc/modutils/*
Line 77: Line 73:
After an hour struggling with why my system still didn't work I started throwing in the ethtool query command all over the place to see what the deal was. After an hour struggling with why my system still didn't work I started throwing in the ethtool query command all over the place to see what the deal was: {{{
ethtool eth0
}}}
Line 79: Line 77:
{{{
 ethtool eth0
==== ifup ====
I found that (at least with my 8139too driver on Debian 3.1/Sarge) the install line was working when I'd {{{modprobe 8139too}}}, but ifup also resets the WOL setting, so I added an up line to /etc/network/interfaces under eth0: {{{
up ethtool -s eth0 wol g
Line 82: Line 81:
==== ifup ====
I found that (at least with my 8139too driver on Debian 3.1/Sarge) the install line was working when I'd modprobe 8139too, but ifup also resets the wol setting, so I added an up line to /etc/network/interfaces under eth0:
Line 85: Line 82:
{{{
 up ethtool -s eth0 wol g
}}}
I kept the ethtool command in /etc/modprobe.d/install.local incase I boot and ifup isn't executed before shutting down.
I kept the ethtool command in {{{/etc/modprobe.d/install.local}}} in case I boot and ifup isn't executed before shutting down.
Line 91: Line 85:
Wake On Lan works on Debian and opens some new options up to me. Wake On LAN works on Debian and opens some new options up to me.
Line 93: Line 87:
I can log into my gateway and boot my desktop, grab what I need and then power it back off remotely. I'm using DHCP with mac to ip mappings so I can look in that file on my gateway system to know the mac address of the system I wish to wake up. If I didn't have that I could keep a text file. I can log into my gateway and boot my desktop, grab what I need and then power it back off remotely. I'm using DHCP with MAC-to-IP mappings so I can look in that file on my gateway system to know the MAC address of the system I wish to wake up. If I didn't have that I could keep a text file.
Line 95: Line 89:
My next feat is to have non-essential systems poweroff (not just halt) on a power outage to extend the battery runtime for the essential systems and then use WOL to power the other systems back on after power is restored and the battery has hit some specific charge level. I think some settings with halt or APM or ACPI are not right on those systems. See OffAndOnAgain. My next feat is to have non-essential systems power-off (not just halt) on a power outage to extend the battery runtime for the essential systems and then use WOL to power the other systems back on after power is restored and the battery has hit some specific charge level. I think some settings with halt or APM or ACPI are not right on those systems. See ["OffAndOnAgain"].
Line 97: Line 91:
== See also == == See Also ==
Line 99: Line 93:
There's
----
CategoryNetwork | CategorySystemAdministration

[:DebianWiki/EditorGuide#translation:Translation(s)]: none

(!) [:/Discussion:Discussion]


Wake On LAN

Some notes on getting the Wake On LAN (WOL) feature to work with a Debian system.

?TableOfContents(2)

Hardware

Your first step towards booting your computer from over the network is to make sure your Ethernet card and mother board support some type of Wake On LAN feature. Notably 3Com's -NM (non managed) cards do not support WOL while their -M (managed) cards do.

There are two main systems. The older method uses a Wake On LAN three pin connector between your Ethernet card and your main board. Both headers are usually labelled 'wol'. The newer system uses a Wake On LAN pin on the PCI bus, negating the need for the cable. Some main boards support both and only provide the header for backwards compatibility with Ethernet cards that don't support the PCI pin.

Recent motherboards with onboard NICs support Wake On LAN without the need for any pins/cables.

Firmware / BIOS

In a nice BIOS under power management you will have a clear, intuitive option labelled "Wake On LAN". Unfortunately my system wasn't so clear and has a couple options available. One seems to always work, the other sometimes works. I built upon the information shared by Mark Ivey since I also have a Shuttle XPC SK41G and am using the "PowerOn by PCI Card" option with success.

http://zovirl.com/2004/software/linux/sk41g_wol

Software

Interface setup

After activating Wake On LAN in hardware it is also necessary to activate it in software. This is done using ethtool, which tells the interface to respond to the magic packet. Replace eth0 with your network interface device name:

sudo apt-get install ethtool
ethtool eth0 -s wol g

This can be automated by editing /etc/network/interfaces:

iface eth0 inet dhcp
        post-up ethtool -s eth0 wol g
        post-down ethtool -s eth0 wol g

This runs ethtool after every time eth0 is brought up, and also after it is brought down, so WOL should work even if the network is not brought down correctly.

You can then power down your system, and prepare the other system to wake it.

Sending WOL messages

I installed the etherwake package in the controlling system for the etherwake command to send the "Magic Packet" to my computer to wake it up. The program must be run as root (I guess it could be suid root) to send the packet. I use sudo to execute it:

etherwake <mac address>

wakeonlan is also available, a program that uses UDP packets not TCP, and hence does not need to be run as root. It is also slightly more configurable.

sudo apt-get install wakeonlan
wakeonlan <mac address>

WOL Sensitivity

I found that I didn't want any of the Wake On LAN settings except Wake on "Magic Packet" (g). I only wanted my machine to turn on when I specifically told it to, not on unicast messages (u), broadcast messages (b) or multicast messages (m).

WOL Persistence

Hardware looks up to spec, you think the BIOS is set right, but it still doesn't work without some tweaking using the software. According to the Wake On Lan client FAQ most Linux drivers disable the WOL feature on boot, so we need to get it going.

http://ahh.sourceforge.net/wol/faq.html

Kernel 2.6

With a 2.6 kernel we're using /etc/modprobe.d. You may be using /etc/modprobe.conf, but if it's not including /etc/modprobe.d you're probably getting told about that each time you boot and some stuff may not be configured properly. I'm using /etc/modprobe.d and I added a file install.local into the directory. It says:

install 8139too /sbin/modprobe -i 8139too; ethtool -s eth0 wol g

ethtool comes from the ethtool package, so you'll need to install that unless your card supports a load option to set WOL. If that's the case I'd make an options.local file with the appropriate options line, maybe something like:

options 3c59x enable_wol=1

While I was messing with these settings, I noticed that both 8139too and 8139cp were loading, but loading just 8139cp alone failed since my chipset isn't new enough so I [:KernelModuleBlacklisting:blacklisted] it.

Testing on another machine with a C3905B-TXNM and a 3C905C-TXM that uses the 3c59x module to drive them both I found that ethtool was unable to query them or set the WOL setting, but that the enable_wol=1 setting did work and was required.

The forcedeth driver in Kernel 2.6.18 (in Etch) does something strange and [http://www.ussg.iu.edu/hypermail/linux/kernel/0609.3/1337.html you have to send a reversed MAC address]. If your MAC address were 00:11:22:33:44:55, you would type:

etherwake -D 55:44:33:22:11:00

Debugging state with ethtool

After an hour struggling with why my system still didn't work I started throwing in the ethtool query command all over the place to see what the deal was:

ethtool eth0

ifup

I found that (at least with my 8139too driver on Debian 3.1/Sarge) the install line was working when I'd modprobe 8139too, but ifup also resets the WOL setting, so I added an up line to /etc/network/interfaces under eth0:

up ethtool -s eth0 wol g

I kept the ethtool command in /etc/modprobe.d/install.local in case I boot and ifup isn't executed before shutting down.

Conclusion

Wake On LAN works on Debian and opens some new options up to me.

I can log into my gateway and boot my desktop, grab what I need and then power it back off remotely. I'm using DHCP with MAC-to-IP mappings so I can look in that file on my gateway system to know the MAC address of the system I wish to wake up. If I didn't have that I could keep a text file.

My next feat is to have non-essential systems power-off (not just halt) on a power outage to extend the battery runtime for the essential systems and then use WOL to power the other systems back on after power is restored and the battery has hit some specific charge level. I think some settings with halt or APM or ACPI are not right on those systems. See ["OffAndOnAgain"].

See Also


CategoryNetwork | CategorySystemAdministration