Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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

share|improve this question
    
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 2: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 6: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

2 Answers 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.

share|improve this answer

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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