The problem:

  • The computer resumes from S3 sleep (suspend-to-ram) within 5 seconds of suspend if the ethernet cable is connected


  • Intel E2180
  • Gigabyte P35-DS3L
  • Realtek RTL8111b (using the r8169 module)


  • I've disabled ACPI wakeup for all devices, per /proc/acpi/wakeup
  • kernel logs per dmesg look normal - no driver inhibiting suspend, or any other problems. The logs from a successful suspend (ethernet cable disconnected) and a broken suspend (ethernet cable connected) are the same.
  • on S3 suspend-to-ram the kernel force-enables ACPI wakeup for the PCI-e bridge. I suspect this is normal.
  • BIOS: USB mouse/keyboard wakeup disabled, wake-on-ring disabled, wake-on-PME enabled
  • ethtool reports WOL set to ug.

I suspected a faulty device emitting continous WOL packets, but Wireshark records no WOL packets while the computer is on.

This occurs even with all other ports (USB) disconnected (leaving VGA/ethernet).

Also, I will need WOL functionality


  • Disabling WOL on the network interface using ethtool prevents the immediate resume.
  • What are you doing with this machine? It's very old, surely it's not supported anymore? – Chopper3 Dec 1 '16 at 18:12
  • I don't follow, the hardware is still supported by Linux? – user19087 Dec 1 '16 at 18:18
  • That may be the case but what about the systemboard manufacturer? Do they support it still? what's the use-case for this setup you have in mind? – Chopper3 Dec 1 '16 at 18:38
  • Media server, WOL to save power, all my remote apps already support WOL. Since the last BIOS update was years ago, I doubt the systemboard still receives updates. – user19087 Dec 1 '16 at 18:41
  • 1
    what's sending the WOL packet/s? and why isn't it on 24 hours a day? – Chopper3 Dec 1 '16 at 18:52

Turns out this is a misunderstanding of the kernel's interface settings for wake-on-lan. From ethtool's manual:

Sets Wake-on-LAN options.  Not all devices support this.
The argument to this option is a string of characters
specifying which options to enable.

p   Wake on PHY activity
u   Wake on unicast messages
m   Wake on multicast messages
b   Wake on broadcast messages
a   Wake on ARP
g   Wake on MagicPacket™
s   Enable SecureOn™ password for MagicPacket™
d   Disable (wake on nothing).  This option
    clears all previous options.

I assumed the unicast or broadcast flags would restrict the source of the magic packet, that is:

  • ug: only wake if a unicast WoL packet was received
  • bg: only wake if a broadcast WoL packet was received

However, the unicast or broadcast flags match any unicast or broadcast packets. What actually happens:

  • ug: wake if a unicast packet was received, or if a WoL packet was received (unicast or broadcast; doesn't matter as long as the MAC matches)
  • bg: wake if a broadcast packet was received, or if a WoL packet was received (unicast or broadcast; doesn't matter as long as the MAC matches)

Of course the common unicast caveat applies to the unicast (u) and WoL (g) flags: unicast packets can only be received if the target's MAC is still held by the ARP table.

| improve this answer | |

I have the same mainboard and the same issue... you were pretty close to figure out a solution. Change the configuration of the network interface, so that it only accepts "magicpacket" forget about multicast/unicast...

sudo ethtool -s eth0 wol g

This did the trick for me, and as a bonus I'm able to wake the computer up from the network (with etherwake)

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.