Я испытываю очень раздражающее и загадочное поведение при отправке волшебных пакетов (для Wake On LAN) вскоре после проверки связи с контроллером Intel 82579LM GigaBit Ethernet (встроенным контроллером Ethernet Материнская плата Intel DQ67SW).
Таким образом, если я отправлю эхо-запрос icmp и подожду время dt перед отправкой волшебного пакета, я испытаю следующее:
dt <1 секунда: компьютер не просыпается из-за волшебного пакета
dt> = 1 секунда: компьютер просыпается, как и предполагалось, из-за волшебного пакета
Этот сценарий представляет собой минимальную реализацию сценария, о котором я говорю:
#!/bin/sh
ping -q -c 1 -W 1 $1
sleep $3
wakeonlan -p 7 $2 # Could be wakeonlan or etherwake or similar
Затем сценарий будет вызываться как "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
Есть еще один поворот к проблеме. Независимо от значения dt (dt = 0, 0,5 с, 2 с), если сценарий вызывается дважды подряд с интервалом времени dt 'между вызовами, компьютер выйдет из спящего режима. Это значение dt ', при котором компьютер просыпается, составляет 20-40 секунд.
Это очень воспроизводимо. Я пробовал использовать два разных устройства для запуска сценария пробуждения с использованием разных утилит wake-on-lan (wake-on-lan и etherwake), и результаты были одинаковыми. Я также посмотрел на волшебные пакеты с помощью tcpdump. Они хорошо отформатированы независимо от того, идет ли пинг-запрос первым или нет.
Я не замечаю здесь чего-то очевидного? Кажется маловероятным недостатком в контроллере Ethernet, что запрос icmp может "блокировать" последующие волшебные пакеты.
Любые мысли по этому поводу (дополнительные тесты и т. Д.) Были бы очень признательны, прежде чем я поговорю с Intel.
С уважением, Йонас
У нас были аналогичные проблемы с WoL на новых картах Intel в Windows 7. Проблема была вызвана функциями драйвера для энергосбережения: PME и EEE.
С драйверами Intel NIC Windows 7 отключает PME (Power Management Event) при завершении работы, что делает WoL непригодным для использования. Включение PME для сетевой карты (сделав это в Advanced вкладка настроек устройства сетевой карты в Device Manager) позволит WoL функционировать.
Вторая функция, реализующая Энергоэффективный Ethernet Стандарт может привести к тому, что WoL будет ненадежным, если рабочая станция долгое время была включена, но простаивала. Вероятно, это произошло из-за слабой совместимости EEE с другим сетевым оборудованием.
Решением было отключить EEE и включить PME для всех сетевых адаптеров, у которых этот параметр был в реестре. Это сценарий PowerShell, который мы используем для этого:
$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')
}
}
}
GUID, используемый в $regkey описан Вот. Имейте в виду, что изменение настроек в этом разделе реестра опасно, так как в худшем случае это может сделать ваши сетевые адаптеры непригодными для использования.
Думаю, я ответил (по крайней мере, частично) на свой вопрос.
Вместо этого попытка использовать Linux в качестве ОС (с живого компакт-диска) решила проблему. Я не мог воспроизвести поведение, описанное в моем вопросе.
Поэтому я подумал, что это проблема с Windows. Однако я загрузился обратно в окна, чтобы посмотреть, могу ли я воспроизвести это поведение, но не смог. Итак, я предполагаю, что это проблема ОС, а не проблема с контроллером Ethernet. Во время тестирования (результаты в моем исходном вопросе) машина работала несколько месяцев без перезапуска, и Windows, вероятно, начала вести себя глупо.