martin-ger/esp_wifi_repeaterUn routeur NAT WiFi entièrement fonctionnel (et maintenant également un répéteur WiFi)
Un routeur NAT WiFi entièrement fonctionnel (et maintenant aussi un répéteur WiFi, alias pont L2)
NOUVEAU 2026 : 10 ans après la première version, il est enfin devenu ce qu'il a toujours prétendu être : un véritable répéteur WiFi. Afin de ne pas casser les documents et liens existants, l'édition standard reste la version bien connue du routeur NAT avec toutes ses fonctionnalités avancées. Mais si vous êtes intéressé par un véritable pont L2 allégé, regardez ci-dessous dans la section ESP8266 Répéteur WiFi - Pont L2.
Ceci est une implémentation d'un routeur NAT WiFi sur les esp8266 et esp8285. Il inclut également la prise en charge d'un pare-feu de filtrage de paquets avec ACL, mappage de ports, régulation de trafic, hooks pour surveillance à distance (ou sniffing de paquets), une interface de gestion MQTT, une interaction GPIO simple et une gestion de l'alimentation. Pour une configuration avec plusieurs routeurs en maillage afin de couvrir une plus grande zone, un nouveau mode « Automesh » a été inclus.
Si vous cherchez un moyen d'intégrer la fonctionnalité NAT dans votre projet Arduino - voir ici .
Routeur NAT ESP32 est le projet avancé pour l'ESP32.
Les scénarios d'utilisation typiques incluent :
Par défaut, l'ESP agit en tant que STA et que soft-AP et transmet de manière transparente tout le trafic IP qui le traverse. Comme il utilise le NAT, aucune entrée de routage n'est nécessaire ni du côté réseau ni du côté des stations connectées. Les stations sont configurées via DHCP par défaut dans le réseau 192.168.4.0/24 et reçoivent l'adresse de leur serveur DNS du réseau WiFi existant.
Les mesures montrent qu'il peut atteindre environ 5 Mbps dans les deux sens, donc même le streaming est possible.
Quelques détails sont expliqués dans cette vidéo.
Pour un flashage direct sur l'appareil, utilisez l'Installateur Web.
L'esp_wifi_repeater démarre avec la configuration par défaut suivante :
Après le premier démarrage (ou une réinitialisation d'usine), il proposera un réseau WiFi avec un AP ouvert et le ssid « MyAP ». Il n'essaie pas encore de se reconnecter automatiquement à un AP de liaison montante (car il ne connaît pas de ssid ou de mot de passe valide).
Connectez-vous à ce réseau WiFi et effectuez la configuration de base soit via une simple interface web, soit via la configuration complète avec toutes les options via la console.
L'interface web permet de configurer tous les paramètres nécessaires à la fonctionnalité de base de transfert. Merci à rubfi pour le travail principal sur ce point : https://github.com/rubfi/esp_wifi_repeater/ . Pointez votre navigateur vers « http://192.168.4.1 ». Cette page devrait apparaître :
Entrez d'abord les valeurs appropriées pour le réseau WiFi de liaison montante, les « Paramètres STA ». Utilisez le mot de passe « none » pour les réseaux ouverts. Cochez la case « Automesh » si et seulement si vous souhaitez réellement utiliser le mode automesh. Cliquez sur « Connect ». L'ESP redémarre et se connectera à votre routeur WiFi. La LED de statut devrait clignoter après quelques secondes.
Si vous avez sélectionné automesh, la configuration est terminée. La configuration des « Paramètres Soft AP » n'est pas nécessaire car en mode automesh, ces paramètres sont identiques aux « Paramètres STA ». Le même ssid sera proposé par tous les répéteurs ESP connectés.
Si vous n'utilisez pas automesh, vous pouvez maintenant recharger la page et modifier les « Paramètres Soft AP ». Cliquez sur « Set » et l'ESP redémarre à nouveau. Il est maintenant prêt à transférer le trafic via le Soft AP nouvellement configuré. Sachez que ces modifications affectent également l'interface de configuration, c'est-à-dire que pour effectuer d'autres configurations, connectez-vous à l'ESP via l'un des réseaux WiFi nouvellement configurés. Pour un accès via le Soft AP, souvenez-vous de l'adresse du réseau du Soft AP si vous l'avez changée (l'ESP a toujours l'adresse x.x.x.1 dans ce réseau).
Si vous le souhaitez, vous pouvez cocher la case « lock » et cliquer sur « Lock ». Désormais, la configuration ne peut plus être modifiée sans la déverrouiller d'abord avec le mot de passe du réseau WiFi de liaison montante (définissez-en un même si le réseau est ouvert).
Si vous souhaitez saisir des caractères non ASCII ou spéciaux dans l'interface web, vous devez utiliser le codage hexadécimal de type HTTP comme « My%20AccessPoint ». Cela donnera la chaîne « My AccessPoint ». Avec ce codage hexadécimal, vous pouvez saisir n'importe quelle valeur d'octet, sauf 0 (pour des raisons internes au C).
Si vous avez fait une erreur et perdu tout contact avec l'ESP, vous pouvez toujours utiliser la console série pour le récupérer (« reset factory », voir ci-dessous).
La configuration avancée doit être effectuée via la ligne de commande sur l'interface console. Cette console est disponible soit via le port série à 115200 bauds, soit via le port tcp 7777 (par exemple « telnet 192.168.4.1 7777 » depuis une STA connectée).
Utilisez les commandes suivantes pour une configuration initiale :
Encore une fois, si vous souhaitez saisir des caractères non ASCII ou spéciaux, vous pouvez utiliser le codage hexadécimal de type HTTP (par exemple « My%20AccessPoint ») ou, uniquement sur la CLI, comme raccourci les guillemets de style C avec antislash (par exemple « My\ AccessPoint »). Les deux méthodes donneront la chaîne « My AccessPoint ».
La ligne de commande comprend beaucoup plus de commandes :
Suffisantes pour le faire fonctionner dans presque tous les environnements.
La plupart des commandes set ne sont effectives qu'après save et reset.
Toute partie d'une entrée de ligne de commande après un seul « # » jusqu'à la fin de la ligne sera traitée comme un commentaire et sera ignorée.
Dans la configuration par défaut, GPIO2 est configuré pour piloter une LED de statut (connectée à GND) avec les indications suivantes :
Avec « set status_led GPIOno », la broche GPIO peut être changée (toute valeur > 16, par exemple « set status_led 255 » désactivera complètement la LED de statut). Lorsqu'elle est configurée sur GPIO1, elle fonctionne avec la LED bleue intégrée des cartes ESP-01. Cependant, comme GPIO1 est également la broche UART-TX, cela signifie que la console série ne fonctionne pas. La configuration est alors limitée à l'accès réseau.
Si vous mettez à l'état bas un GPIO sélectionné pendant plus de 3 secondes, le répéteur effectuera une réinitialisation d'usine et redémarrera avec la configuration par défaut. Avec « set hw_reset GPIOno », la broche GPIO peut être changée (toute valeur > 16, par exemple « set hw_reset 255 » désactivera la fonction de réinitialisation matérielle d'usine).
Pour de nombreux modules, y compris les ESP-01 et NodeMCUs, il est probablement judicieux d'utiliser GPIO 0 pour cela, car il est de toute façon utilisé. Cependant, ce n'est pas la broche par défaut, car elle pourrait interférer avec sa mise à l'état bas pendant le flashage. Ainsi, si vous souhaitez utiliser un bouton-poussoir existant sur GPIO 0 pour la réinitialisation matérielle d'usine, configurez-le avec « set hw_reset 0 » et « save » après le flashage. Une réinitialisation d'usine déclenchée par la broche matérielle NE réinitialisera PAS le numéro GPIO hw_reset configuré (« reset factory » depuis la console le fera).
Afin de permettre aux clients du réseau externe de se connecter aux ports du serveur sur le réseau interne, les ports doivent être mappés. Un port externe est mappé à un port interne d'une adresse IP interne spécifique. Utilisez la commande « portmap add » pour cela. Les mappages de ports peuvent être listés avec la commande « show » et sont sauvegardés avec la configuration actuelle.
Cependant, pour s'assurer que l'appareil attendu écoute à une certaine adresse IP, il faut garantir que cet appareil a la même adresse IP une fois qu'il ou l'ESP est redémarré. Pour y parvenir, soit des adresses IP fixes peuvent être configurées dans les appareils, soit l'ESP doit se souvenir de ses baux DHCP. Cela peut être réalisé avec la commande « save dhcp ». Elle sauvegarde l'état actuel et tous les baux DHCP, afin qu'ils soient restaurés après le redémarrage. Les baux DHCP peuvent être listés avec la commande « show stats ».
Le support de WPA2 Enterprise (PEAP) a maintenant été inclus dans le projet. Il permet un « convertisseur » qui traduit un réseau WPA2 enterprise avec authentification PEAP en un réseau WPA2-PSK. Cela résout un problème courant, en particulier dans les environnements universitaires : le réseau WiFi local est un réseau WPA2 Enterprise avec authentification PEAP-MSCHAPv2. Un exemple très connu est le réseau « eduroam » disponible dans de nombreuses universités dans le monde. Le problème est que de nombreux appareils IoT ne peuvent pas gérer l'authentification WPA2 Enterprise. Le développement et les démonstrations sont donc difficiles. Ce qui est très utile, c'est un « convertisseur » qui se connecte au réseau WPA2 Enterprise et propose un réseau WPA-PSK plus simple à ses clients.
Pour l'utiliser, définissez les paramètres de configuration suivants : ssid, use_peap, peap_identity, peap_username et peap_password (vous n'avez pas besoin du paramètre password habituel). Cette configuration doit être effectuée (et sauvegardée) via la CLI et n'est pas disponible dans l'interface web.
Le code ne vérifie actuellement pas le certificat du serveur RADIUS. Il est vulnérable aux attaques MITM lorsque quelqu'un met en place un AP et un serveur RADIUS malveillants. Bien que le mot de passe ne soit pas envoyé en texte clair, le MSCHAPv2 utilisé est connu pour être cassé. Soyez également conscient du fait que l'ESP8266 contient désormais votre mot de passe de réseau d'entreprise. Tout le trafic qu'il transfère peut désormais être lié par l'administrateur réseau à votre compte. Ne l'utilisez pas à mauvais escient et ne le proposez pas à des personnes non fiables, par exemple en configurant un réseau ouvert. Et même lorsque l'appareil est verrouillé, votre mot de passe de réseau d'entreprise peut être extrait via le port série de la mémoire flash de l'ESP en texte clair.
Parfois, vous pouvez souhaiter utiliser plusieurs esp_wifi_repeaters à la suite ou en maillage pour couvrir une plus grande distance ou zone. Généralement, cela peut être fait sans problème avec des routeurs NAT, vous aurez en fait plusieurs couches de NAT. Cependant, cela signifie que la connectivité est limitée : tous les nœuds peuvent parler à internet, mais généralement il n'y a pas de connectivité IP directe entre les nœuds. Et, bien sûr, la bande passante disponible diminue avec le nombre de sauts nécessaires. Mais les utilisateurs ont rapporté que même 5 esp_wifi_repeaters à la suite fonctionnent plutôt bien.
Dans une telle configuration, la mise en place est une activité assez longue et sujette aux erreurs. Pour simplifier cela, l'esp_wifi_repeater a maintenant un nouveau mode : « Automesh ». Configurez simplement le SSID et le mot de passe et activez « automesh ». (soit sur la CLI avec « set automesh 1 » soit sur l'interface web en cochant simplement la case). Cela fera ce qui suit :Chaque esp_wifi_repeater configuré de cette façon proposera automatiquement un réseau WiFi sur le point d'accès (AP) avec le même SSID/mot de passe que celui auquel il est connecté. Les clients peuvent utiliser les mêmes paramètres WiFi pour le réseau d'origine ou les réseaux répétés. Chaque esp_wifi_repeater configuré avec « automesh » recherchera d'abord le meilleur autre point d'accès auquel se connecter. Celui-ci est le plus proche du réseau WiFi d'origine et possède la meilleure puissance de signal (RSSI).
La puissance du signal est facile à mesurer avec un scan, mais comment déterminer lequel est le plus proche du réseau WiFi d'origine lorsque l'on voit plusieurs points d'accès avec le même SSID ? Pour cela, le protocole utilise une astuce un peu sale : les esp_wifi_repeaters en mode « automesh » manipulent leur BSSID (en réalité, selon la norme IEEE 802.11, il s'agit de l'« ESSID » car c'est un point d'accès, mais le SDK l'appelle « BSSID »), c'est-à-dire l'adresse MAC de leur interface AP, qui est envoyée avec chaque balise (beacon) environ 10 fois par seconde. Il utilise le format : 24:24:mm:rr:rr:rr. « 24:24 » est simplement l'identifiant unique d'un répéteur (il y a une probabilité minime que cela entre en collision avec la MAC du vrai point d'accès, mais nous pouvons négliger cela, car nous pouvons changer ce préfixe si vraiment nécessaire). « mm » représente le « niveau de mesh », c'est-à-dire la distance en sauts (hops) par rapport au réseau WiFi d'origine. Les trois derniers « rr:rr:rr » sont des nombres aléatoires pour distinguer les différents ESP. Le point d'accès d'origine conserve son BSSID, c'est-à-dire que celui sans le préfixe « 24:24 » est reconnu comme racine, appelé niveau de mesh 0.
Maintenant, chaque esp_wifi_repeater peut apprendre quel autre esp_wifi_repeater est le plus proche du réseau WiFi d'origine, s'y connecter et choisir son propre BSSID en conséquence. De plus, l'adresse IP du réseau interne est ajustée en fonction du niveau de mesh : 10.24.m.0. Cela crée un arbre (un mesh très particulier) avec le point d'accès WiFi d'origine comme racine et des nœuds de répétition à plusieurs niveaux de mesh (en fait, cela fonctionne un peu comme le Spanning Tree Protocol (STP) au niveau de la couche liaison, ou le routage au niveau réseau à l'aide d'un protocole à vecteur de distance). Dès qu'une perte de liaison montante est détectée, la configuration est redémarrée. Cela devrait éviter les boucles, car pendant la (re)configuration, aucune balise avec un BSSID n'est non plus envoyée.
Pour plus de commodité, l'esp_wifi_repeater après la configuration « automesh » tente d'abord de vérifier s'il peut se connecter à un point d'accès montant. Si cela échoue, même si un point d'accès avec le bon SSID a été trouvé, il suppose que l'utilisateur a fait une erreur avec le mot de passe et se réinitialise aux paramètres d'usine. Après s'être connecté avec succès une fois, il considérera la configuration comme correcte et continuera d'essayer après une perte de connexion ou une réinitialisation aussi longtemps que nécessaire (pour éviter une attaque DOS avec un point d'accès mal configuré).
S'il y a plus d'un ESP à portée, il peut y avoir un compromis entre un chemin « mauvais » plus court et un chemin « bon » plus long (bon et mauvais en termes de qualité de liaison). Le paramètre am_threshold détermine ce qu'est une mauvaise connexion : si le RSSI lors d'un scan est inférieur à ce seuil, la connexion est mauvaise et un chemin avec un saut supplémentaire est préféré. C'est-à-dire, étant donné que am_threshold est 85 et qu'il y a deux nœuds automesh détectés dans le scan : A avec niveau 1 et RSSI -88 dB et B avec niveau 2 et RSSI -60 dB, alors une liaison vers A est considérée comme trop mauvaise (-88 dB < -am_threshold) et B est préféré. Le nouveau nœud deviendra un nœud de niveau 3 avec une liaison montante via B. am_threshold est donné comme une valeur positive mais signifie un dB négatif. Une valeur plus petite est meilleure.
Si vous souhaitez obtenir plus d'informations sur la topologie d'un réseau automesh, vous pouvez envisager de connecter tous les nœuds à un courtier MQTT et de les laisser publier le sujet « Topology » (voir ci-dessous). Si vous vous abonnez maintenant sur « /WiFi/+/system/Topology », vous obtiendrez toutes les informations sur les nœuds et les liaisons, y compris le RSSI (des ESP connectés) dont vous avez besoin pour reconstruire le graphe complet et détecter les liaisons faibles dans le mesh. Le sujet TopologyInfo contient la structure JSON suivante, qui peut être utilisée pour reconstruire un graphe complet d'un réseau 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"} ] }
Using the two parameters _am_scan_time_ and _am_sleep_time_ power management can be implemented in automesh mode, if you have connected GPIO16 to RST. After booting the esp_wifi_repeater scans for available uplink APs for _am_scan_time_ seconds. If none is found, it goes to deepsleep for _am_sleep_time_ seconds and tries again after reboot (default is 0 = disabled for both parameters).
# Monitoring
Depuis la console, un service de monitoring peut être démarré (« monitor on [portno] »). Ce service reflète le trafic du réseau interne au format pcap vers un flux TCP. Par exemple, avec une commande « netcat [external_ip_of_the_repeater] [portno] | sudo wireshark -k -S -i - » depuis un ordinateur du réseau externe, vous pouvez désormais observer le trafic du réseau interne en temps réel. Utilisez ceci par exemple pour observer avec quels sites internet vos clients internes communiquent. Soyez conscient que cela double au moins la charge sur l'ESP et le réseau WiFi. Sous forte charge, cela peut entraîner le raccourcissement, voire la perte, de certains paquets dans la session de monitoring. ATTENTION : laisser ce port ouvert constitue un problème de sécurité potentiel. Toute personne sur les réseaux locaux peut se connecter et observer votre trafic.
# Firewall
Le routeur ESP dispose d'un pare-feu de base intégré. Des listes de contrôle d'accès (ACL) peuvent être appliquées à l'interface SoftAP. C'est une pierre angulaire de la sécurité IoT, lorsque le routeur est utilisé pour connecter d'autres appareils IoT à Internet. Cela peut être utilisé pour empêcher, par exemple, des appareils IoT tiers de « rappeler à la maison », d'être utilisés comme bots malveillants, et pour protéger votre réseau domestique avec PC, tablettes et téléphones d'être visibles par les appareils de domotique.
Les quatre listes ACL sont nommées « from_sta », « to_sta », « from_ap » et « to_ap » pour les paquets entrants et sortants sur les deux interfaces (« sta » désigne les interfaces vers les clients connectés, « ap » l'interface vers le point d'accès amont). Les ACL sont définies « à la manière de CISCO IOS ».
L'exemple suivant est utile pour un sous-réseau invité. Il autorise l'accès à Internet mais pas aux autres adresses locales (utilisez la plage de votre réseau local pour l'adresse xx.xx.xx.xx). Ce jeu de règles autorise les diffusions locales sortantes (pour DHCP) et UDP 53 (DNS), tout autre paquet destiné au sous-réseau du routeur amont sera bloqué, tous les autres paquets peuvent passer vers 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
L'exemple suivant est plus restrictif et est utile lorsque vous planifiez un sous-réseau IoT avec un accès très limité au point d'accès de l'ESP. Il autorisera également les diffusions locales sortantes (pour DHCP), UDP 53 (DNS) et TCP 1883 (MQTT) vers un courtier local, mais tout autre paquet sera bloqué, y compris l'accès arbitraire à Internet (vous pouvez adapter la quatrième instruction selon vos besoins pour autoriser d'autres hôtes) :``` 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
ACLs pour la direction "to_sta" peuvent également être définies, mais cela n'est généralement pas nécessaire, car la direction inverse est assez bien protégée contre le trafic non sollicité par la traduction NAT.
Les ACL sont constituées de règles de filtrage traitées pour chaque paquet. Chaque règle comprend un protocole (IP, TCP ou UDP), une adresse/port source, une adresse/port destination, ainsi qu'une action "allow" ou "deny". Dans le cas d'IP simple, seules les adresses sont données, pas les ports. Les règles IP incluent les paquets TCP et UDP. Les adresses peuvent être données comme adresses de sous-réseau en notation "/", par exemple 192.168.178.0/24. "any" peut également être utilisé comme joker, correspondant à n'importe quelle adresse ou numéro de port. Une règle est définie par la commande "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]
Les règles sont traitées de haut en bas dans l'ordre de leur apparition dans la liste. La première règle qui correspond à un paquet est appliquée et détermine si un paquet est autorisé (et transmis) ou refusé (et abandonné). Cela signifie : cas particuliers en premier, règles générales à la fin. S'il y a des règles dans une ACL, tous les paquets qui ne correspondent à aucune règle sont refusés par défaut. Ainsi, la dernière règle "from_sta IP any any deny" dans l'exemple ci-dessus n'est pas vraiment nécessaire, car c'est le comportement par défaut de toute façon. Si une ACL est vide, tous les paquets sont autorisés.
La définition des règles ACL fonctionne également de haut en bas : une nouvelle règle est toujours ajoutée à la fin d'une liste. Pour modifier une ACL, vous devez d'abord la vider complètement (acl from_sta clear) puis la reconstruire. Les ACL sont sauvegardées avec la configuration. "show acl" affichera les ACL ainsi que les statistiques du nombre d'occurrences pour chaque règle et le nombre total de paquets autorisés et refusés.
Avec la commande "set acl_debug 1", un résumé de tous les paquets refusés est affiché sur la console. De plus, un sujet MQTT peut publier ce résumé. Cela peut être utilisé pour la configuration du pare-feu afin de déterminer quelles règles sont nécessaires pour faire fonctionner les appareils connectés. Cela donne également une indication si un trafic inattendu se produit (et est refusé).
Pour une analyse plus approfondie, le service de monitoring peut être utilisé (même les paquets refusés sont signalés au moniteur avant d'être abandonnés). Lorsque le moniteur est démarré avec la commande "monitor acl _port_", les ACL peuvent être utilisées comme filtres en ligne. Toutes les règles définies comme "allow_monitor" au lieu de "allow" et "deny_monitor" au lieu de "deny" sont traitées comme d'habitude, autorisant la transmission d'un paquet, mais elles envoient également le paquet au moniteur. Ainsi, une liste de règles qui autorisent fondamentalement "allow" ou "allow_monitor" tous les paquets a toujours du sens, car elle peut être utilisée pour sélectionner dès la capture quels paquets doivent être enregistrés. Par exemple, une liste :```
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
permettra de sélectionner tous les paquets pour la surveillance qui vont d'une station vers le sous-réseau 192.168.0.0/16 (local) et du sous-réseau 192.168.0.0/16 vers une station. Bien sûr, un tel filtre peut également être appliqué après la capture sur une trace de surveillance complète, mais si vous savez déjà ce que vous cherchez, ces filtres en ligne aideront à réduire considérablement la surcharge de surveillance. Il peut également être utilisé pour déboguer toutes les règles de pare-feu de type deny en utilisant simplement "deny_monitor" au lieu de deny.
Par défaut, l'interface AP est en NAT, de sorte que tout nœud connecté à l'AP pourra accéder au monde extérieur de manière transparente via l'interface STA de l'ESP. Aucune action supplémentaire n'est donc nécessaire si vous n'êtes pas un véritable expert en réseau.
Pour ceux qui sont vraiment intéressés par une configuration réseau plus poussée : la pile IPv4 lwip de l'ESP a été améliorée pour ce projet avec la prise en charge des routes statiques : "show route" affiche la table de routage avec toutes les routes connues, y compris les liens vers les interfaces réseau connectées (l'interface AP et l'interface STA). Le routage entre ces deux interfaces fonctionne sans configuration supplémentaire. Des routes supplémentaires vers d'autres réseaux peuvent être définies via la commande "route add network gateway", connue des ordinateurs Linux ou des routeurs. Une commande "save" enregistre l'état actuel de la table de routage dans la configuration flash.
Voici un exemple simple de ce qui peut être fait avec les routes statiques. Étant donné la configuration réseau suivante avec deux ESP connectés par les interfaces STA via un routeur domestique central :``` | 10.0.1.1 AP-ESP1-STA 192.168.1.10 | <-> |Home Router| <-> | 192.168.1.20 STA-ESP2-AP 10.0.2.1|
Chaque ESP possède un second réseau derrière son AP avec des adresses réseau différentes : 10.0.1.0/24 et 10.0.2.0/24. ESP1 peut pinguer ESP2 vers l'adresse 192.168.1.20 mais pas vers 10.0.2.1, car il ne sait pas qu'il peut l'atteindre via 192.168.1.20. Cela change si vous ajoutez deux routes statiques. Sur ESP1 :```
route add 10.0.2.0/24 192.168.1.20
et sur ESP2:``` route add 10.0.1.0/24 192.168.1.10
Maintenant, une "ping 10.0.2.1" sur ESP1 réussira. Il est envoyé vers 192.168.1.20 puis reçu par ESP2.
Maintenant, dans chaque réseau, un client supplémentaire se connecte (avec les adresses 10.0.1.2 et 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 |
Maintenant, même le client STA1 avec l'adresse locale 10.0.1.2 peut envoyer un ping à STA2 avec 10.0.2.2, car il envoie d'abord sa requête à son routeur par défaut ESP1, et celui-ci sait que tous les paquets destinés à une adresse 10.0.2.0/24 doivent être transférés à 192.168.1.20. Là, ESP2 sait comment les envoyer à STA2. Il en va de même pour la réponse dans l'autre direction.
Cela vous permet de configurer une topologie multi-étoile d'ESP, où chaque ESP et ses clients STA peuvent se joindre directement (sans avoir besoin de mappages de ports). La configuration des routes requises peut être quelque peu fastidieuse, mais constitue un bon exercice de mise en réseau. La prochaine étape serait de porter un protocole de routage dynamique comme RIP sur l'ESP…
En définissant upstream_kbps et downstream_kbps sur une valeur autre que 0 (0 est la valeur par défaut), vous pouvez limiter le débit maximal du point d'accès de l'ESP. Cette valeur est une limite qui s'applique au trafic de tous les clients connectés. Les paquets qui dépasseraient le débit défini sont supprimés. Le régulateur de trafic utilise l'algorithme "Token Bucket" avec une taille de seau actuellement de quatre fois le débit par seconde, permettant des rafales lorsqu'il n'y avait pas de trafic auparavant.
Depuis la version 1.3, le routeur intègre un client MQTT (merci à Tuan PM pour sa bibliothèque https://github.com/tuanpmt/esp_mqtt). Cela peut aider à intégrer le routeur/répéteur dans l'IoT. Un système domotique peut par exemple prendre des décisions basées sur les informations concernant les stations actuellement associées, allumer et éteindre les répéteurs (par exemple selon un planning horaire), ou simplement surveiller la charge. Le routeur peut être connecté soit à un courtier MQTT local, soit à un courtier accessible publiquement dans le cloud. Cependant, il ne supporte pas actuellement le chiffrement TLS.
Par défaut, le client MQTT est désactivé. Il peut être activé en définissant le paramètre de configuration "mqtt_host" sur un nom d'hôte différent de "none". Pour configurer MQTT, vous pouvez définir les paramètres suivants :
Les paramètres MQTT peuvent être affichés avec la commande "show mqtt".
Le routeur peut publier périodiquement les sujets d'état suivants (toutes les mqtt_interval) :
De plus, le répéteur peut publier sur une base événementielle :
En tant que LWT et rapport d'état, le répéteur publie :
Le routeur peut être configuré en utilisant les sujets suivants :
Si vous souhaitez maintenant que le routeur publie par exemple seulement Vdd, son adresse IP et la sortie de la ligne de commande, définissez le mqtt_mask à 0x0001 | 0x0002 | 0x0040 (= "set mqtt_mask 0043").
Le esp_wifi_repeater inclut désormais le support d'une carte réseau Ethernet ENC28J60 connectée via SPI (merci à Andrew Kroll https://github.com/xxxajk pour son excellent travail pour la faire fonctionner), si vous activez l'option de compilation HAVE_ENC28J60 dans "user_config.h". L'interface Ethernet supportera environ 1 Mbps lorsque l'ESP fonctionne à 160 MHz. Activer l'interface du point d'accès et utiliser l'Ethernet comme liaison montante transformera le esp_wifi_repeater en un point d'accès bon marché pour les appareils WiFi (par exemple d'autres ESP).
La connexion via SPI doit être :``` 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
Les fils courts et soudés sont les meilleurs. De plus, vous aurez besoin d'un transistor pour découpler GPIO15, sinon votre ESP ne démarrera plus, voir : https://esp8266hints.wordpress.com/category/ethernet/ . Il est également important d'avoir une bonne alimentation : l'ENC28j60 nécessite environ 160mA lorsqu'il est actif. Pour moi, cela échoue si j'essaie d'utiliser le 3,3V de la carte ESP.
Maintenant, vous pouvez configurer la nouvelle interface Ethernet :
- set eth_enable [0|1] : active/désactive une carte réseau Ethernet ENC28J60 sur le bus SPI (par défaut : 0 - désactivé)
- set eth_ip _ip-addr_ : définit une adresse IP statique pour l'interface ETH
- set eth_netmask _netmask_ : définit un masque de sous-réseau statique pour l'interface ETH
- set eth_gw _gw-addr_ : définit une adresse de passerelle statique pour l'interface ETH
- set eth_dhcpd [0|1] : démarre un serveur DHCP pour les adresses IP dynamiques sur l'interface ETH (par défaut : 0 - désactivé)
# Gestion de l'alimentation
Le répéteur surveille sa tension d'alimentation actuelle (indiquée dans la commande "show stats"). Cela ne fonctionne que si le 107e octet dans esp_init_data_default.bin, nommé vdd33_const, est défini sur 255 (0xFF). La façon la plus simple d'y parvenir est d'écrire esp_init_data_default_v08_vdd33.bin dans la mémoire flash (voir ci-dessous).
Si _vmin_ (en mV, par défaut 0) est défini sur une valeur > 0 et que la tension d'alimentation chute en dessous de cette valeur, il passera en mode sommeil profond pendant _vmin_sleep_ secondes. Si vous avez connecté GPIO16 à RST (ce qui est difficile à souder sur un ESP-01), il redémarrera après cet intervalle, tentera de se reconnecter et continuera ses mesures. Si _vmin_ est enregistré dans la configuration, il se mettra en sommeil encore et encore, jusqu'à ce que la tension d'alimentation dépasse le seuil. Ces paramètres sont particulièrement (uniquement ?) utiles si vous avez alimenté l'ESP avec une batterie (lithium) sans protection contre la décharge excessive. Alors une valeur de 2900mV-3000mV est probablement utile, car elle réduit la consommation d'énergie de l'ESP au minimum et vous avez beaucoup plus de temps pour recharger ou remplacer la batterie avant d'endommager la batterie. Cela n'a de sens que si vous avez l'ESP connecté directement à la batterie. Si vous avez une logique supplémentaire, cela continuera de vider la batterie.
Vous pouvez envoyer l'ESP en sommeil manuellement une fois en utilisant la commande "sleep".
Attention : Si vous enregistrez une valeur _vmin_ supérieure à la tension d'alimentation maximale dans la mémoire flash, le répéteur s'éteindra immédiatement à chaque redémarrage. Ensuite, vous devrez effacer toute la configuration en flashant blank.bin (ou tout autre fichier) sur 0x0c000.
# Répéteur WiFi - Pont L2
Le projet propose désormais deux modes de fonctionnement distincts : **Routeur NAT** et **Pont de couche 2** (appelé "Mode répéteur"). Bien que les deux modes étendent la couverture réseau, ils diffèrent fondamentalement dans la façon dont ils gèrent le trafic et l'identité des appareils.
### Mode Routeur NAT (Standard)
Dans ce mode, comme décrit ci-dessus, l'appareil agit comme une passerelle standard. Il crée un nouveau sous-réseau et effectue la traduction d'adresses réseau (NAT) pour tous les appareils connectés à son point d'accès (AP).
* **Isolation de sous-réseau** : Les clients connectés sont sur un sous-réseau privé (par exemple 192.168.4.x) et sont isolés du réseau principal.
* **Identité du trafic** : Tout le trafic des clients apparaît au routeur principal comme s'il provenait de l'adresse IP/MAC de l'ESP8266 lui-même.
* **Simplicité** : Ne nécessite aucune configuration spéciale sur le routeur amont et est compatible avec pratiquement tous les réseaux Wi-Fi standard.
* **Limitation** : Les appareils sur le réseau principal ne peuvent pas facilement initier des connexions vers les appareils derrière le répéteur en raison de la barrière NAT, à moins d'utiliser le mappage de ports.
### Mode Pont de couche 2 (variante "Répéteur")
Ce mode implémente un pont transparent de couche 2 (couche de liaison de données). L'ESP8266 étend le réseau primaire existant plutôt que de créer un sous-réseau secondaire.
* **Pont transparent** : L'ESP8266 ponte le trafic au niveau de la trame Ethernet. Les clients connectés reçoivent des adresses IP directement du serveur DHCP du réseau principal (via DHCP snooping/relais).
* **Réseau unifié** : Tous les appareils (à la fois sur le répéteur et le routeur principal) existent dans le même domaine de diffusion L2.
* **Visibilité des appareils** : Les appareils derrière le répéteur conservent leurs identités MAC et IP d'origine sur le réseau principal. Cela permet aux protocoles de découverte locaux (comme mDNS/Bonjour, UPnP ou la découverte réseau) de fonctionner de manière transparente sur l'ensemble du réseau.
* **Complexité** : Nécessite une gestion avancée, telle que Proxy ARP et DHCP snooping, pour garantir que le réseau amont achemine correctement le trafic de retour vers les clients "cachés" connectés via le répéteur.
* **Cas d'utilisation** : Idéal lorsque la découverte d'appareils (par exemple, contrôler une imprimante ou un appareil domotique via une application téléphonique) sur l'ensemble du réseau est requise.
Le mode répéteur a moins de fonctionnalités : le routage, le mappage de ports et le DHCP ne sont pas nécessaires, les ACL et l'Automesh n'ont pas non plus vraiment de sens, et la surveillance réseau via pcap non plus. Donc toutes ces fonctionnalités ne sont pas disponibles en mode répéteur. MQTT a également été retiré. Les fonctionnalités restantes sont toujours disponibles via la console ou la console à distance.
Vous pouvez trouver les binaires précompilés dans le dossier "firmware-repeater".
La première configuration de la version mode répéteur est fondamentalement aussi simple que pour le routeur NAT. Via la console série, définissez simplement ssid, password, ap_ssid et ap_password, puis enregistrez et réinitialisez. Si vous souhaitez le faire via l'interface Web, c'est également simple, mais vous devez respecter l'ordre correct :
- Connectez-vous au WiFi "MyAP" avec votre client
- Pointez le navigateur vers "http://192.168.4.1"
- Entrez **d'abord** les paramètres AP ssid et mot de passe, définissez et redémarrez
- Connectez-vous ensuite au nouveau ssid AP que vous avez défini, pointez à nouveau le navigateur vers "http://192.168.4.1"
- Entrez maintenant les paramètres STA ssid et mot de passe et connectez-vous
Une fois que le ssid STA est défini, le répéteur ne gérera plus son propre serveur DHCP, mais recevra son IP du DHCP amont (plus de 192.168.4.1). Pour vous connecter à sa page Web ou à la console à distance, vous pouvez utiliser le nom "esp-wifi-repeater.local", si votre client prend en charge mDNS, ou vous devez rechercher l'adresse attribuée dans votre routeur amont (ou la console série avec "show stats"). Vous pouvez toujours réinitialiser l'ESP via la console avec "reset factory".
### Résumé des différences clés
| Caractéristique | Routeur NAT | Pont de couche 2 |
| :--- | :--- | :--- |
| **Architecture réseau** | Crée un sous-réseau isolé | Étend le domaine de diffusion existant |
| **Attribution d'adresse IP** | Les clients utilisent un pool secondaire | Les clients utilisent le serveur DHCP amont |
| **Découverte (mDNS/UPnP)** | Souvent bloquée/difficile | Entièrement prise en charge (Transparent) |
| **Visibilité amont** | Identité du client masquée (NAT) | Identité du client préservée |
| **Implémentation** | Réseau standard | Proxy avancé (Proxy ARP/Snooping) |
# Compilation et flashage
Pour le flashage direct des binaires précompilés sur l'appareil, utilisez l'[Installeur Web](https://martin-ger.github.io/esp_wifi_repeater/).
Si vous avez Docker installé, la façon la plus simple d'accéder à l'environnement de compilation complet est de connecter votre ESP8266 à /dev/ttyUSB0 et d'exécuter l'image en utilisant :```
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
Pour construire la version L2 WiFi Repeater, il suffit d'utiliser l'option VARIANT=bridge pour la commande 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
Pour configurer l'environnement de construction à partir de zéro et construire ce binaire, téléchargez et installez l'esp-open-sdk (je suggère cette version avec le SDK NONOS de base 2.2 : https://github.com/xxxajk/esp-open-sdk). Assurez-vous de pouvoir compiler et télécharger l'exemple "blinky" inclus.
Téléchargez ensuite cette arborescence source dans un répertoire séparé et ajustez la variable BUILD_AREA dans le Makefile ainsi que les options souhaitées dans user/user_config.h. Les modifications de la configuration par défaut peuvent être effectuées dans user/config_flash.c. Construisez le firmware esp_wifi_repeater avec "make". "make flash" le flashe sur un esp8266.
L'arborescence source inclut une version binaire de liblwip_open ainsi que les inclusions supplémentaires requises issues de mon fork d'esp-open-lwip et un binaire de l'outil rboot. *Aucune action d'installation supplémentaire n'est nécessaire pour cela.* Seulement si vous ne souhaitez pas utiliser la bibliothèque précompilée, récupérez les sources depuis https://github.com/martin-ger/esp-open-lwip. Utilisez-les pour remplacer le répertoire "esp-open-lwip" dans l'arborescence esp-open-sdk. "make clean" dans le répertoire esp_open_lwip puis à nouveau un "make" dans le répertoire esp_open_sdk supérieur. Cela compilera un liblwip_open.a qui contient les fonctionnalités NAT. Remplacez liblwip_open_napt.a par ce binaire. Vous pouvez également construire le binaire "rboot.bin" depuis https://github.com/raburton/rboot et le remplacer dans le répertoire racine du projet.
*Mise à jour* : si vous lisez quelque part sur le Web des instructions d'installation utilisant "0x10000.bin" - en raison de l'OTA, cela a été changé en "0x02000.bin" maintenant.
Si vous souhaitez utiliser les binaires de firmware précompilés complets, vous pouvez les flasher avec "esptool.py --port /dev/ttyUSB0 write_flash -fs 4MB -ff 80m -fm dio 0x00000 firmware/0x00000.bin 0x02000 firmware/0x02000.bin" (utilisez -fs 1MB pour un ESP-01). Pour l'esp8285, vous devez utiliser -fs 1MB et -fm dout.
Sous Windows, vous pouvez le flasher en utilisant l'outil "ESP8266 Download Tool" disponible sur https://espressif.com/en/support/download/other-tools. Téléchargez les deux fichiers 0x00000.bin et 0x02000.bin depuis le répertoire firmware. Pour un ESP12 générique, un NodeMCU ou un Wemos D1, utilisez les paramètres suivants (pour un ESP-01, changez FLASH SIZE en "8Mbit") :
<img src="https://raw.githubusercontent.com/martin-ger/esp_wifi_repeater/master/FlashRepeaterWindows.jpg">
Si le mode "QIO" échoue sur votre appareil, essayez "DIO" à la place. Jetez également un œil aux "Detected Info" pour vérifier la taille et le mode de la puce flash. Si votre firmware téléchargé ne démarre toujours pas correctement, veuillez vérifier avec les sommes de contrôle fournies si les fichiers binaires sont éventuellement corrompus. Si vous avez des doutes concernant la corruption des binaires du firmware, téléchargez le dépôt complet en zip et extrayez les binaires de ce zip - cela évite les problèmes de téléchargement HTTP (par exemple les conversions CR-LF).
# Prise en charge des mises à jour OTA (Over the air)
Basé sur l'utilisation de la bibliothèque rboot : https://github.com/raburton/rboot et grâce à la contribution de christianchristensen.
Le processus de construction crée deux copies du binaire esp_wifi_repeater dans le répertoire firmware : 0x02000.bin et 0x82000.bin. Pour une installation initiale, il suffit de flasher 0x00000.bin (le chargeur d'amorçage rboot) et 0x02000.bin (une copie du programme). L'esp_wifi_repeater fonctionnera.
Si vous disposez d'au moins 1 Mo de flash, vous pouvez effectuer une mise à jour OTA (Over the air) avec une autre version. C'est-à-dire que vous pouvez charger interactivement un nouveau binaire depuis la CLI et basculer dessus. L'autre binaire est chargé dans l'emplacement mémoire actuellement inactif (soit 0x02000 (rom0) soit 0x82000 (rom1)) et démarré en cas de succès. Vous pouvez également basculer interactivement entre deux binaires installés. La configuration actuelle sera utilisée pour les deux binaires (tant que son format n'a pas changé).
Vous pouvez contrôler les fonctionnalités OTA avec les commandes suivantes :
- show ota : affiche le binaire actuellement actif et l'URL de la prochaine mise à jour
- set ota_host _hostname_ : définit le nom d'hôte ou l'adresse IP du serveur OTA (par défaut : "none")
- set ota_port _portno_ : définit le numéro de port du serveur OTA (par défaut : 80)
- ota update : tente de télécharger un nouveau binaire (0x02000.bin ou 0x82000.bin) via HTTP depuis ota_host:ota_port et le démarre
- ota switch : bascule vers l'autre binaire (s'il est installé)
Pour tester la fonctionnalité OTA, configurez votre ESP (en tant que STA ou AP) pour être connecté au réseau avec le serveur de mise à jour. Lancez ensuite un serveur Web simple dans le répertoire firmware, par exemple ;```
cd firmware
python -m SimpleHTTPServer 8080
Définissez le paramètre hostname sur le nom d'hôte ou l'IP de votre ordinateur, définissez portno sur 8080, et 'save'. Ensuite, tapez sur la CLI :``` ota update
Si configuré correctement, la mise à jour démarrera et l'ESP redémarrera avec le nouveau binaire.
# Problèmes connus
- En raison des limitations de l'implémentation SoftAP de l'ESP, il y a un maximum de 8 stations connectées simultanément.
- L'ESP8266 nécessite une bonne alimentation électrique car il produit des pics de courant allant jusqu'à 170 mA lors de l'émission (la consommation moyenne typique est d'environ 70 mA lorsque le WiFi est activé). Vérifiez d'abord l'alimentation électrique si votre ESP fonctionne de manière instable et redémarre de temps en temps. Un gros condensateur entre Vdd et Gnd peut aider si vous rencontrez des problèmes ici.
# Licences
Le logiciel est open source. Les fichiers sources tiers ont leur propre en-tête de licence. Pour tous les autres fichiers, la licence MIT s'applique.