No necesitas instalar ethtool con apt para configurar Wake-on-LAN en ZimaCube con ZimaOS. En el hilo original, el personal de IceWhale aclaró que ethtool ya está incluido en ZimaOS y que Wake-on-LAN normalmente está habilitado de forma predeterminada en ZimaCube.
La confusión surgió al mezclar instrucciones del producto y del sistema operativo. La guía antigua que encontró el usuario estaba escrita para ZimaBoard con CasaOS, donde la instalación de paquetes al estilo Debian puede ser relevante. ZimaOS utiliza un diseño de sistema diferente, por lo que copiar comandos apt install de la documentación de CasaOS no es una opción predeterminada segura.
Por qué el antiguo comando apt no era adecuado para ZimaOS
El usuario intentó seguir una guía de Wake-on-LAN que indicaba instalar ethtool. ZimaOS no ofrece un flujo normal de gestión de paquetes apt para los componentes del sistema, como lo haría un host Debian general.
El personal de IceWhale respondió que la utilidad ya estaba presente. Esa es la primera comprobación correcta: ejecuta ethtool desde el shell compatible de ZimaOS antes de intentar instalar o reemplazar paquetes del sistema.
La guía actual de Wake-on-LAN de ZimaCube también utiliza el comando integrado ethtool en lugar de un paso de instalación mediante apt.
WOL está habilitado de forma predeterminada en ZimaCube, pero verifica todo el proceso
La documentación actual de ZimaCube indica que Wake-on-LAN está habilitado de forma predeterminada. Si no está activo, el comando documentado para Linux es ethtool -s eth0 wol g, seguido de ethtool eth0 para verificar la configuración de activación.
No des por sentado que el nombre de la interfaz siempre es eth0 en todas las instalaciones personalizadas de ZimaOS. Identifica primero la interfaz Ethernet real. La guía actual de ZimaCube también señala que el procedimiento de WOL es compatible con el puerto de 2.5GbE, por lo que la elección del puerto es importante en ese hardware.
La configuración del firmware puede bloquear WOL aunque Linux esté configurado correctamente
Wake-on-LAN requiere más que un indicador de software. La NIC debe recibir alimentación en espera, el firmware debe permitir eventos de activación y la interfaz de red debe conservar el modo de activación adecuado después del apagado.
El procedimiento actual de ZimaCube habilita Wake from PME en la BIOS antes de comprobar Linux. Si un paquete mágico no produce ningún efecto, verifica la configuración de la BIOS y el estado de alimentación antes de cambiar repetidamente ethtool.
La configuración de alimentación de la BIOS de ZimaCube también identifica Wake on LAN como una opción del firmware que debe combinarse con la configuración de ZimaOS.
Añade soluciones de persistencia solo si la configuración realmente se restablece
La guía actual de WOL incluye un ejemplo de servicio de systemd para volver a aplicar wol g después de reiniciar. Puede ser útil cuando un sistema verificado vuelve repetidamente a un estado deshabilitado.
No debería ser el primer paso en un ZimaCube que ya informa correctamente del estado de Wake-on-LAN. Primero reinicia y vuelve a comprobar el valor actual. Añade un mecanismo de persistencia solo si puedes demostrar que la configuración se está perdiendo, y vuelve a validarla después de las actualizaciones de ZimaOS.
Prueba desde la misma LAN antes de solucionar problemas de activación remota
Empieza con un emisor de Wake-on-LAN fiable en la misma subred y utiliza la dirección MAC correcta. Las pruebas locales eliminan del problema la VPN, el reenvío de difusión del router y las políticas de acceso remoto.
Si WOL funciona localmente pero falla de forma remota, probablemente la configuración de ZimaCube no sea el problema principal. En ese punto, investiga cómo llega la herramienta remota a la LAN y si puede enviar un paquete mágico al dominio de difusión correcto.
