Differences between revisions 37 and 41 (spanning 4 versions)
Revision 37 as of 2021-03-24 03:44:35
Size: 13168
Editor: ?Celejar
Comment:
Revision 41 as of 2021-04-29 02:23:08
Size: 13465
Editor: ?JunichiUekawa
Comment: remove ancient options, and list the defaults first. Add commands to check which options are being used.
Deletions are marked like this. Additions are marked like this.
Line 5: Line 5:
Some notes on getting the Wake On LAN (WOL) feature to work with a Debian system.

<<TableOfContents(2)>>

Wake On LAN (WOL) enables other systems on your local area network (LAN) to turn on your system over the network. Support for WOL is required in your network card, motherboard, UEFI/BIOS boot firmware and operating system network configuration.

<<TableOfContents(3)>>
Line 10: Line 11:
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 labeled "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.<<FootNote([[http://zovirl.com/2004/software/linux/sk41g_wol|Getting Wake-On-Lan to work with a Shuttle SK41G and Mandrake Linux 9.1]])>>

Your first step towards booting your computer from over the network is to make sure your network card and motherboard support some type of Wake On LAN (WOL) feature.

Motherboards with onboard NICs usually support WOL without the need for any pins/cables.

For motherboards without onboard NICs there are two main systems:

 * Newer motherboards use a WOL pin on the PCI bus, negating the need for the cable.
 * Older motherboards use a WOL three pin connector between your network card and your main board. Both headers are usually labelled 'wol'.
 * Some motherboards support both and only provide the header for backwards compatibility with network cards that don't support the PCI pin.

=== Examples ===

 * 3Com's -NM (non managed) cards do not support WOL while their -M (managed) cards do.

== Firmware ==

In the UEFI/BIOS boot firmware settings under power management or network you may have a clear, intuitive option labelled "Wake On LAN". If you do not have that option, there may be another power management or network option that enables WOL.

