I got Wake-on-LAN almost working on my desktop computer. It took some trial and error, but here are the essential steps:
I configured my Gigabyte S-series GA-MA790FX-DS5 motherboard BIOS to have
PME Eventset to
enabled; this enables wake-on-LAN which means, apparently, that the NIC still receives a little bit of power in order to check for the Magic Packet. I also tweaked the ACPI configuration by setting the
ACPI Suspend Typeto be
S3(STR), so that when I do a suspend (rather than hibernate or power-off), only RAM gets power and not the CPU.
/etc/rc./init.d/haltso that it ends with:
# Wakeup-on-LAN /usr/sbin/ethtool -s eth0 wol g sleep 5 # one source claims this matters exec $command $HALTARGS
# Restart the network interfaces after suspending # Author: Victor Chudnovsky (victor dot chudnovsky at g m a i l dot c o m) case "$1" in thaw|resume) service network restart ;; suspend|hibernate) /usr/sbin/ethtool -s eth0 wol g sleep 5 # one source claims this matters ;; *) ;; esac exit $?
To allow waking up my desktop from the outside, I made sure my router allows WOL packets to reach the machine. One can do this either by setting the machine to be the DMZ server or by explictly configuring these packets to be routed through (typically on port 9)
Possibly unnecessary but it can’t hurt: Disabled the standard r8169 driver and instead installed the official r8168 RealTek driver for my onboard Realtek 8111B ethernet chip. I followed the directionsin the README, which essentially amount to the steps here.
Possibly unnecessary: I created
That was enough to enable suspend-to-LAN. To actually wake the computer, one needs a client that can send the Magic Packet to the wakeable machine. These clients thus need the IP address of the machine (or a broadcast address) and the MAC address of the NIC that is a wol-able.
I got an Android app for my phone, aWOL that allows multiple profies for various machines that can be woken up remotely.
wolclients on various computers from which I want to wake up my desktop.
This set-up seems to work pretty well. There are some occasional issues I’m encountering that I’m still trying to debug:
Rarely, I’ve noticed that if I suspend or hibernate and resume too many times too quickly, these operations start failing with a
Device or resource busymessage in
/var/log/pm-suspend/log, but if I wait for a while and try again, it starts working.
The remaining problem is this: if I’m powered off for too long, the card does not respond to the Magic Packet. This defeats the whole purpose of this feature, obviously, so I’m trying to figure out under what conditions this happens. I found this problem mentioned elsewhere, but no solution as of yet. I asked Gigabyte customer support, but have not heard back from them yet.