martin-ger/esp_wifi_repeaterUn router NAT WiFi totalmente funcional (y ahora también un repetidor WiFi)
Un router NAT WiFi totalmente funcional (y ahora también un repetidor WiFi, también conocido como puente L2)
NUEVO 2026: 10 años después de la primera versión, por fin se ha convertido en lo que siempre pretendió ser: un verdadero repetidor WiFi. Para no romper ninguna documentación ni enlace existente, la edición estándar sigue siendo la conocida versión de router NAT con todas las funciones avanzadas. Pero si te interesa un puente L2 real y reducido, mira más abajo en la sección Repetidor WiFi ESP8266 - puente L2.
Esta es una implementación de un router NAT WiFi para esp8266 y esp8285. También incluye soporte para un cortafuegos de filtrado de paquetes con ACLs, mapeo de puertos, modelado de tráfico, hooks para monitorización remota (o captura de paquetes), una interfaz de gestión MQTT, interacción GPIO sencilla y gestión de energía. Para una configuración con múltiples routers en una malla que cubra un área más grande, se ha incluido un nuevo modo "Automesh".
Si buscas una forma de integrar la funcionalidad NAT en tu proyecto Arduino - consulta aquí .
Router NAT ESP32 es el proyecto avanzado para el ESP32.
Los escenarios de uso típicos incluyen:
Por defecto, el ESP actúa como STA y como soft-AP y reenvía transparentemente cualquier tráfico IP a través de él. Como usa NAT, no se requieren entradas de enrutamiento ni en el lado de la red ni en las estaciones conectadas. Las estaciones se configuran por defecto mediante DHCP en la red 192.168.4.0/24 y reciben la dirección de su servidor DNS de la red WiFi existente.
Las mediciones muestran que puede alcanzar unos 5 Mbps en ambas direcciones, por lo que incluso el streaming es posible.
Algunos detalles se explican en este vídeo.
Para flashear directamente el dispositivo, usa el Instalador Web.
El esp_wifi_repeater inicia con la siguiente configuración por defecto:
Después del primer arranque (o del restablecimiento de fábrica) ofrecerá una red WiFi con un AP abierto y el ssid "MyAP". Aún no intenta reconectarse automáticamente a un AP de enlace ascendente (ya que no conoce un ssid o contraseña válidos).
Conéctate a esta red WiFi y realiza la configuración básica, ya sea mediante una interfaz web sencilla o mediante la configuración completa con todas las opciones a través de la consola.
La interfaz web permite configurar todos los parámetros necesarios para la funcionalidad básica de reenvío. Gracias a rubfi por el trabajo principal en esto: https://github.com/rubfi/esp_wifi_repeater/ . Apunta tu navegador a "http://192.168.4.1". Debería aparecer esta página:
Primero introduce los valores apropiados para la red WiFi de enlace ascendente, los "Ajustes STA". Usa la contraseña "none" para redes abiertas. Marca la casilla "Automesh" solo si realmente quieres usar el modo automesh. Haz clic en "Connect". El ESP se reinicia y se conectará a tu router WiFi. El LED de estado debería parpadear después de unos segundos.
Si has seleccionado automesh, has terminado con la configuración. Configurar los "Ajustes del Soft AP" no es necesario, ya que en el modo automesh estos ajustes son idénticos a los "Ajustes STA". El mismo ssid será ofrecido por todos los repetidores ESP conectados.
Si no estás usando automesh, ahora puedes recargar la página y cambiar los "Ajustes del Soft AP". Haz clic en "Set" y de nuevo el ESP se reinicia. Ahora está listo para reenviar tráfico a través del Soft AP recién configurado. Ten en cuenta que estos cambios también afectan a la interfaz de configuración, es decir, para hacer más configuraciones, conéctate al ESP a través de una de las redes WiFi recién configuradas. Para el acceso a través del Soft AP, recuerda la dirección de la red del Soft AP si la has cambiado (el ESP siempre tiene la dirección x.x.x.1 en esta red).
Si quieres, puedes marcar la casilla "lock" y hacer clic en "Lock". Ahora la configuración no se puede cambiar sin desbloquearla primero con la contraseña de la red WiFi de enlace ascendente (define una aunque la red sea abierta).
Si quieres introducir caracteres no ASCII o especiales en la interfaz web, tienes que usar codificación hexadecimal estilo HTTP como "My%20AccessPoint". Esto dará como resultado la cadena "My AccessPoint". Con esta codificación hexadecimal puedes introducir cualquier valor de byte que quieras, excepto 0 (por razones internas de C).
Si has cometido un error y has perdido todo contacto con el ESP, aún puedes usar la consola serie para recuperarlo ("reset factory", ver más abajo).
La configuración avanzada debe realizarse mediante la línea de comandos en la interfaz de consola. Esta consola está disponible ya sea a través del puerto serie a 115200 baudios o mediante el puerto tcp 7777 (por ejemplo, "telnet 192.168.4.1 7777" desde una STA conectada).
Usa los siguientes comandos para una configuración inicial:
De nuevo, si quieres introducir caracteres no ASCII o especiales puedes usar codificación hexadecimal estilo HTTP (por ejemplo, "My%20AccessPoint") o, solo en la CLI, como atajo, comillas estilo C con barra invertida (por ejemplo, "My\ AccessPoint"). Ambos métodos darán como resultado la cadena "My AccessPoint".
La línea de comandos entiende muchos más comandos:
Suficientes para que funcione en casi todos los entornos.
La mayoría de los comandos set solo son efectivos después de save y reset.
Cualquier parte de una entrada de línea de comandos después de un solo "#" hasta el final de la línea se tratará como un comentario y se ignorará.
En la configuración por defecto, GPIO2 está configurado para controlar un LED de estado (conectado a GND) con las siguientes indicaciones:
Con "set status_led nºGPIO" se puede cambiar el pin GPIO (cualquier valor > 16, por ejemplo, "set status_led 255" deshabilitará el LED de estado por completo). Cuando se configura en GPIO1, funciona con el LED azul incorporado en las placas ESP-01. Sin embargo, como GPIO1 también es el pin UART-TX, esto significa que la consola serie no funciona. La configuración se limita entonces al acceso de red.
Si pones en bajo un GPIO seleccionado durante más de 3 segundos, el repetidor hará un restablecimiento de fábrica y se reiniciará con la configuración por defecto. Con "set hw_reset nºGPIO" se puede cambiar el pin GPIO (cualquier valor > 16, por ejemplo, "set hw_reset 255" deshabilitará la función de restablecimiento de fábrica por hardware).
Para muchos módulos, incl. ESP-01s y NodeMCUs, probablemente sea una buena idea usar GPIO 0 para esto, ya que se usa de todos modos. Sin embargo, no es el pin por defecto, ya que podría interferir con ponerlo en bajo durante el flasheo. Por lo tanto, si quieres usar un pulsador existente en GPIO 0 para el restablecimiento de fábrica por hardware, configúralo con "set hw_reset 0" y "save" después del flasheo. Un restablecimiento de fábrica activado por el pin HW NO restablecerá el número de GPIO hw_reset configurado ("reset factory" desde la consola sí lo hará).
Para permitir que clientes de la red externa se conecten al puerto del servidor en la red interna, los puertos deben mapearse. Un puerto externo se mapea a un puerto interno de una dirección IP interna específica. Usa el comando "portmap add" para eso. Los mapeos de puertos se pueden listar con el comando "show" y se guardan con la configuración actual.
Sin embargo, para asegurarse de que el dispositivo esperado está escuchando en una determinada dirección IP, hay que asegurarse de que este dispositivo tenga la misma dirección IP una vez que se reinicie él o el ESP. Para lograrlo, o bien se pueden configurar direcciones IP fijas en los dispositivos o el ESP debe recordar sus concesiones DHCP. Esto se puede lograr con el comando "save dhcp". Guarda el estado actual y todas las concesiones DHCP, para que se restauren después del reinicio. Las concesiones DHCP se pueden listar con el comando "show stats".
El soporte para WPA2 Enterprise (PEAP) ahora se ha incluido en el proyecto. Permite un "conversor" que traduce una red WPA2 enterprise con autenticación PEAP a una red WPA2-PSK. Esto resuelve un problema común, especialmente en entornos universitarios: la red WiFi local es una red WPA2 Enterprise con autenticación PEAP-MSCHAPv2. Un ejemplo muy destacado es la red "eduroam", disponible en muchas universidades de todo el mundo. El problema es que muchos dispositivos IoT no pueden manejar la autenticación WPA2 Enterprise. Por lo tanto, el desarrollo y las demos son difíciles. Lo que es muy útil es un "conversor" que se conecte a la red WPA2 Enterprise y ofrezca una red WPA-PSK más simple a sus clientes.
Para usarlo, establece los siguientes parámetros de configuración: ssid, use_peap, peap_identity, peap_username y peap_password (no necesitas el parámetro de contraseña habitual). Esta configuración debe realizarse (y guardarse) a través de la CLI y no está disponible en la interfaz web.
El código actualmente no verifica el certificado del servidor RADIUS. Es vulnerable a ataques MITM, cuando alguien configura un AP y un servidor RADIUS falsos. Aunque la contraseña no se envía en texto plano, se sabe que el MSCHAPv2 utilizado está roto. Además, ten en cuenta que el ESP8266 ahora contiene la contraseña de tu red enterprise. Todo el tráfico que reenvía ahora puede ser relacionado por el administrador de red con tu cuenta. No lo uses mal ni lo ofrezcas a terceros no confiables, por ejemplo configurando una red abierta. E incluso cuando el dispositivo está bloqueado, la contraseña de tu red enterprise puede extraerse en texto plano a través del puerto serie desde la flash del ESP.
A veces es posible que quieras usar varios esp_wifi_repeaters en cadena o en malla para cubrir una mayor distancia o área. Generalmente, esto se puede hacer sin problemas con routers NAT; de hecho, tendrás varias capas de NAT. Sin embargo, esto significa que la conectividad es limitada: todos los nodos pueden hablar con internet, pero generalmente no hay conectividad IP directa entre los nodos. Y, por supuesto, el ancho de banda disponible disminuye cuantos más saltos necesites. Pero los usuarios han informado que incluso 5 esp_wifi_repeaters en cadena funcionan bastante bien.
En tal configuración, la configuración es una actividad bastante lenta y propensa a errores. Para simplificarlo, el esp_wifi_repeater ahora tiene un nuevo modo: "Automesh". Simplemente configura el SSID y la contraseña y activa "automesh" (ya sea en la CLI con "set automesh 1" o en la interfaz web marcando la casilla). Esto hará lo siguiente:Cada esp_wifi_repeater configurado de esa manera ofrecerá automáticamente una red WiFi en el AP con el mismo SSID/contraseña que la red a la que está conectado. Los clientes pueden usar los mismos ajustes de WiFi para la red original o para las repetidas. Cada esp_wifi_repeater configurado con "automesh" buscará primero el mejor otro AP al que conectarse. Este es el que está más cerca de la red WiFi original y tiene la mejor intensidad de señal (RSSI).
La intensidad de la señal es fácil de medir con un escaneo, pero ¿cuál es el más cercano a la red WiFi original cuando ves varios APs con el mismo SSID? Por lo tanto, el protocolo usa un truco algo sucio: los esp_wifi_repeaters en modo "automesh" manipulan su BSSID (en realidad, según el estándar IEEE 802.11 esto es el "ESSID" ya que es un AP, pero el SDK lo llama "BSSID"), es decir, la dirección MAC de su interfaz AP, que se envía con cada trama de baliza aproximadamente 10 veces por segundo. Usa el formato: 24:24:mm:rr:rr:rr. "24:24" es solo el identificador único de un repetidor (hay una probabilidad mínima de que esto colisione con el MAC de los APs reales, pero podemos ignorar esto, ya que podemos cambiar ese prefijo si realmente es necesario). "mm" significa el "nivel de malla", es decir, la distancia en saltos a la red WiFi original. Los últimos tres "rr:rr:rr" son solo números aleatorios para distinguir los distintos ESPs. El AP original mantiene su BSSID, es decir, el que no tiene el prefijo "24:24" se reconoce como raíz, llamado nivel de malla 0.
Ahora cada esp_wifi_repeater puede aprender qué otro esp_wifi_repeater está más cerca de la red WiFi original, puede conectarse a él y elegir su propio BSSID en consecuencia. También la dirección IP de la red interna se ajusta al nivel de malla: 10.24.m.0. Esto crea un árbol (una malla muy especial) con el AP WiFi original como raíz y nodos repetidores en varios niveles de malla (en realidad, funciona de manera algo similar al Protocolo de Árbol de Expansión (STP) en la capa de enlace o al enrutamiento en la capa de red mediante un protocolo de vector de distancia). Tan pronto como se detecta una pérdida del enlace ascendente, se reinicia la configuración. Esto debería evitar bucles, ya que durante la (re)configuración tampoco se envían balizas con un BSSID.
Por conveniencia, el esp_wifi_repeater después de la configuración "automesh" primero intenta comprobar si puede conectarse a un AP ascendente. Si esto falla, incluso cuando se ha encontrado un AP con el SSID correcto, asume que el usuario cometió un error con la contraseña y se restablece a los valores de fábrica. Después de haberse conectado correctamente una vez, asumirá que la configuración es correcta y seguirá intentándolo tras una pérdida de conexión o reinicio durante el tiempo que sea necesario (para evitar un ataque DoS con un AP mal configurado).
Si hay más de un ESP dentro del alcance, puede haber un compromiso entre un camino "malo" más corto y un camino "bueno" más largo (bueno y malo en términos de calidad de enlace). El parámetro am_threshold determina qué es una mala conexión: si el RSSI en un escaneo es menor que este umbral, una conexión es mala y se prefiere un camino con un salto más. Es decir, dado que am_threshold es 85 y hay dos nodos automesh detectados en el escaneo: A con nivel 1 y RSSI -88 dB y B con nivel 2 y RSSI -60 dB, entonces un enlace a A se considera demasiado malo (-88 dB < -am_threshold) y se prefiere B. El nuevo nodo se convertirá en un nodo de nivel 3 con enlace ascendente a través de B. am_threshold se da como un valor positivo pero significa un valor negativo en dB. Un valor más pequeño es mejor.
Si quieres obtener más información sobre la topología de una red automesh, puedes considerar conectar todos los nodos a un broker MQTT y dejar que publiquen el tema "Topology" (ver más abajo). Si ahora te suscribes a "/WiFi/+/system/Topology" obtendrás toda la información de nodos y enlaces, incluido el RSSI (de los ESPs conectados) que necesitas para reconstruir el grafo completo y detectar enlaces débiles en la malla. El tema TopologyInfo contiene la siguiente estructura JSON, que se puede utilizar para reconstruir un grafo completo de una red 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"} ] }
Usando los dos parámetros _am_scan_time_ y _am_sleep_time_ se puede implementar la gestión de energía en modo automesh, si se ha conectado GPIO16 a RST. Tras el arranque, el esp_wifi_repeater escanea durante _am_scan_time_ segundos en busca de APs de enlace ascendente disponibles. Si no encuentra ninguno, entra en deepsleep durante _am_sleep_time_ segundos y lo intenta de nuevo tras el reinicio (el valor predeterminado es 0 = deshabilitado para ambos parámetros).
# Monitorización
Desde la consola se puede iniciar un servicio de monitorización ("monitor on [portno]"). Este servicio refleja el tráfico de la red interna en formato pcap hacia un flujo TCP. Por ejemplo, con "netcat [external_ip_of_the_repeater] [portno] | sudo wireshark -k -S -i -" desde un ordenador de la red externa, ahora se puede observar el tráfico de la red interna en tiempo real. Úselo, por ejemplo, para observar con qué sitios de internet se están comunicando sus clientes internos. Tenga en cuenta que esto al menos duplica la carga del esp y de la red WiFi. Con una carga elevada, esto puede provocar que algunos paquetes se trunquen o incluso se descarten en la sesión de monitorización. PRECAUCIÓN: dejar este puerto abierto es un posible problema de seguridad. Cualquier persona de las redes locales puede conectarse y observar su tráfico.
# Firewall
El router ESP tiene un firewall básico integrado. Se pueden aplicar ACL (Listas de Control de Acceso) a la interfaz SoftAP. Esta es una piedra angular en la seguridad de IoT, cuando el router se utiliza para llevar otros dispositivos IoT a internet. Se puede utilizar para evitar, p. ej., que los dispositivos IoT de terceros "llamen a casa", que sean utilizados como bots de malware, y para proteger su red doméstica con PC, tabletas y teléfonos de ser visibles para los dispositivos de domótica.
Las cuatro listas ACL se denominan "from_sta", "to_sta", "from_ap" y "to_ap" para los paquetes entrantes y salientes en ambas interfaces ("sta" significa las interfaces hacia los clientes conectados, "ap" la interfaz hacia el AP de enlace ascendente). Las ACL se definen "en estilo CISCO IOS".
El siguiente ejemplo es útil para una subred de invitados. Permite el acceso a internet pero no a ninguna otra dirección local (use el rango de su red local para la dirección xx.xx.xx.xx). Este conjunto de reglas permite las difusiones locales salientes (para DHCP) y UDP 53 (DNS), cualquier otro paquete hacia la subred del router ascendente será bloqueado, todos los demás paquetes pueden pasar 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
El siguiente ejemplo es más restrictivo y resulta útil cuando se planifica una subred de IoT con acceso muy restringido en el AP del ESP. También permitirá broadcasts locales salientes (para DHCP), UDP 53 (DNS) y TCP 1883 (MQTT) a un broker local, pero cualquier otro paquete será bloqueado, incluido el acceso arbitrario a Internet (puede adaptar la cuarta regla según sus necesidades para habilitar otros hosts):``` 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 for the "to_sta" direction may be defined as well, but this is usually not required, as the reverse direction is quite well protected against unsolicited traffic by the NAT transation.
ACLs consist of filtering rules that are processed for each packet. Each rule consists of a protocol (IP, TCP, or UDP), source address/port, destination address/port, as well as an action "allow" or "deny". In case of plain IP no ports, only addresses are given. IP rules include TCP and UDP packets. Addresses can be given as subnet addresses in the "/" notation, e.g. 192.168.178.0/24. Also "any" can be used as wildcard, it matches on any address or portnumber. A rule is defined by the "acl" command:
- 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]
The rules are processed top-down in the order of their appearance in the list. The first rule that matches a packet is applied and determies whether a packet is allowed (and forwarded) or denied (and dropped). This means, special cases first, general rules at the end. If there are rules in an ACL all packets that don't match any rule are denied by default. Thus, the last rule "from_sta IP any any deny" in the example above is not really needed, as it is the default anyway. If an ACL is empty, all packets are allowed.
Definition of ACL rules works also top-down: a new rule is always added at the end of a list. To change an ACL you first have to clear it completely (acl from_sta clear) and then rebuild it. ACLs are saved with the config. "show acl" will print out the ACLs plus statistics on the number of hits for each rule and the overall number of allowed and denied packets.
With the command "set acl_debug 1" a summary of all denied packets is printed to the console. Also, an MQTT topic can publishe this summary. This can be used for firewall configuration to determine which rules are required to get the connected devices working. It also gives a hint if, if unexpected traffic happens (and is denied).
For deeper analysis the monitoring service can be used (even denied packets are reported to the monitor before they are dropped). When the monitor is started with the "monitor acl _port_" command, ACLs can be used as online filters. All rules that are defined as
"allow_monitor" instead of "allow" and "deny_monitor" instead of "deny" are processed as usual, resulting in allowing of forwarding a packet, but they also send the packet to the monitor. Thus a list of rules that basically "allow" or "allow_monitor" all packets still makes sense, as it can be used to select already during catpure time which packet should be recorded. E.g. a lists:```
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
permitirá todos los paquetes y también seleccionará todos los paquetes para monitorización que vayan de una estación a la subred 192.168.0.0/16 (local) y de la 192.168.0.0/16 a una estación. Por supuesto, un filtro de este tipo también puede aplicarse después de la captura a un rastro de monitorización completo, pero si ya sabes lo que buscas, estos filtros en línea ayudarán a reducir drásticamente la sobrecarga de monitorización. También puede usarse para depurar todas las reglas de firewall de denegación simplemente usando "deny_monitor" en lugar de deny.
Por defecto, la interfaz del AP está traducida mediante NAT, de modo que cualquier nodo conectado al AP podrá acceder al mundo exterior de forma transparente a través de la interfaz STA del ESP. Así que no se requiere ninguna acción adicional, a menos que seas un auténtico friki de las redes.
Para aquellos que estén realmente interesados en una configuración de red más avanzada: la pila IPv4 lwip del ESP se ha mejorado para este proyecto con soporte para rutas estáticas: "show route" muestra la tabla de enrutamiento con todas las rutas conocidas, incluidos los enlaces a las interfaces de red conectadas (la interfaz AP y la interfaz STA). El enrutamiento entre estas dos interfaces funciona sin configuración adicional. Se pueden añadir rutas adicionales a otras redes mediante el comando "route add network gateway", conocido de los sistemas Linux o routers. Un comando "save" escribe el estado actual de la tabla de enrutamiento en la configuración flash.
Aquí hay un ejemplo sencillo de lo que se puede hacer con rutas estáticas. Dado el siguiente esquema de red con dos ESP conectados por las interfaces STA a través de un router doméstico 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|
Cada ESP tiene una segunda red detrás de su AP con diferentes direcciones de red: 10.0.1.0/24 y 10.0.2.0/24. ESP1 puede hacer ping a ESP2 hacia la 192.168.1.20, pero no a la 10.0.2.1, ya que no sabe que puede alcanzarla a través de la 192.168.1.20. Esto cambia si añades dos rutas estáticas. En ESP1:```
route add 10.0.2.0/24 192.168.1.20
y en ESP2:``` route add 10.0.1.0/24 192.168.1.10
Ahora un "ping 10.0.2.1" en ESP1 tendrá éxito. Se envía a 192.168.1.20 y luego es respondido por ESP2.
Ahora en cada red se conecta un cliente adicional (con direcciones 10.0.1.2 y 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 |
Ahora incluso el cliente STA1 con la dirección local 10.0.1.2 puede hacer ping a STA2 con 10.0.2.2, ya que envía su solicitud primero a su router por defecto ESP1 y este sabe que todos los paquetes destinados a una dirección 10.0.2.0/24 deben reenviarse a 192.168.1.20. Allí el ESP2 sabe cómo enviarlos a STA2. Lo mismo aplica para la respuesta en la otra dirección.
Esto te permite configurar una topología multi-estrella de ESPs, donde cada ESP y sus clientes STA pueden alcanzarse directamente entre sí (sin necesidad de mapeos de puertos). La configuración de las rutas requeridas puede ser algo tediosa, pero es un buen ejercicio de redes. El siguiente paso sería portar un protocolo de enrutamiento dinámico como RIP al ESP...
Al establecer upstream_kbps y downstream_kbps a un valor distinto de 0 (0 es el valor por defecto), puedes limitar el bitrate máximo del AP del ESP. Este valor es un límite que se aplica al tráfico de todos los clientes conectados. Los paquetes que excedan el bitrate definido se descartan. El conformador de tráfico utiliza el algoritmo "Token Bucket" con un tamaño de cubo de actualmente cuatro veces el bitrate por segundo, lo que permite ráfagas cuando no ha habido tráfico anteriormente.
Desde la versión 1.3 el router incluye un cliente MQTT integrado (gracias a Tuan PM por su librería https://github.com/tuanpmt/esp_mqtt). Esto puede ayudar a integrar el router/repetidor en el IoT. Un sistema de domótica puede, por ejemplo, tomar decisiones basadas en información sobre las estaciones actualmente asociadas, puede encender y apagar los repetidores (por ejemplo, según un horario), o simplemente usarse para monitorizar la carga. El router puede conectarse a un broker MQTT local o a un broker disponible públicamente en la nube. Sin embargo, actualmente no soporta cifrado TLS.
Por defecto, el cliente MQTT está deshabilitado. Se puede habilitar estableciendo el parámetro de configuración "mqtt_host" a un nombre de host distinto de "none". Para configurar MQTT puedes establecer los siguientes parámetros:
Los parámetros MQTT se pueden mostrar con el comando "show mqtt".
El router puede publicar periódicamente los siguientes temas de estado (cada mqtt_interval):
Además, el repetidor puede publicar según eventos:
Como LWT e informe de estado, el repetidor publica:
El router se puede configurar utilizando los siguientes temas:
Si ahora quieres que el router publique, por ejemplo, solo Vdd, su IP y la salida de la línea de comandos, establece mqtt_mask a 0x0001 | 0x0002 | 0x0040 (= "set mqtt_mask 0043").
El esp_wifi_repeater ahora incluye soporte para una tarjeta de red Ethernet ENC28J60 conectada vía SPI (Gracias a Andrew Kroll https://github.com/xxxajk por su gran trabajo para lograrlo), si activas la opción de compilación HAVE_ENC28J60 en "user_config.h". La interfaz Ethernet soportará aproximadamente 1 Mbps cuando el ESP esté funcionando a 160 MHz. Activar la interfaz AP y usar Ethernet como uplink convertirá al esp_wifi_repeater en un AP económico para dispositivos WiFi (por ejemplo, otros ESPs).
La conexión vía SPI debe ser:``` 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
Cables cortos y soldados funcionan mejor. Además necesitarás un transistor para desacoplar GPIO15; de lo contrario, tu ESP ya no arrancará. Ver: https://esp8266hints.wordpress.com/category/ethernet/ . También es importante tener una buena fuente de alimentación: el ENC28j60 necesita unos 160mA cuando está activo. En mi caso falla si intento usar los 3.3V de la placa ESP.
Ahora puedes configurar la nueva interfaz Ethernet:
- set eth_enable [0|1]: habilita/deshabilita una NIC Ethernet ENC28J60 en el bus SPI (por defecto: 0 - deshabilitado)
- set eth_ip _ip-addr_: establece una dirección IP estática para la interfaz ETH
- set eth_netmask _netmask_: establece una máscara de red estática para la interfaz ETH
- set eth_gw _gw-addr_: establece una dirección de puerta de enlace estática para la interfaz ETH
- set eth_dhcpd [0|1]: inicia un servidor DHCP para direcciones IP dinámicas en la interfaz ETH (por defecto: 0 - deshabilitado)
# Gestión de energía
El repetidor supervisa su tensión de alimentación actual (que se muestra en el comando "show stats"). Esto solo funciona si el byte 107 en esp_init_data_default.bin, llamado vdd33_const, está configurado en 255 (0xFF). La forma más sencilla de lograrlo es escribir esp_init_data_default_v08_vdd33.bin en la flash (ver más abajo).
Si _vmin_ (en mV, por defecto 0) se establece a un valor > 0 y la tensión de alimentación cae por debajo de ese valor, el dispositivo entrará en modo de suspensión profunda durante _vmin_sleep_ segundos. Si has conectado GPIO16 a RST (lo cual es difícil de soldar en un ESP-01), se reiniciará después de ese intervalo, intentará reconectarse y continuará con sus mediciones. Si _vmin_ se guarda con la configuración, dormirá una y otra vez hasta que la tensión de alimentación supere el umbral. Estos ajustes son especialmente (¿solo?) útiles si has alimentado el ESP con una batería (de litio) sin protección contra descarga profunda. Entonces, un valor de 2900mV-3000mV probablemente sea útil, ya que reduce el consumo de energía del ESP al mínimo y dispones de mucho más tiempo para recargar o reemplazar la batería antes de que se dañe. Esto solo tiene sentido si tienes el ESP conectado directamente a la batería. Si tienes lógica adicional, esta seguirá agotando la batería.
Puedes enviar el ESP a dormir manualmente una vez usando el comando "sleep".
Precaución: Si guardas un valor de _vmin_ superior a la tensión máxima de alimentación en la flash, el repetidor se apagará inmediatamente cada vez después del reinicio. Entonces tendrás que borrar toda la configuración grabando blank.bin (o cualquier otro archivo) en 0x0c000.
# Repetidor WiFi - Puente L2
El proyecto ofrece ahora dos modos operativos distintos: **Router NAT** y **Puente de Capa 2** (denominado "modo repetidor"). Si bien ambos modos amplían la cobertura de red, difieren fundamentalmente en cómo manejan el tráfico y la identidad de los dispositivos.
### Modo Router NAT (Estándar)
En este modo, como se ha descrito anteriormente, el dispositivo actúa como una puerta de enlace estándar. Crea una nueva subred y realiza traducción de direcciones de red (NAT) para todos los dispositivos conectados a su punto de acceso (AP).
* **Aislamiento de subred**: Los clientes conectados están en una subred privada (p. ej., 192.168.4.x) y quedan protegidos de la red principal.
* **Identidad del tráfico**: Todo el tráfico de los clientes aparece ante el router principal como si se originara desde la propia dirección IP/MAC del ESP8266.
* **Simplicidad**: No requiere configuración especial en el router ascendente y es compatible con prácticamente todas las redes Wi-Fi estándar.
* **Limitación**: Los dispositivos de la red principal no pueden iniciar fácilmente conexiones con los dispositivos detrás del repetidor debido a la barrera NAT, a menos que se utilice mapeo de puertos.
### Modo Puente de Capa 2 (variante "repetidor")
Este modo implementa un puente transparente de Capa 2 (capa de enlace de datos). El ESP8266 extiende la red principal existente en lugar de crear una subred secundaria.
* **Puente transparente**: El ESP8266 puentea el tráfico a nivel de trama Ethernet. Los clientes conectados reciben direcciones IP directamente del servidor DHCP de la red principal (mediante DHCP snooping/relay).
* **Red unificada**: Todos los dispositivos (tanto en el repetidor como en el router principal) existen en el mismo dominio de difusión L2.
* **Visibilidad de los dispositivos**: Los dispositivos detrás del repetidor conservan sus identidades MAC e IP originales en la red principal. Esto permite que los protocolos de descubrimiento local (como mDNS/Bonjour, UPnP o el descubrimiento de red) funcionen sin problemas en toda la red.
* **Complejidad**: Requiere manejo avanzado, como Proxy ARP y DHCP snooping, para garantizar que la red ascendente enrute correctamente el tráfico de vuelta a los clientes "ocultos" conectados a través del repetidor.
* **Caso de uso**: Ideal cuando se requiere descubrimiento de dispositivos (p. ej., controlar una impresora o un dispositivo doméstico inteligente mediante una aplicación móvil) en toda la red.
El modo repetidor tiene menos funciones: no se requieren enrutamiento, mapeo de puertos ni DHCP; las ACL y Automesh tampoco tienen mucho sentido, ni tampoco la monitorización de red mediante pcap. Por lo tanto, todas estas funciones no están disponibles en el modo repetidor. Además, se ha eliminado MQTT. Las funciones restantes siguen disponibles a través de la consola o la consola remota.
Puedes encontrar los binarios precompilados en la carpeta "firmware-repeater".
La configuración inicial de la versión en modo repetidor es básicamente tan simple como la del router NAT. Mediante la consola serie, simplemente establece ssid, password, ap_ssid y ap_password, luego guarda y reinicia. Si prefieres hacerlo a través de la interfaz web, también es simple, pero debes seguir el orden correcto:
- Conéctate al WiFi "MyAP" con tu cliente
- Apunta el navegador a "http://192.168.4.1"
- Introduce **primero** el ssid y la contraseña de los ajustes del AP, configúralo y reinicia
- Luego conéctate al ssid del AP recién definido, apunta el navegador de nuevo a "http://192.168.4.1"
- Ahora introduce el ssid y la contraseña de los ajustes STA y conéctate
Una vez definido el ssid de STA, el repetidor ya no ejecutará su propio servidor DHCP, sino que recibirá su IP del DHCP ascendente (ya no 192.168.4.1). Para conectarte a su página web o a la consola remota, puedes usar el nombre "esp-wifi-repeater.local", si tu cliente es compatible con mDNS, o tienes que buscar la dirección asignada en tu router ascendente (o en la consola serie con "show stats"). Siempre puedes restablecer el ESP mediante la consola y "reset factory".
### Resumen de las diferencias clave
| Característica | Router NAT | Puente de Capa 2 |
| :--- | :--- | :--- |
| **Arquitectura de red** | Crea una subred nueva y aislada | Extiende el dominio de difusión existente |
| **Direccionamiento IP** | Los clientes usan un pool secundario | Los clientes usan el servidor DHCP ascendente |
| **Descubrimiento (mDNS/UPnP)** | A menudo bloqueado/difícil | Totalmente compatible (transparente) |
| **Visibilidad ascendente** | Identidad del cliente oculta (NAT) | Identidad del cliente preservada |
| **Implementación** | Redes estándar | Proxying avanzado (Proxy ARP/Snooping) |
# Compilación y grabación
Para grabar directamente los binarios precompilados en el dispositivo, usa el [Web-Installer](https://martin-ger.github.io/esp_wifi_repeater/).
Si tienes Docker instalado, la forma más sencilla de acceder al entorno de compilación completo es conectar tu ESP8266 a /dev/ttyUSB0 y ejecutar la imagen 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
Para compilar la versión L2 WiFi Repeater, simplemente usa la opción VARIANT=bridge para el 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
Para configurar el entorno de compilación desde cero y compilar este binario, descarga e instala el esp-open-sdk (sugiero esta versión con la base NONOS SDK 2.2: https://github.com/xxxajk/esp-open-sdk). Asegúrate de poder compilar y descargar el ejemplo "blinky" incluido.
Luego descarga este árbol de código fuente en un directorio separado y ajusta la variable BUILD_AREA en el Makefile y las opciones deseadas en user/user_config.h. Los cambios de la configuración predeterminada se pueden realizar en user/config_flash.c. Compila el firmware esp_wifi_repeater con "make". "make flash" lo graba en un esp8266.
El árbol de código fuente incluye una versión binaria de liblwip_open más las inclusiones adicionales necesarias de mi fork de esp-open-lwip y un binario de la herramienta rboot. *No se requiere ninguna acción de instalación adicional para eso.* Solo si no quieres usar la biblioteca precompilada, revisa las fuentes desde https://github.com/martin-ger/esp-open-lwip . Úsala para reemplazar el directorio "esp-open-lwip" en el árbol de esp-open-sdk. Ejecuta "make clean" en el directorio esp_open_lwip y nuevamente un "make" en el directorio superior esp_open_sdk. Esto compilará un liblwip_open.a que contiene las características NAT. Reemplaza liblwip_open_napt.a con ese binario. También puedes compilar el binario "rboot.bin" desde https://github.com/raburton/rboot y reemplazarlo en el directorio raíz del proyecto.
*Actualización*: si lees en algún lugar de la web instrucciones de instalación que usan "0x10000.bin" - debido a OTA esto se ha cambiado a "0x02000.bin" ahora.
Si quieres usar los binarios de firmware precompilados completos, puedes grabarlos 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 para un ESP-01). Para el esp8285 debes usar -fs 1MB y -fm dout.
En Windows puedes grabarlo usando la "ESP8266 Download Tool" disponible en https://espressif.com/en/support/download/other-tools. Descarga los dos archivos 0x00000.bin y 0x02000.bin del directorio de firmware. Para un ESP12 genérico, un NodeMCU o un Wemos D1 usa la siguiente configuración (para un ESP-01 cambia FLASH SIZE a "8Mbit"):
<img src="https://raw.githubusercontent.com/martin-ger/esp_wifi_repeater/master/FlashRepeaterWindows.jpg">
Si el modo "QIO" falla en tu dispositivo, prueba "DIO" en su lugar. También echa un vistazo a la "Detected Info" para comprobar el tamaño y el modo del chip de flash. Si tu firmware descargado aún no se inicia correctamente, verifica con las sumas de verificación incluidas si los archivos binarios están posiblemente corruptos. Si dudas de que los binarios del firmware estén corruptos, descarga el repositorio completo como zip y extrae los binarios de ese zip; esto evita problemas de descarga HTTP (por ejemplo, conversiones CR-LF).
# Soporte de actualización OTA (Over the air)
Basado en el uso de la librería rboot: https://github.com/raburton/rboot y gracias a la contribución de christianchristensen.
El proceso de compilación crea dos copias del binario esp_wifi_repeater en el directorio de firmware: 0x02000.bin y 0x82000.bin. Para una instalación inicial es suficiente grabar solo 0x00000.bin (el cargador de arranque rboot) y 0x02000.bin (una copia del programa). El esp_wifi_repeater funcionará.
Si tienes al menos 1MB de flash, puedes hacer una actualización OTA (Over the air) con otra versión. Es decir, puedes cargar interactivamente un nuevo binario desde la CLI y cambiar a él. El otro binario se carga en la ubicación de memoria actualmente no activa (ya sea 0x02000 (rom0) o 0x82000 (rom1)) y se inicia si tiene éxito. También puedes cambiar interactivamente entre dos binarios instalados. La configuración actual se usará para ambos binarios (siempre que su formato no haya cambiado).
Puedes controlar las funciones OTA con los siguientes comandos:
- show ota: muestra el binario actualmente activo y la URL de la próxima actualización
- set ota_host _hostname_: define el nombre de host o la dirección IP del servidor OTA (predeterminado: "none")
- set ota_port _portno_: define el número de puerto del servidor OTA (predeterminado: 80)
- ota update: intenta descargar un nuevo binario (0x02000.bin o 0x82000.bin) a través de HTTP desde ota_host:ota_port y lo inicia
- ota switch: cambia al otro binario (si está instalado)
Para probar la función OTA, configura tu ESP (como STA o AP) para que esté conectado a la red con el servidor de actualización. Allí inicia un servidor web simple en el directorio de firmware, por ejemplo;```
cd firmware
python -m SimpleHTTPServer 8080
Establezca el parámetro hostname al nombre de host o IP de su computadora, establezca portno en 8080 y "save". Luego escriba en la CLI:``` ota update
Si está configurado correctamente, la actualización se iniciará y el ESP se reiniciará con el nuevo binario.
# Problemas conocidos
- Debido a las limitaciones de la implementación de SoftAP del ESP, hay un máximo de 8 estaciones conectadas simultáneamente.
- El ESP8266 requiere una fuente de alimentación buena, ya que produce picos de corriente de hasta 170 mA durante la transmisión (el consumo medio típico es de alrededor de 70 mA cuando el WiFi está activado). Compruebe primero la fuente de alimentación si su ESP funciona de forma inestable y se reinicia de vez en cuando. Un condensador grande entre Vdd y Gnd puede ayudar si experimenta problemas aquí.
# Licencias
El software es de código abierto. Los archivos fuente de terceros tienen su propia cabecera de licencia. Para todos los demás archivos se aplica la licencia MIT.