Non è necessario installare ethtool con apt per configurare Wake-on-LAN su ZimaCube con ZimaOS. Nel thread originale, lo staff di IceWhale ha chiarito che ethtool è già incluso in ZimaOS e che Wake-on-LAN è normalmente abilitato per impostazione predefinita su ZimaCube.
La confusione è nata dalla sovrapposizione di istruzioni relative a prodotti e sistemi operativi diversi. La guida più datata trovata dall’utente era stata scritta per ZimaBoard con CasaOS, dove l’installazione di pacchetti in stile Debian può essere pertinente. ZimaOS utilizza un’architettura di sistema diversa, quindi copiare i comandi apt install dalla documentazione di CasaOS non è una scelta predefinita sicura.
Perché il vecchio comando apt non era adatto a ZimaOS
L’utente ha cercato di seguire una guida per Wake-on-LAN che indicava di installare ethtool. ZimaOS non espone un normale flusso di gestione dei pacchetti di sistema tramite apt come avviene su un host Debian generico.
Lo staff di IceWhale ha risposto che l’utility era già presente. Questo è il primo controllo corretto: esegui ethtool dalla shell ZimaOS supportata prima di provare a installare o sostituire pacchetti di sistema.
Anche la guida attuale di Wake-on-LAN per ZimaCube utilizza il comando integrato ethtool anziché una procedura di installazione tramite apt.
WOL è abilitato per impostazione predefinita su ZimaCube, ma verifica l’intero percorso
La documentazione attuale di ZimaCube indica che Wake-on-LAN è abilitato per impostazione predefinita. Se non è attivo, il comando documentato lato Linux è ethtool -s eth0 wol g, seguito da ethtool eth0 per verificare l’impostazione di riattivazione.
Non dare per scontato che il nome dell’interfaccia sia sempre eth0 in ogni installazione personalizzata di ZimaOS. Identifica prima l’interfaccia Ethernet effettiva. La guida attuale di ZimaCube specifica inoltre che la procedura WOL supporta la porta 2.5GbE, quindi la scelta della porta è importante su questo hardware.
Le impostazioni del firmware possono bloccare WOL anche quando Linux è configurato correttamente
Wake-on-LAN richiede più di un semplice flag software. La scheda di rete deve ricevere alimentazione in standby, il firmware deve consentire gli eventi di riattivazione e l’interfaccia di rete deve conservare la modalità di riattivazione appropriata dopo lo spegnimento.
La procedura attuale per ZimaCube abilita Wake from PME nel BIOS prima di controllare Linux. Se un magic packet non produce alcun effetto, verifica l’impostazione del BIOS e lo stato di alimentazione prima di modificare ripetutamente ethtool.
Anche le impostazioni di alimentazione del BIOS di ZimaCube identificano Wake on LAN come un’opzione del firmware che deve essere abbinata alla configurazione di ZimaOS.
Aggiungi soluzioni per la persistenza solo se l’impostazione viene effettivamente reimpostata
La guida attuale per WOL include un esempio di servizio systemd per riapplicare wol g dopo il riavvio. Può essere utile quando un sistema verificato torna ripetutamente a uno stato disabilitato.
Non dovrebbe essere il primo passaggio su uno ZimaCube che segnala già correttamente lo stato di Wake-on-LAN. Riavvia prima il dispositivo e controlla nuovamente il valore attuale. Aggiungi un meccanismo di persistenza solo se puoi dimostrare che l’impostazione viene persa, quindi verificalo nuovamente dopo gli aggiornamenti di ZimaOS.
Esegui il test dalla stessa LAN prima di diagnosticare la riattivazione da remoto
Inizia con un mittente Wake-on-LAN funzionante sulla stessa sottorete e utilizza l’indirizzo MAC corretto. Il test locale elimina dal problema VPN, inoltro broadcast del router e criteri di accesso remoto.
Se il WOL locale funziona ma quello remoto no, probabilmente l’impostazione di ZimaCube non è la causa principale. A questo punto verifica in che modo lo strumento remoto raggiunge la LAN e se riesce a inviare un magic packet al dominio broadcast corretto.
