immediate resume from S3 sleep when ethernet cable plugged in

The problem:

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

Hardware:

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

Software:

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

Edit:

Disabling WOL on the network interface using ethtool prevents the immediate resume.

user19087

Posted 2016-12-01T17:08:03.103

Reputation: 513

What are you doing with this machine? It's very old, surely it's not supported anymore? – Chopper3 – 2016-12-01T18:12:05.300

I don't follow, the hardware is still supported by Linux? – user19087 – 2016-12-01T18:18:24.920

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 – 2016-12-01T18:38:40.233

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 – 2016-12-01T18:41:36.683

1what's sending the WOL packet/s? and why isn't it on 24 hours a day? – Chopper3 – 2016-12-01T18:52:47.893

right now, nothing, per wireshark. Eventuall, some remote apps, which support sending WOL. I suspend the mediaserver when not in use to save power. – user19087 – 2016-12-01T18:58:57.850

narrowed the issue down to the r8169 module. – user19087 – 2016-12-01T18:59:16.617

Is this a home-based question? – Chopper3 – 2016-12-01T19:00:15.750

Yes. But does it really matter if the server is in a home environment or not? If serverfault only supports specific hardware, you would've immediately migrated my question, since I initially posted my hardware.... And the answer turned out to be environment agnostic. – user19087 – 2016-12-01T20:08:51.517

Please read the help pages for serverfault.com when you can, even the first few lines will make it clear why you picked the wrong site to post this on. – Chopper3 – 2016-12-01T22:24:31.227

Answers

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.

user19087

Posted 2016-12-01T17:08:03.103

Reputation: 513

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)

Nicolas V

Posted 2016-12-01T17:08:03.103

Reputation: 1