Vous n’avez pas besoin d’installer ethtool avec apt pour configurer le Wake-on-LAN sur un ZimaCube exécutant ZimaOS. Dans le fil de discussion d’origine, le personnel d’IceWhale a précisé que ethtool est déjà inclus dans ZimaOS et que le Wake-on-LAN est normalement activé par défaut sur le ZimaCube.
La confusion venait d’un mélange entre les instructions relatives au produit et celles relatives au système d’exploitation. L’ancien guide trouvé par l’utilisateur concernait le ZimaBoard avec CasaOS, où l’installation de paquets selon la méthode Debian peut être pertinente. ZimaOS repose sur une conception différente. Il n’est donc pas recommandé, par défaut, de copier les commandes apt install de la documentation de CasaOS.
Pourquoi l’ancienne commande apt ne convenait pas à ZimaOS
L’utilisateur a tenté de suivre un guide du Wake-on-LAN qui lui indiquait d’installer ethtool. ZimaOS ne fournit pas un flux de gestion des paquets système classique avec apt, comme le ferait un hôte Debian généraliste.
Le personnel d’IceWhale a indiqué que l’utilitaire était déjà présent. C’est la première vérification à effectuer : exécutez ethtool depuis le shell ZimaOS pris en charge avant d’essayer d’installer ou de remplacer des paquets système.
Le guide actuel du Wake-on-LAN du ZimaCube utilise également la commande intégrée ethtool, plutôt qu’une étape d’installation avec apt.
Le WOL du ZimaCube est activé par défaut, mais vérifiez l’ensemble du chemin
La documentation actuelle du ZimaCube indique que le Wake-on-LAN est activé par défaut. S’il n’est pas actif, la commande Linux documentée est ethtool -s eth0 wol g, suivie de ethtool eth0 pour vérifier le paramètre de réveil.
Ne supposez pas que le nom de l’interface est toujours eth0 dans toutes les installations personnalisées de ZimaOS. Identifiez d’abord l’interface Ethernet réelle. Le guide actuel du ZimaCube précise également que sa procédure WOL prend en charge le port 2,5 GbE ; le choix du port est donc important sur ce matériel.
Les paramètres du micrologiciel peuvent bloquer le WOL même si Linux est correctement configuré
Le Wake-on-LAN nécessite plusieurs éléments, et pas seulement un indicateur logiciel. La carte réseau doit recevoir une alimentation en veille, le micrologiciel doit autoriser les événements de réveil et l’interface réseau doit conserver le mode de réveil approprié après l’arrêt.
La procédure actuelle du ZimaCube active l’option Wake from PME dans le BIOS avant la vérification sous Linux. Si un paquet magique ne produit aucun effet, vérifiez le paramètre du BIOS et l’état d’alimentation avant de modifier plusieurs fois ethtool.
Les paramètres d’alimentation du BIOS du ZimaCube indiquent également que le Wake on LAN est une option du micrologiciel qui doit être associée à la configuration de ZimaOS.
N’ajoutez une solution de persistance que si le paramètre est effectivement réinitialisé
Le guide actuel du WOL inclut un exemple de service systemd permettant de réappliquer wol g après un redémarrage. Cela peut être utile lorsqu’un système vérifié revient régulièrement à un état désactivé.
Ce ne devrait pas être la première étape sur un ZimaCube qui indique déjà que le Wake-on-LAN fonctionne correctement. Commencez par redémarrer, puis vérifiez à nouveau la valeur actuelle. N’ajoutez un mécanisme de persistance que si vous pouvez démontrer que le paramètre est perdu, et vérifiez-le à nouveau après les mises à jour de ZimaOS.
Testez depuis le même réseau local avant de résoudre les problèmes de réveil à distance
Commencez avec un émetteur Wake-on-LAN fiable situé sur le même sous-réseau et utilisez l’adresse MAC correcte. Les tests locaux éliminent du problème le VPN, la redirection des diffusions par le routeur et les règles d’accès à distance.
Si le WOL local réussit, mais que le WOL à distance échoue, le paramètre du ZimaCube n’est probablement pas la cause principale. Examinez alors la manière dont l’outil distant accède au réseau local et vérifiez s’il peut envoyer un paquet magique au domaine de diffusion approprié.
