Não precisa de instalar ethtool com apt para configurar o Wake-on-LAN no ZimaCube com ZimaOS. No tópico original, a equipa da IceWhale esclareceu que o ethtool já está incluído no ZimaOS e que o Wake-on-LAN está normalmente ativado por predefinição no ZimaCube.
A confusão surgiu por se terem misturado instruções relativas ao produto e ao sistema operativo. O guia mais antigo que o utilizador encontrou foi escrito para o ZimaBoard com CasaOS, onde a instalação de pacotes ao estilo Debian pode ser relevante. O ZimaOS utiliza um design de sistema diferente, pelo que copiar comandos apt install da documentação do CasaOS não é uma prática segura por defeito.
Porque é que o antigo comando apt não se aplicava ao ZimaOS
O utilizador tentou seguir um guia de Wake-on-LAN que indicava a instalação do ethtool. O ZimaOS não disponibiliza um fluxo normal de gestão de pacotes apt para componentes do sistema da mesma forma que um anfitrião Debian genérico.
A equipa da IceWhale respondeu que o utilitário já estava presente. Essa é a verificação inicial correta: execute ethtool a partir da shell suportada do ZimaOS antes de tentar instalar ou substituir pacotes do sistema.
O guia atual de Wake-on-LAN do ZimaCube também utiliza o comando integrado ethtool, em vez de uma etapa de instalação com apt.
O WOL do ZimaCube está ativado por predefinição, mas verifique todo o percurso
A documentação atual do ZimaCube indica que o Wake-on-LAN está ativado por predefinição. Se não estiver ativo, o comando documentado do lado do Linux é ethtool -s eth0 wol g, seguido de ethtool eth0 para verificar a definição de ativação.
Não assuma que o nome da interface é sempre eth0 em todas as instalações personalizadas do ZimaOS. Identifique primeiro a interface Ethernet real. O guia atual do ZimaCube também indica que o procedimento de WOL é compatível com a porta 2.5GbE, pelo que a escolha da porta é importante neste hardware.
As definições do firmware podem impedir o WOL mesmo quando o Linux está corretamente configurado
O Wake-on-LAN requer mais do que um único sinalizador de software. A NIC tem de receber alimentação em modo de espera, o firmware tem de permitir eventos de ativação e a interface de rede tem de manter o modo de ativação adequado após o encerramento.
O procedimento atual do ZimaCube ativa a opção Wake from PME na BIOS antes de verificar o Linux. Se um pacote mágico não produzir qualquer efeito, verifique a definição da BIOS e o estado de alimentação antes de alterar repetidamente o ethtool.
As definições de alimentação da BIOS do ZimaCube também identificam o Wake on LAN como uma opção de firmware que tem de ser conjugada com a configuração do ZimaOS.
Adicione soluções de persistência apenas se a definição for realmente reposta
O guia atual de WOL inclui um exemplo de serviço systemd para reaplicar wol g após um reinício. Isto pode ser útil quando um sistema verificado regressa repetidamente a um estado desativado.
Não deve ser o primeiro passo num ZimaCube que já apresenta o Wake-on-LAN corretamente. Primeiro, reinicie e volte a verificar o valor atual. Adicione um mecanismo de persistência apenas se conseguir demonstrar que a definição está a ser perdida e volte a validá-la após as atualizações do ZimaOS.
Teste a partir da mesma LAN antes de diagnosticar a ativação remota
Comece com um emissor de Wake-on-LAN comprovadamente funcional na mesma sub-rede e utilize o endereço MAC correto. Os testes locais eliminam da equação a VPN, o encaminhamento de difusão do router e as políticas de acesso remoto.
Se o WOL local for bem-sucedido, mas o WOL remoto falhar, a definição do ZimaCube provavelmente não é o problema principal. Nesse caso, investigue a forma como a ferramenta remota chega à LAN e se consegue entregar um pacote mágico ao domínio de difusão correto.
