martin-ger/esp_wifi_repeaterUn router NAT WiFi completamente funzionale (e ora anche un ripetitore WiFi)
Un router NAT WiFi completamente funzionale (e ora anche un ripetitore WiFi, alias bridge L2)
NOVITÀ 2026: 10 anni dopo la prima release è finalmente diventato ciò che ha sempre preteso di essere: un vero ripetitore WiFi. Per non rompere alcun documento e collegamento esistente, l'edizione standard rimane la ben nota versione router NAT con tutte le funzionalità avanzate. Ma se sei interessato a un vero bridge L2 ridotto, guarda sotto nella sezione ESP8266 WiFi Repeater - L2 bridge.
Questa è un'implementazione di un router NAT WiFi su esp8266 e esp8285. Include anche il supporto per un firewall di filtraggio pacchetti con ACL, mapping delle porte, modellamento del traffico, hook per monitoraggio remoto (o packet sniffing), un'interfaccia di gestione MQTT, interazione GPIO semplice e gestione dell'alimentazione. Per una configurazione con più router in una mesh per coprire un'area più ampia, è stata inclusa una nuova modalità "Automesh".
Se stai cercando un modo per integrare la funzionalità NAT nel tuo progetto Arduino - vedi qui .
EPS32 NAT Router è il progetto avanzato per ESP32.
Gli scenari di utilizzo tipici includono:
Per impostazione predefinita, l'ESP agisce come STA e come soft-AP e inoltra trasparentemente qualsiasi traffico IP attraverso di esso. Poiché utilizza NAT, non sono richieste voci di routing né sul lato della rete né sulle stazioni connesse. Le stazioni vengono configurate tramite DHCP per impostazione predefinita nella rete 192.168.4.0/24 e ricevono l'indirizzo del risponditore DNS dalla rete WiFi esistente.
Le misurazioni mostrano che può raggiungere circa 5 Mbps in entrambe le direzioni, quindi anche lo streaming è possibile.
Alcuni dettagli sono spiegati in questo video.
Per il flashing diretto sul dispositivo utilizzare il Web-Installer.
L'esp_wifi_repeater si avvia con la seguente configurazione predefinita:
Dopo il primo avvio (o reset di fabbrica) offrirà una rete WiFi con un AP aperto e ssid "MyAP". Non tenta ancora di riconnettersi automaticamente a un AP uplink (poiché non conosce un ssid o password validi).
Connettiti a questa rete WiFi e fai la configurazione di base tramite una semplice interfaccia web o la configurazione completa con tutte le opzioni tramite la console.
L'interfaccia web consente la configurazione di tutti i parametri necessari per la funzionalità di inoltro di base. Grazie a rubfi per il lavoro principale su questo: https://github.com/rubfi/esp_wifi_repeater/ . Punta il browser su "http://192.168.4.1". Dovrebbe apparire questa pagina:
Per prima cosa inserisci i valori appropriati per la rete WiFi uplink, le "Impostazioni STA". Usa la password "none" per reti aperte. Spunta la casella "Automesh" se e solo se vuoi davvero usare la modalità automesh. Clicca "Connetti". L'ESP si riavvia e si collegherà al tuo router WiFi. Il LED di stato dovrebbe lampeggiare dopo alcuni secondi.
Se hai selezionato automesh, hai finito con la configurazione. Non è necessario configurare le "Impostazioni Soft AP" poiché in modalità automesh queste impostazioni sono identiche alle "Impostazioni STA". Lo stesso ssid sarà offerto da tutti i ripetitori ESP connessi.
Se non stai usando automesh, puoi ora ricaricare la pagina e cambiare le "Impostazioni Soft AP". Clicca "Imposta" e l'ESP si riavvia di nuovo. Ora è pronto per inoltrare il traffico attraverso il Soft AP appena configurato. Tieni presente che queste modifiche influiscono anche sull'interfaccia di configurazione, cioè per fare ulteriori configurazioni, connettiti all'ESP attraverso una delle reti WiFi appena configurate. Per l'accesso tramite il Soft AP, ricorda l'indirizzo della rete Soft AP se lo hai cambiato (l'ESP ha sempre l'indirizzo x.x.x.1 in questa rete).
Se vuoi, puoi spuntare la casella "blocca" e cliccare "Blocca". Ora la configurazione non può più essere modificata senza prima sbloccarla con la password della rete WiFi uplink (definisci una anche se la rete è aperta).
Se vuoi inserire caratteri non ASCII o speciali nell'interfaccia web devi usare la codifica esadecimale in stile HTTP come "My%20AccessPoint". Questo risulterà in una stringa "My AccessPoint". Con questa codifica esadecimale puoi inserire qualsiasi valore di byte desideri, tranne 0 (per ragioni interne C).
Se hai commesso un errore e hai perso tutto il contatto con l'ESP, puoi comunque usare la console seriale per recuperarlo ("reset factory", vedi sotto).
La configurazione avanzata deve essere eseguita tramite la riga di comando sull'interfaccia della console. Questa console è disponibile sia tramite la porta seriale a 115200 baud che tramite la porta TCP 7777 (es. "telnet 192.168.4.1 7777" da una STA connessa).
Usa i seguenti comandi per una configurazione iniziale:
Ancora, se vuoi inserire caratteri non ASCII o speciali puoi usare la codifica esadecimale in stile HTTP (es. "My%20AccessPoint") o, solo sulla CLI, come scorciatoia citazioni in stile C con backslash (es. "My\ AccessPoint"). Entrambi i metodi risulteranno in una stringa "My AccessPoint".
La riga di comando comprende molti più comandi:
Abbastanza per farlo funzionare in quasi tutti gli ambienti.
La maggior parte dei comandi set sono efficaci solo dopo save e reset.
Qualsiasi parte di un input della riga di comando dopo un singolo "#" fino alla fine della riga sarà trattata come commento e ignorata.
Nella configurazione predefinita, GPIO2 è configurato per pilotare un LED di stato (collegato a GND) con le seguenti indicazioni:
Con "set status_led numeroGPIO" il pin GPIO può essere cambiato (qualsiasi valore > 16, es. "set status_led 255" disabilita completamente il LED di stato). Quando configurato su GPIO1, funziona con il LED blu integrato sulle schede ESP-01. Tuttavia, poiché GPIO1 è anche il pin UART-TX, ciò significa che la console seriale non funziona. La configurazione è quindi limitata all'accesso di rete.
Se porti a basso un GPIO selezionato per più di 3 secondi, il ripetitore eseguirà un reset di fabbrica e riavvierà con la configurazione predefinita. Con "set hw_reset numeroGPIO" il pin GPIO può essere cambiato (qualsiasi valore > 16, es. "set hw_reset 255" disabilita la funzionalità di reset di fabbrica HW).
Per molti moduli, inclusi ESP-01 e NodeMCU, probabilmente è una buona idea usare GPIO 0 per questo, poiché viene comunque utilizzato. Tuttavia, non è il pin predefinito, poiché potrebbe interferire con il pull down durante il flashing. Pertanto, se vuoi utilizzare un pulsante esistente su GPIO 0 per il reset di fabbrica HW, configuralo con "set hw_reset 0" e "save" dopo il flashing. Un reset di fabbrica attivato dal pin HW NON resetta il numero GPIO hw_reset configurato ("reset factory" dalla console lo farà).
Per consentire ai client della rete esterna di connettersi a una porta del server sulla rete interna, le porte devono essere mappate. Una porta esterna viene mappata su una porta interna di un indirizzo IP interno specifico. Usa il comando "portmap add" per questo. Le mappature delle porte possono essere elencate con il comando "show" e vengono salvate con la configurazione corrente.
Tuttavia, per assicurarsi che il dispositivo previsto sia in ascolto su un determinato indirizzo IP, è necessario garantire che questi dispositivi abbiano lo stesso indirizzo IP una volta riavviati. Per ottenere ciò, è possibile configurare indirizzi IP fissi nei dispositivi o l'ESP deve ricordare i suoi lease DHCP. Questo può essere ottenuto con il comando "save dhcp". Salva lo stato corrente e tutti i lease DHCP, in modo che vengano ripristinati dopo il riavvio. I lease DHCP possono essere elencati con il comando "show stats".
Il supporto per WPA2 Enterprise (PEAP) è stato ora incluso nel progetto. Consente un "convertitore" che traduce una rete WPA2 Enterprise con autenticazione PEAP in una rete WPA2-PSK. Questo risolve un problema comune, specialmente in ambienti universitari: la rete WiFi locale è una rete WPA2 Enterprise con autenticazione PEAP-MSCHAPv2. Un esempio molto prominente è la rete "eduroam" disponibile in molte università in tutto il mondo. Il problema è che molti dispositivi IoT non possono gestire l'autenticazione WPA2 Enterprise. Quindi lo sviluppo e le demo sono difficili. Ciò che è molto utile è un "convertitore" che si collega alla rete WPA2 Enterprise e offre una rete WPA-PSK più semplice ai suoi client.
Per usarlo, imposta i seguenti parametri di configurazione: ssid, use_peap, peap_identity, peap_username e peap_password (non è necessario il solito parametro password). Questa configurazione deve essere eseguita (e salvata) tramite CLI e non è disponibile nell'interfaccia web.
Il codice attualmente non controlla il certificato del server RADIUS. È vulnerabile ad attacchi MITM, quando qualcuno configura un AP falso e un server RADIUS. Sebbene la password non venga inviata in chiaro, il MSCHAPv2 utilizzato è noto per essere compromesso. Inoltre, sii consapevole del fatto che l'ESP8266 ora contiene la password della tua rete aziendale. Tutto il traffico inoltrato da esso può ora essere correlato dall'amministratore di rete al tuo account. Non abusarne e offrirlo a persone non fidate, ad esempio configurando una rete aperta. E anche quando il dispositivo è bloccato, la password della rete aziendale può essere estratta tramite porta seriale dalla flash dell'ESP in chiaro.
A volte potresti voler utilizzare diversi esp_wifi_repeater in serie o una mesh per coprire una distanza o un'area più ampia. Generalmente, questo può essere fatto senza problemi con router NAT, in realtà avrai diversi livelli di NAT. Tuttavia, ciò significa che la connettività è limitata: tutti i nodi possono parlare con Internet, ma generalmente non c'è connettività IP diretta tra i nodi. E, naturalmente, la larghezza di banda disponibile diminuisce con il numero di salti necessari. Ma gli utenti hanno segnalato che anche 5 esp_wifi_repeater in serie funzionano abbastanza bene.
In una tale configurazione, la configurazione è un'attività piuttosto dispendiosa in termini di tempo e soggetta a errori. Per semplificare, l'esp_wifi_repeater ora ha una nuova modalità: "Automesh". Basta configurare l'SSID e la password e attivare "automesh". (tramite CLI con "set automesh 1" o sull'interfaccia web semplicemente selezionando la casella). Questo farà quanto segue:Ogni esp_wifi_repeater configurato in questo modo offrirà automaticamente una rete WiFi sull'AP con lo stesso SSID/password a cui è connesso. I client possono utilizzare le stesse impostazioni WiFi per la rete originale o per quelle ripetute. Ogni esp_wifi_repeater configurato con "automesh" cercherà prima il miglior altro AP a cui connettersi. Questo è quello più vicino alla rete WiFi originale e con la migliore potenza del segnale (RSSI).
La potenza del segnale è facile da misurare con una scansione, ma quale è quello più vicino alla rete WiFi originale quando si vedono diversi AP con lo stesso SSID? Pertanto il protocollo utilizza un trucco un po' sporco: gli esp_wifi_repeater in modalità "automesh" manipolano il loro BSSID (in realtà, secondo lo standard IEEE 802.11 questo è l'"ESSID" in quanto è un AP, ma l'SDK lo chiama "BSSID"), cioè l'indirizzo MAC della loro interfaccia AP, che viene inviato con ogni beacon frame circa 10 volte al secondo. Usa il formato: 24:24:mm:rr:rr:rr. "24:24" è semplicemente l'identificatore univoco di un ripetitore (c'è una probabilità minima che questo collida con il MAC di un AP reale, ma possiamo trascurare ciò, poiché possiamo cambiare quel prefisso se realmente necessario). "mm" indica il "mesh level", cioè la distanza in hop dalla rete WiFi originale. Gli ultimi tre "rr:rr:rr" sono solo numeri casuali per distinguere i vari ESP. L'AP originale mantiene il suo BSSID, cioè quello senza il prefisso "24:24" viene riconosciuto come root, chiamato mesh level 0.
Ora ogni esp_wifi_repeater può apprendere quale altro esp_wifi_repeater è il più vicino alla rete WiFi originale, può connettersi a quello e scegliere il proprio BSSID di conseguenza. Anche l'indirizzo IP della rete interna viene regolato in base al mesh level: 10.24.m.0. Questo crea un albero (un mesh molto speciale) con l'AP WiFi originale come radice e nodi ripetitori su diversi mesh level (in realtà, funziona in modo simile allo Spanning Tree Protocol (STP) sul livello di collegamento o al routing sul livello di rete usando un protocollo Distance Vector). Non appena viene rilevata una perdita del collegamento uplink, la configurazione viene riavviata. Questo dovrebbe evitare loop, poiché durante la (ri-)configurazione non vengono inviati nemmeno beacon con un BSSID.
Per comodità, l'esp_wifi_repeater dopo la configurazione "automesh" tenta prima di verificare se può connettersi a un AP uplink. Se questo fallisce, anche quando è stato trovato un AP con l'SSID corretto, presume che l'utente abbia commesso un errore con la password e ripristina le impostazioni di fabbrica. Dopo essersi connesso con successo una volta, presumerà che la configurazione sia corretta e continuerà a provare dopo la perdita di connessione o il ripristino per tutto il tempo necessario (per evitare un attacco DOS con un AP configurato male).
Se c'è più di un ESP nel raggio d'azione, potrebbe esserci un compromesso tra un percorso "cattivo" più breve e un percorso "buono" più lungo (buono e cattivo in termini di qualità del collegamento). Il parametro am_threshold determina cosa è una connessione cattiva: se l'RSSI in una scansione è inferiore a questa soglia, una connessione è cattiva e viene preferito un percorso con un hop in più. Cioè, dato am_threshold uguale a 85 e ci sono due nodi automesh rilevati nella scansione: A con livello 1 e RSSI -88 dB e B con livello 2 e RSSI -60 dB, allora un collegamento ad A è considerato troppo cattivo (-88 dB < -am_threshold) e B è preferito. Il nuovo nodo diventerà un nodo di livello 3 con collegamento uplink tramite B. am_threshold è dato come un valore positivo ma significa un dB negativo. Un valore più piccolo è meglio.
Se vuoi ottenere maggiori informazioni sulla topologia di una rete automesh, potresti considerare di connettere tutti i nodi a un broker MQTT e far loro pubblicare il topic "Topology" (vedi sotto). Se ora ti iscrivi a "/WiFi/+/system/Topology" riceverai tutte le informazioni sui nodi e sui collegamenti, inclusi gli RSSI (degli ESP connessi) di cui hai bisogno per ricostruire il grafo completo e rilevare collegamenti deboli nel mesh. Il topic TopologyInfo contiene la seguente struttura JSON, che può essere utilizzata per ricostruire un grafo completo di una rete automesh:``` { "nodeinfo" { "id":"ESP_07e37e", "ap_mac":"24:24:01:72:c7:f9", "sta_mac":"60:01:bc:07:e3:7e", "uplink_bssid":"00:1a:54:93:23:0a", "ap_ip":"10.24.1.1", "sta_ip":"192.168.178.33", "rssi":"-66", "mesh_level":"1", "no_stas":"2" }, "stas":[ {"mac":"5c:cf:45:11:7f:13","ip":"10.24.1.2"}, {"mac":"00:14:22:76:99:c5","ip":"10.24.1.3"} ] }
Utilizzando i due parametri _am_scan_time_ e _am_sleep_time_ la gestione dell'alimentazione può essere implementata in modalità automesh, se hai collegato GPIO16 a RST. Dopo l'avvio, l'esp_wifi_repeater esegue una scansione degli AP uplink disponibili per _am_scan_time_ secondi. Se non ne trova alcuno, entra in deepsleep per _am_sleep_time_ secondi e riprova dopo il riavvio (il valore predefinito è 0 = disabilitato per entrambi i parametri).
# Monitoraggio
Dalla console è possibile avviare un servizio di monitoraggio ("monitor on [portno]"). Questo servizio rispecchia il traffico della rete interna in formato pcap su un flusso TCP. Ad esempio, con "netcat [external_ip_of_the_repeater] [portno] | sudo wireshark -k -S -i -" da un computer nella rete esterna è ora possibile osservare il traffico nella rete interna in tempo reale. Utilizza questo ad esempio per osservare con quali siti internet i tuoi client interni stanno comunicando. Tieni presente che questo almeno raddoppia il carico sull'esp e sulla rete WiFi. Sotto carico elevato, ciò potrebbe causare il troncamento o addirittura la perdita di alcuni pacchetti nella sessione di monitoraggio. ATTENZIONE: lasciare questa porta aperta è un potenziale problema di sicurezza. Chiunque dalle reti locali può connettersi e osservare il tuo traffico.
# Firewall
Il router ESP ha un firewall di base integrato. Le ACL (Access Control Lists) possono essere applicate all'interfaccia SoftAP. Questo è un cardine nella sicurezza IoT, quando il router viene utilizzato per portare altri dispositivi IoT in internet. Può essere utilizzato per impedire, ad esempio, che dispositivi IoT di terze parti "chiamino casa", vengano usati come bot malware, e per proteggere la tua rete domestica con PC, tablet e telefoni dall'essere visibili ai dispositivi di home automation.
Le quattro liste ACL sono denominate "from_sta", "to_sta", "from_ap" e "to_ap" per i pacchetti in entrata e in uscita su entrambe le interfacce ("sta" indica le interfacce verso i client connessi, "ap" l'interfaccia verso l'AP uplink). Le ACL sono definite in "stile CISCO IOS".
Il seguente esempio è utile per una sottorete guest. Consente l'accesso a internet ma non a nessun altro indirizzo locale (usa il tuo intervallo di rete locale per l'indirizzo xx.xx.xx.xx). Questo insieme di regole consente i broadcast locali in uscita (per DHCP) e UDP 53 (DNS), qualsiasi altro pacchetto verso la sottorete del router upstream verrà bloccato, tutti gli altri pacchetti possono passare a internet:```
acl from_sta clear
acl from_sta IP any 255.255.255.255 allow
acl from_sta UDP any any any 53 allow
acl from_sta IP any xx.xx.xx.xx/24 deny
acl from_sta IP any any allow
Il prossimo esempio è più restrittivo ed è utile quando si pianifica una sottorete IoT con accesso molto limitato all'AP dell'ESP. Permetterà anche broadcast locali in uscita (per DHCP), UDP 53 (DNS) e TCP 1883 (MQTT) a un broker locale, ma tutti gli altri pacchetti saranno bloccati, incluso l'accesso arbitrario a Internet (puoi adattare la quarta istruzione secondo le tue esigenze per abilitare altri host):``` acl from_sta clear acl from_sta IP any 255.255.255.255 allow acl from_sta UDP any any any 53 allow acl from_sta TCP any any 192.168.0.0/16 1883 allow acl from_sta IP any any deny
Le ACL per la direzione "to_sta" possono essere definite, ma di solito non è necessario, poiché la direzione inversa è abbastanza ben protetta dal traffico non sollecitato grazie alla traslazione NAT.
Le ACL consistono in regole di filtro che vengono elaborate per ogni pacchetto. Ogni regola è composta da un protocollo (IP, TCP o UDP), indirizzo/porta di origine, indirizzo/porta di destinazione, oltre a un'azione "allow" o "deny". Nel caso di IP semplice, vengono forniti solo gli indirizzi, non le porte. Le regole IP includono pacchetti TCP e UDP. Gli indirizzi possono essere forniti come indirizzi di sottorete nella notazione "/", es. 192.168.178.0/24. Inoltre, "any" può essere usato come wildcard, corrispondendo a qualsiasi indirizzo o numero di porta. Una regola è definita dal comando "acl":
- acl [from_sta|to_sta|from_ap|to_ap] [TCP|UDP|IP] _src-ip_ [_src_port_] _desr-ip_ [_dest_port_] [allow|deny|allow_monitor|deny_monitor]
Le regole vengono elaborate dall'alto verso il basso nell'ordine in cui appaiono nell'elenco. La prima regola che corrisponde a un pacchetto viene applicata e determina se un pacchetto è consentito (e inoltrato) o negato (e scartato). Ciò significa: casi speciali prima, regole generali alla fine. Se ci sono regole in un'ACL, tutti i pacchetti che non corrispondono a nessuna regola vengono negati per impostazione predefinita. Pertanto, l'ultima regola "from_sta IP any any deny" nell'esempio precedente non è realmente necessaria, poiché è comunque l'impostazione predefinita. Se un'ACL è vuota, tutti i pacchetti sono consentiti.
La definizione delle regole ACL funziona anch'essa dall'alto verso il basso: una nuova regola viene sempre aggiunta alla fine di un elenco. Per modificare un'ACL, è necessario prima cancellarla completamente (acl from_sta clear) e poi ricostruirla. Le ACL vengono salvate con la configurazione. "show acl" stamperà le ACL più le statistiche sul numero di hit per ogni regola e il numero complessivo di pacchetti consentiti e negati.
Con il comando "set acl_debug 1" viene stampata sulla console una sintesi di tutti i pacchetti negati. Inoltre, un argomento MQTT può pubblicare questa sintesi. Ciò può essere utilizzato per la configurazione del firewall per determinare quali regole sono necessarie per far funzionare i dispositivi collegati. Fornisce anche un indizio se si verifica traffico imprevisto (e viene negato).
Per un'analisi più approfondita è possibile utilizzare il servizio di monitoraggio (anche i pacchetti negati vengono segnalati al monitor prima di essere scartati). Quando il monitor viene avviato con il comando "monitor acl _port_", le ACL possono essere utilizzate come filtri online. Tutte le regole definite come "allow_monitor" invece di "allow" e "deny_monitor" invece di "deny" vengono elaborate come al solito, consentendo l'inoltro di un pacchetto, ma inviano anche il pacchetto al monitor. Pertanto, un elenco di regole che essenzialmente "allow" o "allow_monitor" tutti i pacchetti ha comunque senso, poiché può essere utilizzato per selezionare già durante il tempo di cattura quale pacchetto deve essere registrato. Ad esempio, un elenco:```
acl from_sta clear
acl from_sta IP 192.168.0.0/16 any allow_monitor
acl from_sta IP any any allow
acl to_sta clear
acl to_sta IP any 192.168.0.0/16 allow_monitor
cl to_sta IP any any allow
will allow all packets and also select all packets for monitoring that go from a station to the 192.168.0.0/16 (local)subnet and from the 192.168.0.0/16 to a station. Of course such a filter can be applied also after the capture to a full monitoring trace, but if you already know, what you are looking for, these online filters will help to reduce monitoring overhead drastically. It can also be used to debug all deny firewall rules by simply using "deny_monitor" instead of deny.
By default the AP interface is NATed, so that any node connected to the AP will be able to access the outside world transparently via the ESP's STA interface. So no further action is required, if you are not a real network nerd.
For those of you that are really interested in further network config: the ESP's lwip IPv4 stack has been enhanced for this project with support for static routes: "show route" displays the routing table with all known routes, including the links to the connected network interfaces (the AP and the STA interface). Routing between these two interfaces works without further configuration. Additional routes to other networks can be set via the "route add network gateway" command, known from Linux boxes or routers. A "save" command writes the current state of the routing table to flash configuration.
Here is a simple example of what can be done with static routes. Given the following network setup with two ESPs connected with the STA interfaces via a central home router:``` | 10.0.1.1 AP-ESP1-STA 192.168.1.10 | <-> |Home Router| <-> | 192.168.1.20 STA-ESP2-AP 10.0.2.1|
Ogni ESP ha una seconda rete dietro il suo AP con indirizzi di rete differenti: 10.0.1.0/24 e 10.0.2.0/24. ESP1 può eseguire il ping verso ESP2 all'indirizzo 192.168.1.20 ma non verso 10.0.2.1, poiché non sa di poterlo raggiungere tramite 192.168.1.20. Questo cambia se si aggiungono due route statiche. Su ESP1:```
route add 10.0.2.0/24 192.168.1.20
e su ESP2:``` route add 10.0.1.0/24 192.168.1.10
Ora un "ping 10.0.2.1" su ESP1 avrà successo. Viene inviato a 192.168.1.20 e poi risposto da ESP2.
Ora in ogni rete si connette un client aggiuntivo (con indirizzi 10.0.1.2 e 10.0.2.2):```
| STA1 10.0.1.2 | <-> | 10.0.1.1 ESP1 192.168.1.10 | <-> |Home Router| <-> | 192.168.1.20 ESP2 10.0.2.1| <-> | STA2 10.0.2.2 |
Ora anche il client STA1 con indirizzo locale 10.0.1.2 può eseguire il ping verso STA2 con 10.0.2.2 poiché invia la sua richiesta prima al suo router predefinito ESP1 e questo sa che tutti i pacchetti verso un indirizzo 10.0.2.0/24 devono essere inoltrati a 192.168.1.20. Lì, l'ESP2 sa come inviarli a STA2. Lo stesso vale per la risposta nell'altra direzione.
Questo permette di configurare una topologia multi-stella di ESP, dove ogni ESP e i suoi client STA possono raggiungersi direttamente (senza bisogno di portmap). La configurazione delle route necessarie può essere un po' dolorosa - ma un buon esercizio di networking. Il prossimo passo sarebbe portare un protocollo di routing dinamico come RIP sull'ESP...
Impostando upstream_kbps e downstream_kbps su un valore diverso da 0 (0 è il default), è possibile limitare il bitrate massimo dell'AP dell'ESP. Questo valore è un limite che si applica al traffico di tutti i client connessi. I pacchetti che supererebbero il bitrate definito vengono scartati. Il modellatore di traffico utilizza l'algoritmo "Token Bucket" con una dimensione del bucket attualmente pari a quattro volte il bitrate al secondo, consentendo raffiche quando non c'era traffico prima.
Dalla versione 1.3 il router ha un client MQTT integrato (grazie a Tuan PM per la sua libreria https://github.com/tuanpmt/esp_mqtt). Questo può aiutare a integrare il router/ripetitore nell'IoT. Un sistema di home automation può ad es. prendere decisioni basate sulle informazioni sulle stazioni attualmente associate, può accendere e spegnere i ripetitori (ad es. in base a una pianificazione temporale), o può semplicemente essere utilizzato per monitorare il carico. Il router può essere connesso a un broker MQTT locale o a un broker disponibile pubblicamente nel cloud. Tuttavia, attualmente non supporta la crittografia TLS.
Di default il client MQTT è disabilitato. Può essere abilitato impostando il parametro di configurazione "mqtt_host" su un hostname diverso da "none". Per configurare MQTT è possibile impostare i seguenti parametri:
I parametri MQTT possono essere visualizzati con il comando "show mqtt".
Il router può pubblicare periodicamente i seguenti topic di stato (ogni mqtt_interval):
Inoltre il ripetitore può pubblicare su base evento:
Come LWT e report di stato, il ripetitore pubblica:
Il router può essere configurato utilizzando i seguenti topic:
Se ora si desidera che il router pubblichi ad es. solo Vdd, il suo IP e l'output dei comandi, impostare mqtt_mask su 0x0001 | 0x0002 | 0x0040 (= "set mqtt_mask 0043").
L'esp_wifi_repeater ora include il supporto per una scheda di rete Ethernet ENC28J60 collegata via SPI (Grazie ad Andrew Kroll https://github.com/xxxajk per il suo grande lavoro per farlo funzionare correttamente), se si attiva l'opzione di compilazione HAVE_ENC28J60 in "user_config.h". L'interfaccia Ethernet supporterà circa 1 Mbps quando l'ESP funziona a 160 MHz. Attivare l'interfaccia AP e utilizzare Ethernet come uplink trasformerà l'esp_wifi_repeater in un AP economico per dispositivi WiFi (ad es. altri ESP).
La connessione tramite SPI deve essere:``` NodeMCU/Wemos ESP8266 ENC28J60
D6 GPIO12 <---> MISO
D7 GPIO13 <---> MOSI
D5 GPIO14 <---> SCLK
D8 GPIO15 <---> CS
D1 GPIO5 <---> INT
D2 GPIO4 <---> RESET
Q3/V33 <---> 3.3V
GND <---> GND
I cavi corti e saldati funzionano meglio. Inoltre avrai bisogno di un transistor per disaccoppiare GPIO15, altrimenti il tuo ESP non si avvierà più, vedi: https://esp8266hints.wordpress.com/category/ethernet/ . Inoltre, è importante avere un buon alimentatore: l'ENC28j60 necessita di circa 160mA quando attivo. Per me fallisce se provo a usare i 3.3V dalla scheda ESP.
Ora puoi configurare la nuova interfaccia Ethernet:
- set eth_enable [0|1]: abilita/disabilita una scheda di rete ENC28J60 sul bus SPI (default: 0 - disabilitato)
- set eth_ip _indirizzo-ip_: imposta un indirizzo IP statico per l'interfaccia ETH
- set eth_netmask _netmask_: imposta una netmask statica per l'interfaccia ETH
- set eth_gw _gw-addr_: imposta un indirizzo gateway statico per l'interfaccia ETH
- set eth_dhcpd [0|1]: avvia un server DHCP per indirizzi IP dinamici sull'interfaccia ETH (default: 0 - disabilitato)
# Power Management
Il ripetitore monitora la sua tensione di alimentazione corrente (mostrata nel comando "show stats"). Questo funziona solo se il 107° byte in esp_init_data_default.bin, chiamato vdd33_const, è impostato a 255(0xFF). Il modo più semplice per ottenere ciò è scrivere esp_init_data_default_v08_vdd33.bin nel flash (vedi sotto).
Se _vmin_ (in mV, default 0) è impostato su un valore > 0 e la tensione di alimentazione scende al di sotto di questo valore, entrerà in modalità di sleep profondo per _vmin_sleep_ secondi. Se hai collegato GPIO16 a RST (cosa difficile da saldare su un ESP-01) si riavvierà dopo questo intervallo, proverà a riconnettersi e continuerà le sue misurazioni. Se _vmin_ viene salvato con la configurazione, dormirà ripetutamente finché la tensione di alimentazione non supera la soglia. Queste impostazioni sono particolarmente (solo?) utili se hai alimentato l'ESP con una batteria (al litio) senza protezione da scarica eccessiva. Allora un valore di 2900mV-3000mV è probabilmente utile, poiché riduce il consumo energetico dell'ESP al minimo e hai molto più tempo per ricaricare o sostituire la batteria prima del danneggiamento. Questo ha senso solo se hai l'ESP collegato direttamente alla batteria. Se hai logica aggiuntiva, questa continuerà a scaricare la batteria.
Puoi mandare l'ESP in sleep manualmente una volta usando il comando "sleep".
Attenzione: Se salvi un valore _vmin_ superiore alla tensione di alimentazione massima nel flash, il ripetitore si spegnerà immediatamente ogni volta dopo il riavvio. Dovrai quindi cancellare l'intera configurazione scrivendo blank.bin (o qualsiasi altro file) all'indirizzo 0x0c000.
# Ripetitore WiFi - Bridge L2
Il progetto offre ora due modalità operative distinte: **Router NAT** e **Bridge di Livello 2** (denominata "Modalità ripetitore"). Sebbene entrambe le modalità estendano la copertura di rete, differiscono fondamentalmente nel modo in cui gestiscono il traffico e l'identità dei dispositivi.
### Modalità Router NAT (Standard)
In questa modalità, come descritto sopra, il dispositivo agisce come un gateway standard. Crea una nuova sottorete ed esegue la traduzione degli indirizzi di rete (NAT) per tutti i dispositivi collegati al suo Access Point (AP).
* **Isolamento della sottorete**: I client connessi si trovano su una sottorete privata (es. 192.168.4.x) e sono protetti dalla rete primaria.
* **Identità del traffico**: Tutto il traffico dai client appare al router principale come se provenisse dall'indirizzo IP/MAC dell'ESP8266 stesso.
* **Semplicità**: Non richiede configurazioni speciali sul router a monte ed è compatibile con praticamente tutte le reti Wi-Fi standard.
* **Limitazione**: I dispositivi sulla rete primaria non possono avviare facilmente connessioni ai dispositivi dietro il ripetitore a causa della barriera NAT, a meno che non si utilizzi il port forwarding.
### Modalità Bridge di Livello 2 (Variante "Ripetitore")
Questa modalità implementa un bridge trasparente di Livello 2 (livello di collegamento dati). L'ESP8266 estende la rete primaria esistente anziché creare una sottorete secondaria.
* **Bridging trasparente**: L'ESP8266 fa da ponte per il traffico a livello di frame Ethernet. I client connessi ricevono indirizzi IP direttamente dal server DHCP della rete primaria (tramite DHCP snooping/relay).
* **Rete unificata**: Tutti i dispositivi (sia sul ripetitore che sul router principale) esistono sullo stesso dominio di broadcast L2.
* **Visibilità dei dispositivi**: I dispositivi dietro il ripetitore mantengono le loro identità MAC e IP originali sulla rete principale. Ciò consente ai protocolli di scoperta locale (come mDNS/Bonjour, UPnP o discovery di rete) di funzionare senza problemi su tutta la rete.
* **Complessità**: Richiede una gestione avanzata, come Proxy ARP e DHCP snooping, per garantire che la rete a monte instradi correttamente il traffico verso i client "nascosti" collegati tramite il ripetitore.
* **Caso d'uso**: Ideale quando è richiesta la scoperta dei dispositivi (ad esempio, controllare una stampante o un dispositivo smart home tramite un'app telefonica) su tutta la rete.
La modalità ripetitore ha meno funzionalità: routing, port mapping e DHCP non sono necessari, ACL e Automesh non hanno molto senso, così come il monitoraggio di rete tramite pcap. Quindi tutte queste funzionalità non sono disponibili in modalità ripetitore. Anche MQTT è stato rimosso. Le funzionalità rimanenti sono ancora disponibili tramite la console o la console remota.
Puoi trovare i binari precompilati nella cartella "firmware-repeater".
La configurazione iniziale della versione in modalità ripetitore è sostanzialmente semplice come per il router NAT. Tramite la console seriale imposta semplicemente ssid, password, ap_ssid e ap_password, poi salva e resetta. Se vuoi farlo tramite l'interfaccia web, è altrettanto semplice, ma devi rispettare l'ordine corretto:
- Connettiti al WiFi "MyAP" con il tuo client
- Punta il browser su "http://192.168.4.1"
- Inserisci **prima** l'SSID e la password delle impostazioni AP, imposta e riavvia
- Quindi connettiti al tuo nuovo SSID AP, punta di nuovo il browser su "http://192.168.4.1"
- Ora inserisci l'SSID e la password delle impostazioni STA e connetti
Una volta definito l'SSID STA, il ripetitore non eseguirà più il proprio server DHCP, ma riceverà il suo IP dal DHCP a monte (non più 192.168.4.1). Per connetterti alla sua pagina web o alla console remota, puoi usare il nome "esp-wifi-repeater.local", se il tuo client supporta mDNS, oppure devi cercare l'indirizzo assegnato nel tuo router a monte (o nella console seriale con "show stats"). Puoi sempre resettare l'ESP tramite la console con "reset factory".
### Riepilogo del confronto chiave
| Caratteristica | Router NAT | Bridge di Livello 2 |
| :--- | :--- | :--- |
| **Architettura di rete** | Crea una nuova sottorete isolata | Estende il dominio di broadcast esistente |
| **Assegnazione IP** | I client usano un pool secondario | I client usano il server DHCP a monte |
| **Scoperta (mDNS/UPnP)** | Spesso bloccata/difficile | Completamente supportata (Trasparente) |
| **Visibilità a monte** | Identità del client nascosta (NAT) | Identità del client preservata |
| **Implementazione** | Rete standard | Proxy avanzato (Proxy ARP/Snooping) |
# Building e Flashing
Per il flashing diretto dei binari precompilati sul dispositivo usa il [Web-Installer](https://martin-ger.github.io/esp_wifi_repeater/).
Se hai Docker installato, il modo più semplice per accedere all'ambiente di compilazione completo è collegare il tuo ESP8266 a /dev/ttyUSB0 ed eseguire l'immagine usando:```
git clone https://github.com/martin-ger/esp_wifi_repeater.git
docker run -it --rm --device=/dev/ttyUSB0 -v $(pwd)/esp_wifi_repeater:/home/esp/esp_wifi_repeater martinfger/iot_devel:1.0
cd esp_wifi_repeater
make
make flash
Per costruire la versione L2 WiFi Repeater basta usare l'opzione VARIANT=bridge per il comando make:``` git clone https://github.com/martin-ger/esp_wifi_repeater.git docker run -it --rm --device=/dev/ttyUSB0 -v $(pwd)/esp_wifi_repeater:/home/esp/esp_wifi_repeater martinfger/iot_devel:1.0 cd esp_wifi_repeater make VARIANT=bridge make flash
Per configurare l'ambiente di build da zero e compilare questo binario, scarica e installa esp-open-sdk (suggerisco questa versione con base NONOS SDK 2.2: https://github.com/xxxajk/esp-open-sdk). Assicurati di poter compilare e scaricare l'esempio "blinky" incluso.
Quindi scarica questo albero dei sorgenti in una directory separata e modifica la variabile BUILD_AREA nel Makefile e le eventuali opzioni desiderate in user/user_config.h. Le modifiche alla configurazione predefinita possono essere effettuate in user/config_flash.c. Compila il firmware esp_wifi_repeater con "make". "make flash" lo flasha su un esp8266.
L'albero dei sorgenti include una versione binaria di liblwip_open più gli include aggiuntivi necessari dal mio fork di esp-open-lwip e un binario dello strumento rboot. *Non è richiesta alcuna azione di installazione aggiuntiva per questo.* Solo se non vuoi utilizzare la libreria precompilata, fai il checkout dei sorgenti da https://github.com/martin-ger/esp-open-lwip . Usalo per sostituire la directory "esp-open-lwip" nell'albero di esp-open-sdk. "make clean" nella directory esp_open_lwip e poi di nuovo un "make" nella directory superiore esp_open_sdk. Questo compilerà un liblwip_open.a che contiene le funzionalità NAT. Sostituisci liblwip_open_napt.a con quel binario. Inoltre potresti compilare il binario "rboot.bin" da https://github.com/raburton/rboot e sostituirlo nella directory principale del progetto.
*Aggiornamento*: se leggi da qualche parte in rete istruzioni di installazione che usano "0x10000.bin" - a causa dell'OTA questo è stato cambiato in "0x02000.bin" ora.
Se vuoi utilizzare i binari del firmware precompilati completi, puoi flasharli con "esptool.py --port /dev/ttyUSB0 write_flash -fs 4MB -ff 80m -fm dio 0x00000 firmware/0x00000.bin 0x02000 firmware/0x02000.bin" (usa -fs 1MB per un ESP-01). Per l'esp8285 devi usare -fs 1MB e -fm dout.
Su Windows puoi flasharlo usando il "ESP8266 Download Tool" disponibile su https://espressif.com/en/support/download/other-tools. Scarica i due file 0x00000.bin e 0x02000.bin dalla directory firmware. Per un ESP12 generico, un NodeMCU o un Wemos D1 usa le seguenti impostazioni (per un ESP-01 modifica FLASH SIZE in "8Mbit"):
<img src="https://raw.githubusercontent.com/martin-ger/esp_wifi_repeater/master/FlashRepeaterWindows.jpg">
Se la modalità "QIO" fallisce sul tuo dispositivo, prova "DIO". Dai anche un'occhiata alle "Detected Info" per controllare dimensione e modalità del chip flash. Se il firmware scaricato ancora non si avvia correttamente, verifica con i checksum allegati se i file binari sono eventualmente corrotti. Se hai dubbi riguardo alla corruzione dei binari del firmware, scarica l'intero repo come zip ed estrai i binari da quello zip - questo evita problemi di download HTTP (es. conversioni CR-LF).
# Supporto per aggiornamenti OTA (Over the air)
Basato sull'uso della libreria rboot: https://github.com/raburton/rboot e grazie al contributo di christianchristensen.
Il processo di build crea due copie del binario esp_wifi_repeater nella directory firmware: 0x02000.bin e 0x82000.bin. Per un'installazione iniziale è sufficiente flashare 0x00000.bin (il boot loader rboot) e 0x02000.bin (una copia del programma). L'esp_wifi_repeater funzionerà.
Se hai almeno 1MB di flash puoi fare un aggiornamento OTA (Over the air) con un'altra versione. Cioè puoi caricare interattivamente un nuovo binario dalla CLI e passare ad esso. L'altro binario viene caricato nella posizione di memoria attualmente non attiva (0x02000 (rom0) o 0x82000 (rom1)) e avviato in caso di successo. Puoi anche passare interattivamente tra due binari installati. La configurazione corrente verrà utilizzata per entrambi i binari (finché il suo formato non cambia).
Puoi controllare le funzionalità OTA con i seguenti comandi:
- show ota: mostra il binario attualmente attivo e l'URL del prossimo aggiornamento
- set ota_host _hostname_: imposta hostname o indirizzo IP del server OTA (default: "none")
- set ota_port _portno_: imposta il numero di porta del server OTA (default: 80)
- ota update: tenta di scaricare un nuovo binario (0x02000.bin o 0x82000.bin) via HTTP da ota_host:ota_port e lo avvia
- ota switch: passa all'altro binario (se installato)
Per testare la funzionalità OTA, configura il tuo ESP (come STA o AP) per essere connesso alla rete con il server di aggiornamento. Lì avvia un semplice web server nella directory firmware, ad esempio:```
cd firmware
python -m SimpleHTTPServer 8080
Imposta il parametro hostname sul nome host o IP del tuo computer, imposta portno su 8080, e 'salva'. Quindi digita sulla CLI:``` ota update
Se configurato correttamente, l'aggiornamento inizierà e l'ESP si riavvierà con il nuovo binario.
# Problemi noti
- A causa delle limitazioni dell'implementazione SoftAP dell'ESP, c'è un massimo di 8 stazioni connesse simultaneamente.
- L'ESP8266 richiede una buona alimentazione poiché produce picchi di corrente fino a 170 mA durante la trasmissione (il consumo medio tipico è di circa 70 mA quando il WiFi è acceso). Controlla prima l'alimentazione, se il tuo ESP funziona in modo instabile e si riavvia di tanto in tanto. Un condensatore di grande capacità tra Vdd e Gnd può aiutare se riscontri problemi in questo caso.
# Licenze
Il software è open source. I file sorgente di terze parti hanno la propria intestazione di licenza. Per tutti gli altri file si applica la licenza MIT.