Intel 82579LM Gbit Ethernet Controller - pacote mágico (WOL) logo após o ping não estar funcionando

1

Estou passando por um comportamento muito chato e misterioso ao enviar pacotes mágicos (para Wake On LAN) logo após executar ping em um controlador Ethernet GigaBit 82579LM da Intel (o controlador de ethernet integrado do Placa-mãe Intel DQ67SW ).

Então, basicamente, se eu enviar uma solicitação de eco icmp e aguardar um momento dt antes de enviar um pacote mágico, terei o seguinte:

dt < 1 segundo: O computador não vai acordar devido ao pacote mágico

dt > = 1 segundo: O computador acorda como é suposto devido ao pacote mágico

Este script é uma implementação mínima do cenário de que estou falando:

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

O script seria então chamado como "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

Mais uma reviravolta para o problema existe. Independentemente do valor de dt (dt = 0, 0.5s, 2s) se o script for invocado duas vezes seguidas, com um intervalo de tempo entre chamadas, o computador será ativado. Esse valor de dt 'fazendo com que o computador acorde é de 20 a 40 segundos.

É muito reproduzível. Eu tentei usar dois dispositivos diferentes para executar o script wake usando diferentes utilitários wake-on-lan (wake on lan e etherwake) e os resultados são os mesmos. Eu também olhei os pacotes mágicos usando o tcpdump. Eles são bem formatados, independentemente de o pedido de ping ser o primeiro ou não.

Eu estou negligenciando algo óbvio aqui? Parece uma falha improvável em um controlador de ethernet que um pedido icmp poderia "bloquear" para pacotes mágicos subseqüentes.

Qualquer pensamento sobre isso (testes adicionais para realizar etc.) seria muito apreciado antes de eu falar com a Intel.

Atenciosamente Jonas

    
por Wuhtzu 20.09.2012 / 03:17

2 respostas

2

Tivemos problemas semelhantes com o WoL em placas Intel mais novas no Windows 7. O problema estava sendo causado por recursos de driver para economia de energia: PME e EEE

Com os drivers da Intel NIC, o Windows 7 desativa as PMEs ( Power Management Event ) em um desligamento que torna a WoL inutilizável. Habilitar o PME para uma NIC (fazendo isso na guia Advanced das configurações do dispositivo da NIC em Device Manager ) permitiria que o WoL funcionasse.

O segundo recurso que implementa o padrão Ethernet com eficiência energética faria com que o WoL não fosse confiável se uma estação de trabalho fosse ativada por um longo tempo, mas ocioso. Provavelmente, isso ocorreu devido à fraca compatibilidade do EEE com outro hardware de rede.

A solução foi desativar o EEE e habilitar o PME para todos os NICs que tinham essa configuração no registro. Este é o script do PowerShell que usamos para conseguir isso:

$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')
        }
    }
}

O GUID usado em $regkey é descrito aqui . Esteja avisado que modificar configurações nesta chave do registro é perigoso, pois pode tornar suas NICs inutilizáveis, no pior dos casos.

    
por 25.12.2012 / 19:16
0

Acho que respondi (pelo menos parte) da minha própria pergunta.

Experimentar o linux como sistema operacional (via live cd) resolveu o problema. Eu não consegui replicar o comportamento descrito na minha pergunta.

Então eu pensei que era um problema do Windows. Eu, no entanto, reiniciei as janelas para ver se eu ainda conseguia reproduzir o comportamento - e não consegui. Então, meu palpite agora é que ele é um problema do sistema operacional e não um problema com o controlador ethernet. No momento do teste (resulta na minha pergunta original), a máquina estava funcionando há alguns meses sem reiniciar e o Windows provavelmente começou a se comportar de maneira tola.

    
por 11.10.2012 / 09:42