1

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

Wuhtzu
  • 326
  • 2
  • 4
  • 8
  • What OS is installed on the target machine? Sometimes Windows drivers can disable Wake-On-LAN in the ethernet controller EEPROM. – Andrew Sep 20 '12 at 02:08
  • The target machine is running Windows 7. I haven't tested this with another OS. But if it is Windows causing problems, then it should still involve this odd "if the magic packet follows too closely behind an icmp echo request it will not work". Wol works perfectly if you do not ping the machine first. – Wuhtzu Sep 20 '12 at 06:58
  • Can you try to connect client and target machine directly (without switch) and see if it helps? – Dusan Bajic Sep 20 '12 at 12:35
  • Okay, so I guess I have the answer to my own question. – Wuhtzu Sep 20 '12 at 19:11
  • Boy I suck at using this system. Trying out linux as OS instead (via a live cd) solved the problem. I couldn't replicate the behavior described in my question. So I thought it was a windows issue. I however booted back into windows to see if I could still replicate the behavior - and I couldn't. So my guess now has to be that it is an OS problem and not an problem with the ethernet controller. At time of testing (results in my original question) the machine had been running for a couple of months without restarts and Windows had probably started to behave silly. – Wuhtzu Sep 20 '12 at 19:18
  • How should I proceed from here in terms of serverfault.com customary? Should I make an answer (not just comment) to my own question? And what about further questions spawned from this question / answer? I still need to figure out why windows (and maybe also linux) begings to behave like this when running for a long time. Should that be a new question or how should I do? – Wuhtzu Sep 20 '12 at 19:22
  • You should post the answer as a n answer and accept it, and any follow up questions should be posted as new questions, though you may wish to link back to this for some background. – HopelessN00b Oct 09 '12 at 04:38

2 Answers2

2

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.

mprill
  • 584
  • 3
  • 10
  • Thank you for sharing this. For some reason, my 8.1 installation would not show the "Enable PME" option for my network adapters. I just had to run this script. – Ramon Zarazua B. Dec 19 '14 at 03:12
0

I think I have answered (at least part) of my own question.

Trying out linux as OS instead (via a live cd) solved the problem. I couldn't replicate the behavior described in my question.

So I thought it was a windows issue. I however booted back into windows to see if I could still replicate the behavior - and I couldn't. So my guess now has to be that it is an OS problem and not an problem with the ethernet controller. At time of testing (results in my original question) the machine had been running for a couple of months without restarts and Windows had probably started to behave silly.

Wuhtzu
  • 326
  • 2
  • 4
  • 8