@Ansuel ti tiro in ballo dato che sei il creatore di questa ottima mod per il DGA4132; penso di aver trovato un problema con la gestione del port forwarding, essendo un profano di OpenWRT non so dire però se si tratta di un difetto pre-esistente o se sia stato introdotto con le varie personalizzazioni da te create (non sono sicuro al 100% che tu sia l'unico coder del progetto ma sto assumendo che sia così).
Mi sono preso un po' di tempo per fare qualche verifica più approfondita sulla questione WoL e mi dispiace ma non mi trovo d'accordo con quanto affermato da
@aezakmi123 (che vorrei comunque nuovamente ringraziare infinitamente per avermi diretto verso la soluzione del mio problema, il motivo di qusto post è infatti solo quello di fare chiarezza sulla questione ed eventualmente risolvere un possibile comportamento anomalo del firmware - sempre che io non sia l'unico a trovarlo anomalo).
Una piccola introduzione; mi aspettavo che anche in questo router, come in quello che ho recentemente dovuto sostituire e in quello prima ancora, per abilitare il WoL da WAN bastasse fare il port forwarding della porta necessaria (solitamente la 9) verso il client desiderato e gestire l'ARP binding dell'indirizzo fisico dell'interfaccia di rete del PC con quello logico. Purtroppo dopo aver fatto entrambe le cose (forwarding via interfaccia web e binding via CLI), il WoL nel mio caso ancora non funzionava, ed è qui che mi è venuto in aiuto aezakmi123 con questo utilissimo link:
https://www.ilpuntotecnico.com/forum/index.php/topic,77325.msg224373.html#msg224373 Detto questo, ci sono delle informazioni sbagliate in giro per il forum, in particolare:
1) Il problema non sta nell'ARP table; il comando "ip neigh add" con l'opzione "permanent" serve infatti proprio a creare una entry "statica" (che non può essere cancellata) nella ARP table del router, e questo è facilmente verificabile lanciando il comando, spegnendo il PC e verificando l'ARP table del router via SSH (proprio tramite il comando "arp").
2) L'indirizzo
logico 192.168.1.254 usato in molte guide/esempi non è un indirizzo di broadcast (quelli finiscono tutti con l'otteto 255) ma un normalissimo indirizzo IP scelto arbitrariamente, escluso dal DHCP pool, non assegnato manualmente a nessun device e bindato all'indirizzo
fisico di broadcast FF:FF:FF:FF:FF:FF; il risultato è che un Magic Packet inviato verso quell'indirizzo viene reinderizzato su TUTTE le interfacce Ethernet collegate al router, e i dispositivi capaci di effettuare il WoL si accendono.
Detto questo, ritengo che il comportamento appena descritto non sia il più desiderabile, invece (imho) il comportamento più corretto è quello di poter risvegliare un singolo dispositivo usando un pacchetto indirizzato all'indirizzo fisico specifico di quel particolare dispositivo (e questo è il risultato che ho ottenuto modificando la lista di comandi fornitami tramite il già menzionato link e sostituendo all'indirizzo IP generico quello specifico del PC che desideravo poter accendere da remoto e all'indirizzo MAC di broadcast l'indirizzo fisico specifico di quello stesso dispositivo; vorrei sottolineare che così facendo il WoL
funziona correttamente).
A questo punto non ero però ancora soddisfatto poichè non mi tornava il motivo per cui fosse necessario modificare da CLI le regole del modulo firewall (che sono le stesse che vengono modificate via interfaccia web quando si creano nuove regole per il port forwarding - e qui arriva la parte interessante
@Ansuel); ho rimosso le regole create tramite CLI dal file /etc/config/firewall, ho ricreato la regola per il port forwarding via web ed ho notato che tale regola era stata creata (sempre in /etc/config/firewall) con indirizzo ip di destinazione (dest_ip) valorizzato a "0.0.0.0"; ho quindi modificato tale valore con l'indirizzo effettivo del PC di destinazione, lanciato un "/etc/init.d/firewall restart" et voilà, il WoL ha ripreso a funzionare correttamente!
Arrivo finalmente al succo della questione (scusate il muro di testo e gli eventuali errori)... è possibile che rispetto alla versione "vanilla" di OpenWRT sia stata introdotta qualche modifica che impedisce la corretta creazione delle regole di forwarding via web inizializzando appunto l'ip di destinazione ad un valore (erroneamente) nullo? Ad esempio, giusto per tirare ad indovinare, la funzionalità di autocompletamente del MAC address durante la creazione delle regole di forwarding è nativa di OpenWRT?