=== Examples ===

 * [[https://zovirl.com/2004/02/17/getting-wake-on-lan-to-work-with-a-shuttle-sk41g-and-mandrake-linux-91/|Shuttle XPC SK41G]]: Power Management Setup -> IRQ/Event Activity Detect -> !PowerOn by PCI Card or Modem Ring Resume
Line 20: Line 35:
'''Note:''' With modern systems, Wake On Lan functionality may just work out of the box; e.g., my HP Z440 Wakes On Lan without any special software configuration.
=== Interface setup ===
==== buster ====
The instructions for stretch below didn't work for me, so I did the following:

Add this file
{{{
$ cat /etc/systemd/system/wol.service
[Unit]
Description=Configure Wake-up on LAN

[Service]
Type=oneshot
ExecStart=/sbin/ethtool -s eth0 wol g

[Install]
WantedBy=basic.target
}}}
Activate it with
{{{
sudo systemctl enable wol.service
sudo systemctl daemon-reload
}}}
reboot. Check if it worked with

After activating WOL in hardware and firmware, it must also be activated in software.

First [[#check|check]] if WOL functionality is already activated.

If it is activated, then you can power down your system, and then [[#use|use another system to wake it]].

If it is not activated, then you need to [[#enable|enable]] automatic activation. You can use the integrated WOL functionality of [[#systemd-networkd|systemd networkd]], [[#NetworkManager|NetworkManager]] or [[#ifupdown|ifupdown]]. Alternatively you can activate it [[#Manual|manually]].

<<Anchor(check)>>
=== Checking WOL ===

You can check if WOL is enabled using the DebianMan:ethtool command from the DebianPackage:ethtool package:
Line 70: Line 75:
{{{Wake-on: g}}} means it worked

==== stretch ====

add this file
{{{
$ cat /etc/network/interfaces.d/eth0
{{{Wake-on: g}}} means it is enabled.

<<Anchor(enable)>>
=== Enabling WOL ===

==== ifupdown ====

You can check if you manage network by ifupdown with ifquery. This is the default on Debian installations.

Since [[DebianSqueeze|squeeze]] DebianMan:ethtool parameters can be set directly from an interface configuration file. See the documentation in {{{/usr/share/doc/ethtool/README.Debian}}} for more information.

Add an interface config file {{{/etc/network/interfaces.d/eth0}}} (or modify the global interface config file {{{/etc/network/interfaces}}}):

{{{
Line 81: Line 93:
reboot. Check if it worked with
Activate it:

{{{
sudo reboot
}}}

==== systemd-networkd ====

You can check if your network is managed by systemd-networkd by {{{networkctl list}}} command.

Set the WakeOnLan field to one of the available options in the [[DebianMan:systemd.link#[LINK]_SECTION_OPTIONS|[Link] section of the .link file]] for the network interfaces you want to use WOL on:

{{{
[Link]
WakeOnLan=magic
}}}

Activate it:

{{{
sudo networkctl reload
sudo networkctl reconfigure
}}}

==== NetworkManager ====

You can check if your network devices are managed with {{{nmcli d}}} command.

NetworkManager supports WOL since version 1.0.6 and you can enable it from either your desktop network configuration GUI, or the DebianMan:nm-connection-editor GUI from DebianPackage:nm-connection-editor, or from the DebianMan:nmcli command-line tool using this command:

{{{
$ sudo nmcli c modify "wired1" 802-3-ethernet.wake-on-lan magic
}}}

==== Manual ====

The DebianMan:ethtool command from the DebianPackage:ethtool package can which tells the network interface to respond to the magic packet. Replace eth0 with your network interface device name:

{{{
$ sudo ethtool -s eth0 wol g
}}}

You can arrange for your network management system or init system to run this command automatically.

==== sysvinit ====

Create an init script that runs {{{ethtool -s eth0 wol g}}} or similar when started.

<<Anchor(use)>>
=== Using WOL ===

WOL utilities typically require the target host's NIC MAC address; this can be found by running standard network configuration utilities on the target (e.g. {{{ip a}}}, {{{ifconfig}}}), or by pinging the target system and then checking the local arp table ({{{arp}}}).

Install the DebianPkg:etherwake package in the controlling system for the DebianMan:etherwake command to send the "Magic Packet" to my computer to wake it up. The program must be run as root to send the packet (I use [[sudo]] to execute it).

{{{
$ sudo apt install etherwake
$ sudo etherwake <mac address>
}}}

The DebianPkg:wakeonlan package is also available, DebianMan:wakeonlan is 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 install wakeonlan
$ wakeonlan <mac address>
}}}

<<Anchor(troubleshoot)>>
=== Troubleshooting WOL ===

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).

However, if you __do__ want Wake On LAN on any of these events (other than "Magic Packet"), you may find conflicts with DebianPackage:pm-utils. At the time of writing, scripts in this package will set the wake option for all relevant interface cards to "Magic Packet" __only__, (g). This will be a problem if you want your machine to wake "on-demand", when it receives traffic (u), for example. The issue and a fix is discussed [[#PM-Utils_Conflicts|below]].

==== 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<<FootNote([[https://web.archive.org/web/20080424041500/http://ahh.sourceforge.net/wol/faq.html|http://ahh.sourceforge.net/wol/faq.html]])>>, so we need to get it going.

===== 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 {{{local.conf}}} into the directory:

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

ethtool comes from the DebianPkg: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 {{{local.conf}}} file with the appropriate options line, maybe something like:

{{{
options 3c59x enable_wol=1
}}}

 {i} If your kernel uses an [[initramfs]] image (eg. Debian stock kernels), also run {{{update-initramfs -u}}} (or {{{update-initramfs -u -k all}}} if necessary) to rebuild kernel initial ramdisk(s).

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.

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.

===== 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:
Line 84: Line 198:

Settings for eth0:
 Supported ports: [ MII ]
 Supported link modes: 10baseT/Half 10baseT/Full
                         100baseT/Half 100baseT/Full
                         1000baseT/Full
 Supported pause frame use: No
 Supports auto-negotiation: Yes
 Advertised link modes: 10baseT/Half 10baseT/Full
                         100baseT/Half 100baseT/Full
                         1000baseT/Full
 Advertised pause frame use: No
 Advertised auto-negotiation: Yes
 Speed: 100Mb/s
 Duplex: Full
 Port: MII
 PHYAD: 1
 Transceiver: external
 Auto-negotiation: on
 Supports Wake-on: g
 Wake-on: g
 Link detected: yes
}}}

{{{Wake-on: g}}} means it worked

==== Squeeze ====

As of [[DebianSqueeze|Squeeze]] {{{ethtool}}} parameters can be set directly from {{{/etc/network/interfaces}}}. The above can be achieved like this:{{{
iface eth0 inet dhcp
        ethernet-wol g
}}}

The script {{{/etc/network/if-up.d/ethtool}}} will then take care of calling {{{ethtool}}} on ifup. See {{{/usr/share/doc/ethtool/README.Debian}}} for more information.

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


==== Before squeeze ====
After activating Wake On LAN in hardware it is also necessary to activate it in software. This is done using DebianPkg:ethtool, which tells the interface to respond to the magic packet. Replace eth0 with your network interface device name: {{{
$ su
# aptitude install ethtool
# ethtool -s eth0 wol g
}}}

This can be automated by editing {{{/etc/network/interfaces}}}: {{{
iface eth0 inet dhcp
        post-up /sbin/ethtool -s $IFACE wol g
        post-down /sbin/ethtool -s $IFACE 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.


=== Sending WOL messages ===
Wake On Lan utilities typically require the target host's NIC MAC address; this can be found by running standard network configuration utilities on the target (e.g. {{{ip a}}}, {{{ifconfig}}}), or by pinging the target system and then checking the local arp table ({{{arp}}}).

I installed the DebianPkg: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 to send the packet (I use [[sudo]] to execute it). {{{
# aptitude install etherwake
# etherwake <mac address>
}}}

DebianPkg: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. {{{
# aptitude 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).

However, if you __do__ want Wake On LAN on any of these events (other than "Magic Packet"), you may find conflicts with {{{pm-utils}}}<<FootNote(https://packages.debian.org/search?keywords=pm-utils)>>. At the time of writing, scripts in this package will set the wake option for all relevant interface cards to "Magic Packet" __only__, (g). This will be a problem if you want your machine to wake "on-demand", when it receives traffic (u), for example. The issue and a fix is discussed [[#PM-Utils_Conflicts|below]].

=== 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<<FootNote([[http://replay.waybackmachine.org/20080424041500/http://ahh.sourceforge.net/wol/faq.html|http://ahh.sourceforge.net/wol/faq.html]])>>, so we need to get it going.

==== 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 {{{local.conf}}} into the directory. It says: {{{
install 8139too /sbin/modprobe -i 8139too; /sbin/ethtool -s eth0 wol g
}}}

ethtool comes from the DebianPkg: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 {{{local.conf}}} file with the appropriate options line, maybe something like: {{{
options 3c59x enable_wol=1
}}}

 {i} If your kernel uses an [[initramfs]] image (eg. Debian stock kernels), also run {{{update-initramfs -u}}} (or {{{update-initramfs -u -k all}}} if necessary) to rebuild kernel initial ramdisk(s).

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.

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.

==== 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 [[DebianMan:8/ifup|ifup]] also resets the WOL setting, so I added an up line to {{{/etc/network/interfaces}}} under 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 [[DebianMan:8/ifup|ifup]] also resets the WOL setting, so I added an up line to {{{/etc/network/interfaces}}} under eth0:

{{{
Line 187: Line 211:
=== PM-Utils Conflicts === ==== PM-Utils Conflicts ====
Line 191: Line 215:
configured in {{{/etc/network/interfaces}}} (or one of the files under {{{/etc/network/interfaces.d}}}, or manually using {{{ethtool}}} or in some other way). Look for lines in the file similar to the following: {{{ configured in {{{/etc/network/interfaces}}} (or one of the files under {{{/etc/network/interfaces.d}}}, or manually using {{{ethtool}}} or in some other way). Look for lines in the file similar to the following:

{{{
Line 203: Line 229:
Line 227: Line 254:

}}}

}}}
Line 233: Line 257:
Wake On LAN works on Debian and opens some new options up to me.
Wake On LAN works on Debian and opens up new options for machine management.
Line 240: Line 265:
Line 241: Line 267:
 * Using Wake-On-LAN WOL/PME to power up your computer remotely ~-<<BR>> [[http://replay.waybackmachine.org/20070216135103/http://xlife.zuavra.net/index.php/60/|http://xlife.zuavra.net/index.php/60/]]-~  * Using Wake-On-LAN WOL/PME to power up your computer remotely ~-<<BR>> [[https://web.archive.org/web/20070216135103/http://xlife.zuavra.net/index.php/60/|http://xlife.zuavra.net/index.php/60/]]-~

Translation(s): English - Brazilian Portuguese - Español - Français - Italiano - Русский


Wake On LAN

Wake On LAN (WOL) enables other systems on your local area network (LAN) to turn on your system over the network. Support for WOL is required in your network card, motherboard, UEFI/BIOS boot firmware and operating system network configuration.

Hardware

Your first step towards booting your computer from over the network is to make sure your network card and motherboard support some type of Wake On LAN (WOL) feature.

Motherboards with onboard NICs usually support WOL without the need for any pins/cables.

For motherboards without onboard NICs there are two main systems:

  • Newer motherboards use a WOL pin on the PCI bus, negating the need for the cable.
  • Older motherboards use a WOL three pin connector between your network card and your main board. Both headers are usually labelled 'wol'.
  • Some motherboards support both and only provide the header for backwards compatibility with network cards that don't support the PCI pin.

Examples

  • 3Com's -NM (non managed) cards do not support WOL while their -M (managed) cards do.

Firmware

In the UEFI/BIOS boot firmware settings under power management or network you may have a clear, intuitive option labelled "Wake On LAN". If you do not have that option, there may be another power management or network option that enables WOL.

Examples

  • Shuttle XPC SK41G: Power Management Setup -> IRQ/Event Activity Detect -> PowerOn by PCI Card or Modem Ring Resume

Software

After activating WOL in hardware and firmware, it must also be activated in software.

First check if WOL functionality is already activated.

If it is activated, then you can power down your system, and then use another system to wake it.

If it is not activated, then you need to enable automatic activation. You can use the integrated WOL functionality of systemd networkd, NetworkManager or ifupdown. Alternatively you can activate it manually.

Checking WOL

You can check if WOL is enabled using the ethtool command from the ethtool package:

$ sudo ethtool eth0

Settings for eth0:
        Supported ports: [ MII ]
        Supported link modes:   10baseT/Half 10baseT/Full 
                                100baseT/Half 100baseT/Full 
                                1000baseT/Full 
        Supported pause frame use: No
        Supports auto-negotiation: Yes
        Advertised link modes:  10baseT/Half 10baseT/Full 
                                100baseT/Half 100baseT/Full 
                                1000baseT/Full 
        Advertised pause frame use: No
        Advertised auto-negotiation: Yes
        Speed: 100Mb/s
        Duplex: Full
        Port: MII
        PHYAD: 1
        Transceiver: external
        Auto-negotiation: on
        Supports Wake-on: g
        Wake-on: g
        Link detected: yes

Wake-on: g means it is enabled.

Enabling WOL

ifupdown

You can check if you manage network by ifupdown with ifquery. This is the default on Debian installations.

Since squeeze ethtool parameters can be set directly from an interface configuration file. See the documentation in /usr/share/doc/ethtool/README.Debian for more information.

Add an interface config file /etc/network/interfaces.d/eth0 (or modify the global interface config file /etc/network/interfaces):

auto eth0
iface eth0 inet dhcp
        ethernet-wol g

Activate it:

sudo reboot

systemd-networkd

You can check if your network is managed by systemd-networkd by networkctl list command.

Set the WakeOnLan field to one of the available options in the [Link] section of the .link file for the network interfaces you want to use WOL on:

[Link]
WakeOnLan=magic

Activate it:

sudo networkctl reload
sudo networkctl reconfigure

NetworkManager

You can check if your network devices are managed with nmcli d command.

NetworkManager supports WOL since version 1.0.6 and you can enable it from either your desktop network configuration GUI, or the nm-connection-editor GUI from nm-connection-editor, or from the nmcli command-line tool using this command:

$ sudo nmcli c modify "wired1" 802-3-ethernet.wake-on-lan magic

Manual

The ethtool command from the ethtool package can which tells the network interface to respond to the magic packet. Replace eth0 with your network interface device name:

$ sudo ethtool -s eth0 wol g

You can arrange for your network management system or init system to run this command automatically.

sysvinit

Create an init script that runs ethtool -s eth0 wol g or similar when started.

Using WOL

WOL utilities typically require the target host's NIC MAC address; this can be found by running standard network configuration utilities on the target (e.g. ip a, ifconfig), or by pinging the target system and then checking the local arp table (arp).

Install 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 to send the packet (I use sudo to execute it).

$ sudo apt install etherwake
$ sudo etherwake <mac address>

The wakeonlan package is also available, wakeonlan is 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 install wakeonlan
$ wakeonlan <mac address>

Troubleshooting WOL

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).

However, if you do want Wake On LAN on any of these events (other than "Magic Packet"), you may find conflicts with pm-utils. At the time of writing, scripts in this package will set the wake option for all relevant interface cards to "Magic Packet" only, (g). This will be a problem if you want your machine to wake "on-demand", when it receives traffic (u), for example. The issue and a fix is discussed below.

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 boot1, so we need to get it going.

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 local.conf into the directory:

install 8139too /sbin/modprobe -i 8139too; /sbin/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 local.conf file with the appropriate options line, maybe something like:

options 3c59x enable_wol=1
  • {i} If your kernel uses an initramfs image (eg. Debian stock kernels), also run update-initramfs -u (or update-initramfs -u -k all if necessary) to rebuild kernel initial ramdisk(s).

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.

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.

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:

$ sudo 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:

iface eth0 inet dhcp
        up /sbin/ethtool -s $IFACE wol g

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

PM-Utils Conflicts

The pm-utils package contains scripts that are run on suspend, hibernate and on resume of the system. There is one script, /usr/lib/pmutils/power.d/disable_wol, which sets the configuration for interfaces to only wake on "Magic Packet" (g), regardless of the settings you may have configured in /etc/network/interfaces (or one of the files under /etc/network/interfaces.d, or manually using ethtool or in some other way). Look for lines in the file similar to the following:

            disable) ethtool -s "${d##*/}" wol d>/dev/null 2>&1;;
            enable) ethtool -s "${d##*/}" wol g>/dev/null 2>&1;;

Obviously, if you have set an interface to Wake on LAN in the event of a unicast packet or "Magic Packet" (ug), then suspend using pm-suspend, for example, this script will set the interface to "Magic Packet" only (g) as part of the suspension process.

You can detect the problem, once you know what you're looking for, by noticing through ethtool after a resume that the "Wake-on" settings for interfaces have been set to "g".

A simple fix (that will not interfere with package updates) is to add a file with the same name, disable_wol to the local configuration directory, /etc/pm/power.d/. This overrides the script in /usr/lib/pm-utils/power.d/disable_wol.

This is my (somewhat verbose, and functionally trivial) /etc/pm/power.d/disable_wol:

# Override the file /usr/lib/pm-utils/power.d/disable_wol which
# manually configures Wake On Lan (WOL) settings for interfaces.
# That default file uses ethtool to configure WOL for all interfaces
# to "g" (magic packet) alone.  
#
# Note that the presence of this file, with the same name but under
# /etc/pm/power.d/, is sufficient to completely override the file
# under /usr/lib/pm-utils/power.d/.  This latter file is included in
# the the "pm-utils" Debian package, and may be updated from time to
# time through the package-management system.  The directories under
# /etc/pm/ are the appropriate places for local configurations.
#
# On this system, the WOL configurations are made in the interface
# configuration under /etc/network/.  Each interface can have a 
# different configuration, and it is typical to configure WOL to 
# "ug" to wake the system on a unicast packet for traffic sent
# specifically to that interface.  This allows the system to be
# woken on demand, when traffic to one of its interfaces is received.


exit 0

Conclusion

Wake On LAN works on Debian and opens up new options for machine management.

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.


CategoryNetwork | CategorySystemAdministration