Intel 82579LM Gbit Ethernet Controller – magic packet (WOL) right after ping is not working

packetpingwake-on-lan

I am experiencing a very annoying and mysterious behavior when sending magic packets (for Wake On LAN) shortly after pinging an Intel 82579LM GigaBit Ethernet Controller (the onboard ethernet controller of the Intel DQ67SW motherboard).

So basically if I send an icmp echo request and wait a time dt before sending a magic packet I will experience the following:

dt < 1 second:
The computer will not wake due to the magic packet

dt >= 1 second:
The computer wakes as it is suppose to due to the magic packet

This script is a minimal implementation of the scenario I am talking about:

#!/bin/sh
ping -q -c 1 -W 1 $1
sleep $3
wakeonlan -p 7 $2 # Could be wakeonlan or etherwake or similar

The script would then be invoked like "wake.sh ip mac dt":

Jonas@whatever:~$ ./wake.sh 10.0.1.147 00:22:4D:82:28:30 1.2
PING 10.0.1.147 (10.0.1.147) 56(84) bytes of data.

--- 10.0.1.147 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms

Sending magic packet to 255.255.255.255:7 with 00:22:4D:82:28:30

One more twist to the problem exists. Regardless of the value of dt (dt = 0, 0.5s, 2s) if the script is invoked twice in a row, with a time inteval dt' between invocations, the computer will wake. This dt' value causing the computer to wake is 20-40 seconds.

It is very reproducible. I've tried using two different devices to run the wake script using different wake-on-lan-utilities (wake on lan and etherwake) and the results are the same. I've also looked at the magic packets using tcpdump. They are well formatted regardless of the whether the ping request goes first or not.

Am I overlooking something obvious here? It seems like an unlikely flaw in an ethernet controller that an icmp request qould "block" for subsequent magic packets.

Any thoughts on this (additional tests to perform etc.) would be much appreciated before I go talk to Intel.

Best regards
Jonas

Best Answer

We've had similar issues with WoL on newer Intel cards on Windows 7. The issue was being caused by driver features for power saving: PME and EEE

With the Intel NIC drivers Windows 7 disables PMEs (Power Management Event) on a shutdown which renders WoL unusable. Enabling PME for a NIC (by doing that in the Advanced tab of the NIC's device settings in Device Manager) would allow WoL to function.

The second feature implementing the Energy-Efficient Ethernet standard would cause WoL to be unreliable if a workstation was powered on for a long time, but idle. This was probably due to EEE's weak compatibility with other networking hardware.

The solution was to disable EEE and enable PME for all NICs that had this setting in registry. This is the PowerShell script we use to achieve this:

$regkey = 'HKLM:\SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}'

if (Test-Path $regkey)
{
    Get-ChildItem $regkey -ErrorAction SilentlyContinue |% { 
        if ($_.GetValueNames() -contains 'EnablePME')
        {
            Write-Host "PME value found in $_"
            [Microsoft.Win32.Registry]::SetValue($_, 'EnablePME','1')
        }
    }

    Get-ChildItem $regkey -ErrorAction SilentlyContinue |% {
        if ($_.GetValueNames() -contains 'EEELinkAdvertisement')
        {
            Write-Host "EEELinkAdvertisement value found in $_"
            [Microsoft.Win32.Registry]::SetValue($_, 'EEELinkAdvertisement', '0')
        }
    }
}

The GUID used in $regkey is described here. Be warned that modifying settings in this registry key is dangerous since it can render your NICs unusable, in the worst case scenario.

Related Topic