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