martin-ger/esp_wifi_repeaterUm roteador NAT WiFi totalmente funcional (e agora também um Repetidor WiFi)
Um roteador NAT WiFi totalmente funcional (e agora também um repetidor WiFi, também conhecido como ponte L2)
NOVO 2026: 10 anos após o primeiro lançamento, finalmente se tornou o que sempre pretendeu ser: um verdadeiro Repetidor WiFi. Para não quebrar nenhuma documentação ou link existente, a edição padrão ainda permanece a conhecida versão de roteador NAT com todos os recursos avançados. Mas se você estiver interessado em uma verdadeira ponte L2 simplificada, veja abaixo na seção Repetidor WiFi ESP8266 - ponte L2.
Esta é uma implementação de um roteador NAT WiFi no esp8266 e esp8285. Também inclui suporte para firewall de filtragem de pacotes com ACLs, mapeamento de portas, modelagem de tráfego, hooks para monitoramento remoto (ou sniffing de pacotes), uma interface de gerenciamento MQTT, interação simples com GPIO e gerenciamento de energia. Para uma configuração com múltiplos roteadores em uma malha para cobrir uma área maior, um novo modo "Automesh" foi incluído.
Se você está procurando uma maneira de integrar o recurso NAT no seu projeto Arduino - veja aqui .
Roteador NAT EPS32 é o projeto avançado para o ESP32.
Cenários de uso típicos incluem:
Por padrão, o ESP atua como STA e como soft-AP e encaminha transparentemente qualquer tráfego IP através dele. Como usa NAT, nenhuma entrada de roteamento é necessária nem no lado da rede nem nas estações conectadas. As estações são configuradas via DHCP por padrão na rede 192.168.4.0/24 e recebem o endereço do servidor DNS da rede WiFi existente.
Medições mostram que pode atingir cerca de 5 Mbps em ambas as direções, então até streaming é possível.
Alguns detalhes são explicados neste vídeo.
Para flash direto no dispositivo, use o Instalador Web.
O esp_wifi_repeater inicia com a seguinte configuração padrão:
Após a primeira inicialização (ou reset de fábrica), ele oferecerá uma rede WiFi com um AP aberto e o ssid "MyAP". Ele ainda não tenta reconectar automaticamente a um AP uplink (pois não conhece um ssid ou senha válidos).
Conecte-se a esta rede WiFi e faça a configuração básica através de uma interface web simples ou a configuração completa com todas as opções via console.
A interface web permite a configuração de todos os parâmetros necessários para a funcionalidade básica de encaminhamento. Agradecimentos ao rubfi pelo trabalho principal nisso: https://github.com/rubfi/esp_wifi_repeater/ . Aponte seu navegador para "http://192.168.4.1". Esta página deve aparecer:
Primeiro insira os valores apropriados para a rede WiFi uplink, as "Configurações STA". Use a senha "none" para redes abertas. Marque a caixa "Automesh" se e somente se você realmente quiser usar o modo automesh. Clique em "Connect". O ESP reinicia e se conectará ao seu roteador WiFi. O LED de status deve piscar após alguns segundos.
Se você selecionou automesh, a configuração está concluída. Configurar as "Configurações do Soft AP" não é necessário, pois no modo automesh essas configurações são idênticas às "Configurações STA". O mesmo ssid será oferecido por todos os repetidores ESP conectados.
Se você não estiver usando automesh, pode recarregar a página e alterar as "Configurações do Soft AP". Clique em "Set" e o ESP reinicia novamente. Agora está pronto para encaminhar tráfego através do Soft AP recém-configurado. Esteja ciente de que essas alterações também afetam a interface de configuração, ou seja, para fazer mais configurações, conecte-se ao ESP através de uma das redes WiFi recém-configuradas. Para acesso através do Soft AP, lembre-se do endereço da rede do Soft AP se você o alterou (o ESP sempre tem o endereço x.x.x.1 nesta rede).
Se desejar, marque a caixa "lock" e clique em "Lock". Agora a configuração não pode mais ser alterada sem primeiro desbloqueá-la com a senha da rede WiFi uplink (defina uma mesmo que a rede seja aberta).
Se quiser inserir caracteres não ASCII ou especiais na interface web, você deve usar codificação hexadecimal no estilo HTTP, como "My%20AccessPoint". Isso resultará em uma string "My AccessPoint". Com essa codificação hexadecimal, você pode inserir qualquer valor de byte que desejar, exceto 0 (por razões internas do C).
Se você cometeu um erro e perdeu todo o contato com o ESP, ainda pode usar o console serial para recuperá-lo ("reset factory", veja abaixo).
A configuração avançada deve ser feita via linha de comando no console. Este console está disponível através da porta serial a 115200 baud ou via porta tcp 7777 (por exemplo, "telnet 192.168.4.1 7777" a partir de uma STA conectada).
Use os seguintes comandos para uma configuração inicial:
Novamente, se quiser inserir caracteres não ASCII ou especiais, você pode usar codificação hexadecimal no estilo HTTP (por exemplo, "My%20AccessPoint") ou, apenas no CLI, como atalho, aspas no estilo C com barra invertida (por exemplo, "My\ AccessPoint"). Ambos os métodos resultarão em uma string "My AccessPoint".
A linha de comando entende muitos mais comandos:
Suficiente para fazê-lo funcionar em praticamente todos os ambientes.
A maioria dos comandos set só são efetivos após save e reset.
Qualquer parte de uma entrada de linha de comando após um único "#" até o final da linha será tratada como comentário e ignorada.
Na configuração padrão, o GPIO2 é configurado para acionar um LED de status (conectado ao GND) com as seguintes indicações:
Com "set status_led numero_GPIO" o pino GPIO pode ser alterado (qualquer valor > 16, por exemplo, "set status_led 255" desabilitará completamente o LED de status). Quando configurado para GPIO1, funciona com o LED azul embutido nas placas ESP-01. No entanto, como GPIO1 também é o pino UART-TX, isso significa que o console serial não está funcionando. A configuração fica então limitada ao acesso de rede.
Se você puxar um GPIO selecionado para baixo por mais de 3 segundos, o repetidor fará um reset de fábrica e reiniciará com a configuração padrão. Com "set hw_reset numero_GPIO" o pino GPIO pode ser alterado (qualquer valor > 16, por exemplo, "set hw_reset 255" desabilitará o recurso de reset de fábrica por hardware).
Para muitos módulos, incluindo ESP-01s e NodeMCUs, provavelmente é uma boa ideia usar o GPIO 0 para isso, já que ele é usado de qualquer forma. No entanto, não é o pino padrão, pois pode interferir com o pull-down durante a gravação. Portanto, se você quiser usar um botão existente no GPIO 0 para reset de fábrica por hardware, configure-o com "set hw_reset 0" e "save" após a gravação. Um reset de fábrica acionado pelo pino HW NÃO redefinirá o número GPIO hw_reset configurado ("reset factory" do console fará isso).
Para permitir que clientes da rede externa se conectem a portas de servidor na rede interna, as portas devem ser mapeadas. Uma porta externa é mapeada para uma porta interna de um endereço IP interno específico. Use o comando "portmap add" para isso. Os mapeamentos de porta podem ser listados com o comando "show" e são salvos com a configuração atual.
No entanto, para garantir que o dispositivo esperado esteja ouvindo em um determinado endereço IP, é necessário garantir que este dispositivo tenha o mesmo endereço IP uma vez que ele ou o ESP seja reinicializado. Para conseguir isso, endereços IP fixos podem ser configurados nos dispositivos ou o ESP deve lembrar de seus leases DHCP. Isso pode ser alcançado com o comando "save dhcp". Ele salva o estado atual e todos os leases DHCP, para que sejam restaurados após a reinicialização. Os leases DHCP podem ser listados com o comando "show stats".
O suporte a WPA2 Enterprise (PEAP) foi agora incluído no projeto. Ele permite um "conversor" que traduz uma rede WPA2 Enterprise com autenticação PEAP em uma rede WPA2-PSK. Isso resolve um problema comum especialmente em ambientes universitários: a rede WiFi local é uma rede WPA2 Enterprise com autenticação PEAP-MSCHAPv2. Um exemplo muito proeminente é a rede "eduroam", disponível em muitas universidades ao redor do mundo. O problema é que muitos dispositivos IoT não conseguem lidar com a autenticação WPA2 Enterprise. Portanto, o desenvolvimento e demonstrações são difíceis. O que é muito útil é um "conversor" que faça login na rede WPA2 Enterprise e ofereça uma rede WPA-PSK mais simples para seus clientes.
Para usá-lo, defina os seguintes parâmetros de configuração: ssid, use_peap, peap_identity, peap_username e peap_password (você não precisa do parâmetro password usual). Esta configuração deve ser feita (e salva) via CLI e não está disponível na interface web.
O código atualmente não verifica o certificado do servidor RADIUS. É vulnerável a ataques MITM, quando alguém configura um AP falso e servidor RADIUS. Embora a senha não seja enviada em texto plano, o MSCHAPv2 usado é conhecido por ser quebrado. Além disso, esteja ciente do fato de que o ESP8266 agora contém sua senha de rede corporativa. Todo o tráfego que ele encaminha pode agora ser relacionado pelo administrador de rede à sua conta. Não o utilize indevidamente e ofereça a terceiros não confiáveis, por exemplo, configurando uma rede aberta. E mesmo quando o dispositivo está bloqueado, sua senha de rede corporativa pode ser extraída via porta serial da flash do ESP em texto simples.
Às vezes, você pode querer usar vários esp_wifi_repeaters em sequência ou em malha para cobrir uma distância ou área maior. Geralmente, isso pode ser feito sem problemas com roteadores NAT, na verdade você terá várias camadas de NAT. No entanto, isso significa que a conectividade é limitada: todos os nós podem falar com a internet, mas geralmente não há conectividade IP direta entre os nós. E, claro, a largura de banda disponível diminui quanto mais saltos você precisar. Mas usuários relataram que até 5 esp_wifi_repeaters em sequência funcionam muito bem.
Em tal configuração, a configuração é uma atividade demorada e propensa a erros. Para simplificar isso, o esp_wifi_repeater agora tem um novo modo: "Automesh". Basta configurar o SSID e a senha e ativar o "automesh" (no CLI com "set automesh 1" ou na interface web marcando a caixa de seleção). Isso fará o seguinte:Cada esp_wifi_repeater configurado dessa forma oferecerá automaticamente uma rede WiFi no AP com o mesmo SSID/senha ao qual está conectado. Os clientes podem usar as mesmas configurações de WiFi para a rede original ou para as repetidas. Cada esp_wifi_repeater configurado com "automesh" primeiro procurará o melhor outro AP para se conectar. Este é aquele que está mais próximo da rede WiFi original e tem a melhor intensidade de sinal (RSSI).
A intensidade do sinal é fácil de medir com uma varredura, mas qual é o AP mais próximo da rede WiFi original quando você vê vários APs com o mesmo SSID? Portanto, o protocolo usa um truque um tanto sujo: os esp_wifi_repeaters no modo "automesh" manipulam seu BSSID (na verdade, de acordo com o padrão IEEE 802.11, isso é o "ESSID" já que é um AP, mas o SDK o chama de "BSSID"), ou seja, o endereço MAC de sua interface AP, que é enviado em cada beacon frame cerca de 10 vezes por segundo. Ele usa o formato: 24:24:mm:rr:rr:rr. "24:24" é apenas o identificador único de um repetidor (há uma probabilidade mínima de colidir com o MAC de APs reais, mas podemos ignorar isso, pois podemos alterar esse prefixo se realmente necessário). "mm" significa o "nível da malha", esta é a distância em saltos até a rede WiFi original. Os últimos três "rr:rr:rr" são apenas números aleatórios para distinguir os vários ESPs. O AP original mantém seu BSSID, ou seja, aquele sem o prefixo "24:24" é reconhecido como raiz, chamado de nível de malha 0.
Agora, cada esp_wifi_repeater pode aprender qual outro esp_wifi_repeater está mais próximo da rede WiFi original, pode conectar-se a ele e escolher seu próprio BSSID de acordo. Além disso, o endereço IP da rede interna é ajustado ao nível da malha: 10.24.m.0. Isso cria uma árvore (uma malha muito especial) com o AP WiFi original como raiz e nós repetidores em vários níveis de malha (na verdade, funciona de maneira semelhante ao Spanning Tree Protocol (STP) na camada de enlace ou ao roteamento na camada de rede usando um protocolo de vetor de distância). Assim que uma perda de link de uplink é detectada, a configuração é reiniciada. Isso deve evitar loops, pois durante a (re)configuração também não são enviados beacons com um BSSID.
Por conveniência, o esp_wifi_repeater após a configuração "automesh" primeiro tenta verificar se pode se conectar a um AP de uplink. Se isso falhar, mesmo quando um AP com o SSID correto foi encontrado, ele assume que o usuário cometeu um erro com a senha e redefine para as configurações de fábrica. Depois de ter se conectado com sucesso uma vez, ele assumirá que a configuração está correta e continuará tentando após perda de conexão ou reinicialização pelo tempo que for necessário (para evitar um ataque DOS com um AP mal configurado).
Se houver mais de um ESP no alcance, pode haver um trade-off entre um caminho "ruim" mais curto e um caminho "bom" mais longo (bom e ruim em termos de qualidade de link). O parâmetro am_threshold determina o que é uma conexão ruim: se o RSSI em uma varredura for menor que esse limite, a conexão é ruim e um caminho com mais um salto é preferido. Ou seja, dado am_threshold igual a 85 e dois nós automesh detectados na varredura: A com nível 1 e RSSI -88 dB e B com nível 2 e RSSI -60 dB, então um link para A é considerado muito ruim (-88 dB < -am_threshold) e B é preferido. O novo nó se tornará um nó de nível 3 com uplink via B. am_threshold é fornecido como um valor positivo, mas significa um dB negativo. Um valor menor é melhor.
Se você quiser obter mais informações sobre a topologia de uma rede automesh, pode considerar conectar todos os nós a um broker MQTT e deixá-los publicar o tópico "Topology" (veja abaixo). Se você agora se inscrever em "/WiFi/+/system/Topology", receberá todas as informações do nó e do link, incluindo o RSSI (dos ESPs conectados) necessários para reconstruir o grafo completo e detectar links fracos na malha. O tópico TopologyInfo contém a seguinte estrutura JSON, que pode ser usada para reconstruir um grafo completo de uma rede 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 os dois parâmetros _am_scan_time_ e _am_sleep_time_, o gerenciamento de energia pode ser implementado no modo automesh, se você tiver conectado o GPIO16 ao RST. Após a inicialização, o esp_wifi_repeater escaneia por APs de uplink disponíveis por _am_scan_time_ segundos. Se nenhum for encontrado, ele entra em deepsleep por _am_sleep_time_ segundos e tenta novamente após a reinicialização (o padrão é 0 = desabilitado para ambos os parâmetros).
# Monitoramento
A partir do console, um serviço de monitoramento pode ser iniciado ("monitor on [portno]"). Este serviço espelha o tráfego da rede interna em formato pcap para um fluxo TCP. Por exemplo, com "netcat [external_ip_of_the_repeater] [portno] | sudo wireshark -k -S -i -" a partir de um computador na rede externa, você pode agora observar o tráfego na rede interna em tempo real. Use isso, por exemplo, para observar com quais sites da internet seus clientes internos estão se comunicando. Esteja ciente de que isso pelo menos dobra a carga no esp e na rede WiFi. Sob carga pesada, isso pode resultar em alguns pacotes sendo cortados ou até mesmo descartados na sessão de monitoramento. CUIDADO: deixar esta porta aberta é um potencial problema de segurança. Qualquer pessoa das redes locais pode se conectar e observar seu tráfego.
# Firewall
O roteador ESP possui um firewall básico integrado. ACLs (Listas de Controle de Acesso) podem ser aplicadas à interface SoftAP. Este é um pilar na segurança de IoT, quando o roteador é usado para trazer outros dispositivos IoT para a internet. Pode ser usado para evitar, por exemplo, que dispositivos IoT de terceiros "chamem para casa", sejam mal utilizados como bots de malware, e para proteger sua rede doméstica com PCs, tablets e smartphones de serem visíveis para dispositivos de automação residencial.
As quatro listas de ACL são nomeadas "from_sta", "to_sta", "from_ap" e "to_ap" para pacotes de entrada e saída em ambas as interfaces ("sta" significa as interfaces para os clientes conectados, "ap" a interface para o AP de uplink). As ACLs são definidas no "estilo CISCO IOS".
O exemplo a seguir é útil para uma sub-rede de convidados. Permite acesso à internet, mas não a nenhum outro endereço local (use o intervalo da sua rede local para o endereço xx.xx.xx.xx). Este conjunto de regras permite broadcasts locais de saída (para DHCP) e UDP 53 (DNS), qualquer outro pacote para a sub-rede do roteador upstream será bloqueado, todos os outros pacotes podem passar para 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
O próximo exemplo é mais restritivo e é útil quando você planeja uma sub-rede IoT com acesso muito restrito no AP do ESP. Ele também permitirá broadcasts locais de saída (para DHCP), UDP 53 (DNS) e TCP 1883 (MQTT) para um broker local, mas quaisquer outros pacotes serão bloqueados, incluindo acesso arbitrário à internet (você pode adaptar a quarta instrução conforme suas necessidades para habilitar outros 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 para a direção "to_sta" também podem ser definidas, mas geralmente isso não é necessário, pois a direção reversa é bastante protegida contra tráfego não solicitado pela tradução de NAT.
As ACLs consistem em regras de filtragem que são processadas para cada pacote. Cada regra consiste em um protocolo (IP, TCP ou UDP), endereço/porta de origem, endereço/porta de destino, bem como uma ação "allow" ou "deny". No caso de IP simples, apenas endereços são fornecidos, sem portas. Regras IP incluem pacotes TCP e UDP. Endereços podem ser fornecidos como endereços de sub-rede na notação "/", ex.: 192.168.178.0/24. Também "any" pode ser usado como curinga, correspondendo a qualquer endereço ou número de porta. Uma regra é definida pelo comando "acl":
- acl [from_sta|to_sta|from_ap|to_ap] [TCP|UDP|IP] _src-ip_ [_src_port_] _dest-ip_ [_dest_port_] [allow|deny|allow_monitor|deny_monitor]
As regras são processadas de cima para baixo na ordem em que aparecem na lista. A primeira regra que corresponde a um pacote é aplicada e determina se um pacote é permitido (e encaminhado) ou negado (e descartado). Isso significa: casos especiais primeiro, regras gerais no final. Se houver regras em uma ACL, todos os pacotes que não corresponderem a nenhuma regra são negados por padrão. Assim, a última regra "from_sta IP any any deny" no exemplo acima não é realmente necessária, pois é o padrão de qualquer forma. Se uma ACL estiver vazia, todos os pacotes são permitidos.
A definição de regras ACL também funciona de cima para baixo: uma nova regra é sempre adicionada ao final de uma lista. Para alterar uma ACL, primeiro você deve limpá-la completamente (acl from_sta clear) e depois reconstruí-la. As ACLs são salvas com a configuração. "show acl" exibirá as ACLs mais estatísticas sobre o número de acertos para cada regra e o número total de pacotes permitidos e negados.
Com o comando "set acl_debug 1", um resumo de todos os pacotes negados é impresso no console. Além disso, um tópico MQTT pode publicar esse resumo. Isso pode ser usado para configuração de firewall para determinar quais regras são necessárias para que os dispositivos conectados funcionem. Também dá uma dica se ocorrer tráfego inesperado (e for negado).
Para análise mais aprofundada, o serviço de monitoramento pode ser usado (até pacotes negados são relatados ao monitor antes de serem descartados). Quando o monitor é iniciado com o comando "monitor acl _port_", as ACLs podem ser usadas como filtros online. Todas as regras que são definidas como "allow_monitor" em vez de "allow" e "deny_monitor" em vez de "deny" são processadas normalmente, resultando na permissão ou encaminhamento de um pacote, mas também enviam o pacote para o monitor. Assim, uma lista de regras que basicamente "allow" ou "allow_monitor" todos os pacotes ainda faz sentido, pois pode ser usada para selecionar já durante o tempo de captura qual pacote deve ser gravado. Ex.: uma lista:```
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 os pacotes e também selecionará todos os pacotes para monitoramento que vão de uma estação para a sub-rede 192.168.0.0/16 (local) e da 192.168.0.0/16 para uma estação. É claro que tal filtro também pode ser aplicado após a captura a um traço de monitoramento completo, mas se você já sabe o que está procurando, esses filtros online ajudarão a reduzir drasticamente a sobrecarga de monitoramento. Também pode ser usado para depurar todas as regras de firewall de negação simplesmente usando "deny_monitor" em vez de deny.
Por padrão, a interface AP está em NAT, de modo que qualquer nó conectado ao AP será capaz de acessar o mundo exterior de forma transparente através da interface STA do ESP. Portanto, nenhuma ação adicional é necessária, se você não for um verdadeiro entusiasta de redes.
Para aqueles que estão realmente interessados em configuração de rede adicional: a pilha IPv4 lwip do ESP foi aprimorada para este projeto com suporte a rotas estáticas: "show route" exibe a tabela de roteamento com todas as rotas conhecidas, incluindo os links para as interfaces de rede conectadas (a interface AP e a interface STA). O roteamento entre essas duas interfaces funciona sem configuração adicional. Rotas adicionais para outras redes podem ser definidas através do comando "route add network gateway", conhecido de computadores Linux ou roteadores. Um comando "save" salva o estado atual da tabela de roteamento na configuração flash.
Aqui está um exemplo simples do que pode ser feito com rotas estáticas. Dada a seguinte configuração de rede com dois ESPs conectados com as interfaces STA através de um roteador 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 tem uma segunda rede atrás do seu AP com diferentes endereços de rede: 10.0.1.0/24 e 10.0.2.0/24. O ESP1 pode fazer ping para o ESP2 no 192.168.1.20, mas não para o 10.0.2.1, pois não sabe que pode alcançá-lo através do 192.168.1.20. Isso muda se você adicionar duas rotas estáticas. No ESP1:```
route add 10.0.2.0/24 192.168.1.20
e no ESP2:``` route add 10.0.1.0/24 192.168.1.10
Agora, um "ping 10.0.2.1" no ESP1 será bem-sucedido. É enviado para 192.168.1.20 e então respondido pelo ESP2.
Agora, em cada rede, um cliente adicional se conecta (com endereços 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 |
Agora até o cliente STA1 com o endereço local 10.0.1.2 pode fazer ping para STA2 com 10.0.2.2, pois ele envia sua requisição primeiro ao seu roteador padrão ESP1 e este sabe que todos os pacotes destinados a um endereço 10.0.2.0/24 devem ser encaminhados para 192.168.1.20. Lá, o ESP2 sabe como enviá-lo para STA2. O mesmo se aplica para a resposta no sentido contrário.
Isso permite configurar uma topologia multi-estrela de ESPs, onde cada ESP e seus clientes STA podem se alcançar diretamente (sem necessidade de portmaps). A configuração das rotas necessárias talvez seja um pouco trabalhosa - mas é um bom exercício de redes. O próximo passo seria portar um protocolo de roteamento dinâmico como RIP para o ESP...
Definindo upstream_kbps e downstream_kbps para um valor diferente de 0 (0 é o padrão), você pode limitar a taxa máxima de bits do AP do ESP. Este valor é um limite que se aplica ao tráfego de todos os clientes conectados. Pacotes que excederiam a taxa de bits definida são descartados. O modelador de tráfego usa o algoritmo "Token Bucket" com um tamanho de bucket atualmente de quatro vezes a taxa de bits por segundo, permitindo rajadas quando não houve tráfego antes.
Desde a versão 1.3, o roteador possui um cliente MQTT integrado (graças a Tuan PM por sua biblioteca https://github.com/tuanpmt/esp_mqtt). Isso pode ajudar a integrar o roteador/repetidor na IoT. Um sistema de automação residencial pode, por exemplo, tomar decisões com base em informações sobre as estações atualmente associadas, pode ligar e desligar os repetidores (por exemplo, com base em uma programação de horários), ou pode simplesmente ser usado para monitorar a carga. O roteador pode ser conectado a um broker MQTT local ou a um broker disponível publicamente na nuvem. No entanto, atualmente não suporta criptografia TLS.
Por padrão, o cliente MQTT está desabilitado. Ele pode ser habilitado definindo o parâmetro de configuração "mqtt_host" para um hostname diferente de "none". Para configurar o MQTT, você pode definir os seguintes parâmetros:
Os parâmetros MQTT podem ser exibidos com o comando "show mqtt".
O roteador pode publicar os seguintes tópicos de status periodicamente (a cada mqtt_interval):
Além disso, o repetidor pode publicar por evento:
Como LWT e relatório de status, o repetidor publica:
O roteador pode ser configurado usando os seguintes tópicos:
Se você deseja que o roteador publique, por exemplo, apenas Vdd, seu IP e a saída da linha de comando, defina o mqtt_mask para 0x0001 | 0x0002 | 0x0040 (= "set mqtt_mask 0043").
O esp_wifi_repeator agora inclui suporte para uma placa de rede Ethernet ENC28J60 conectada via SPI (Graças a Andrew Kroll https://github.com/xxxajk por seu ótimo trabalho para acertar), se você ativar a opção de compilação HAVE_ENC28J60 em "user_config.h". A interface Ethernet suportará cerca de 1 Mbps quando o ESP estiver rodando a 160 MHz. Ligar a interface AP e usar a Ethernet como uplink transformará o esp_wifi_repeator em um AP barato para dispositivos WiFi (por exemplo, outros ESPs).
A conexão via SPI deve 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
Fios curtos e soldados funcionam melhor. Além disso, você precisará de um transistor para desacoplar o GPIO15, caso contrário, seu ESP não inicializará mais, veja: https://esp8266hints.wordpress.com/category/ethernet/ . Além disso, é importante ter uma boa fonte de alimentação: o ENC28j60 precisa de cerca de 160mA quando ativo. Para mim, falha se eu tentar usar o 3.3V da placa ESP.
Agora você pode configurar a nova interface Ethernet:
- set eth_enable [0|1]: ativa/desativa uma placa de rede Ethernet ENC28J60 no barramento SPI (padrão: 0 - desativado)
- set eth_ip _ip-addr_: define um endereço IP estático para a interface ETH
- set eth_netmask _netmask_: define uma máscara de rede estática para a interface ETH
- set eth_gw _gw-addr_: define um endereço de gateway estático para a interface ETH
- set eth_dhcpd [0|1]: inicia um servidor DHCP para endereços IP dinâmicos na interface ETH (padrão: 0 - desativado)
# Gerenciamento de Energia
O repetidor monitora sua tensão de alimentação atual (mostrada no comando "show stats"). Isso só funciona se o 107º byte em esp_init_data_default.bin, chamado vdd33_const, estiver definido como 255(0xFF). A maneira mais fácil de conseguir isso é gravar esp_init_data_default_v08_vdd33.bin na flash (veja abaixo).
Se _vmin_ (em mV, padrão 0) for definido com um valor > 0 e a tensão de alimentação cair abaixo desse valor, ele entrará no modo de sono profundo por _vmin_sleep_ segundos. Se você conectou GPIO16 a RST (o que é difícil de soldar em um ESP-01), ele será reinicializado após esse intervalo, tentará reconectar e continuará suas medições. Se _vmin_ for salvo com a configuração, ele dormirá repetidamente até que a tensão de alimentação suba acima do limite. Essas configurações são especialmente (apenas?) úteis se você alimentou o ESP com uma bateria (de lítio) sem proteção contra descarga profunda. Então um valor de 2900mV-3000mV é provavelmente útil, pois reduz o consumo de energia do ESP ao mínimo e você tem muito mais tempo para recarregar ou substituir a bateria antes de danificá-la. Isso só faz sentido se você tiver o ESP conectado diretamente à bateria. Se você tiver lógica adicional, ela ainda consumirá a bateria.
Você pode enviar o ESP para dormir manualmente uma vez usando o comando "sleep".
Atenção: Se você salvar um valor de _vmin_ maior que a tensão de alimentação máxima na flash, o repetidor será desligado imediatamente a cada reinicialização. Então você terá que limpar toda a configuração gravando blank.bin (ou qualquer outro arquivo) em 0x0c000.
# Repetidor WiFi - Ponte L2
O projeto agora oferece dois modos operacionais distintos: **Roteador NAT** e **Ponte de Camada 2** (referido como "modo Repetidor"). Embora ambos os modos estendam a cobertura de rede, eles diferem fundamentalmente na forma como lidam com o tráfego e a identidade dos dispositivos.
### Modo Roteador NAT (Padrão)
Neste modo, conforme descrito acima, o dispositivo atua como um gateway padrão. Ele cria uma nova sub-rede e realiza a Tradução de Endereços de Rede (NAT) para todos os dispositivos conectados ao seu Ponto de Acesso (AP).
* **Isolamento de Sub-rede**: Os clientes conectados estão em uma sub-rede privada (por exemplo, 192.168.4.x) e são isolados da rede primária.
* **Identidade de Tráfego**: Todo o tráfego dos clientes aparece para o roteador principal como se originasse do próprio endereço IP/MAC do ESP8266.
* **Simplicidade**: Não requer configuração especial no roteador upstream e é compatível com praticamente todas as redes Wi-Fi padrão.
* **Limitação**: Dispositivos na rede primária não podem facilmente iniciar conexões com dispositivos atrás do repetidor devido à barreira NAT, a menos que você use mapeamento de portas.
### Modo Ponte de Camada 2 (Variante "Repetidor")
Este modo implementa uma ponte transparente de Camada 2 (Camada de Enlace de Dados). O ESP8266 estende a rede primária existente em vez de criar uma sub-rede secundária.
* **Ponte Transparente**: O ESP8266 faz a ponte do tráfego no nível do quadro Ethernet. Os clientes conectados recebem endereços IP diretamente do servidor DHCP da rede primária (via snooping/relé DHCP).
* **Rede Unificada**: Todos os dispositivos (tanto no repetidor quanto no roteador principal) existem no mesmo domínio de broadcast L2.
* **Visibilidade dos Dispositivos**: Dispositivos atrás do repetidor mantêm suas identidades originais de MAC e IP na rede principal. Isso permite que protocolos de descoberta local (como mDNS/Bonjour, UPnP ou descoberta de rede) funcionem perfeitamente em toda a rede.
* **Complexidade**: Requer tratamento avançado, como Proxy ARP e snooping DHCP, para garantir que a rede upstream roteie corretamente o tráfego de volta para os clientes "ocultos" conectados através do repetidor.
* **Caso de Uso**: Ideal quando é necessária a descoberta de dispositivos (por exemplo, controlar uma impressora ou dispositivo doméstico inteligente via aplicativo de telefone) em toda a rede.
O modo repetidor tem menos recursos: roteamento, mapeamento de portas e DHCP não são necessários, ACLs e Automesh também não fazem muito sentido, assim como o monitoramento de rede via pcap. Portanto, todos esses recursos não estão disponíveis no modo repetidor. Além disso, o MQTT foi removido. Os recursos restantes ainda estão disponíveis via console ou console remoto.
Você pode encontrar os binários pré-compilados na pasta "firmware-repeater".
A configuração inicial da versão do modo repetidor é basicamente tão simples quanto para o roteador NAT. Via console serial, basta definir ssid, password, ap_ssid e ap_password, depois salvar e reiniciar. Se você quiser fazer isso via interface web, também é simples, mas você deve obedecer à ordem correta:
- Conecte-se ao WiFi "MyAP" com seu cliente
- Aponte o navegador para "http://192.168.4.1"
- Digite **primeiro** o ssid e a senha das Configurações de AP, defina e reinicie
- Em seguida, conecte-se ao ssid do AP que você definiu recentemente, aponte o navegador novamente para "http://192.168.4.1"
- Agora digite o ssid e a senha das configurações de STA e conecte
Uma vez que o ssid STA esteja definido, o repetidor não executará mais seu próprio servidor DHCP, mas receberá seu IP do DHCP upstream (não mais 192.168.4.1). Para conectar-se à sua página web ou ao console remoto, você pode usar o nome "esp-wifi-repeater.local", se seu cliente suportar mDNS, ou você terá que procurar o endereço atribuído no seu roteador upstream (ou no console serial com "show stats"). Você pode sempre redefinir o ESP via console e "reset factory".
### Resumo das Principais Diferenças
| Recurso | Roteador NAT | Ponte de Camada 2 |
| :--- | :--- | :--- |
| **Arquitetura de Rede** | Cria nova sub-rede isolada | Estende domínio de broadcast existente |
| **Endereçamento IP** | Clientes usam pool secundário | Clientes usam servidor DHCP upstream |
| **Descoberta (mDNS/UPnP)** | Frequentemente bloqueada/difícil | Totalmente suportada (Transparente) |
| **Visibilidade Upstream** | Identidade do cliente oculta (NAT) | Identidade do cliente preservada |
| **Implementação** | Rede padrão | Proxy avançado (Proxy ARP/Snooping) |
# Compilação e Gravação
Para gravação direta dos binários pré-compilados no dispositivo, use o [Web-Installer](https://martin-ger.github.io/esp_wifi_repeater/).
Se você tiver o Docker instalado, a maneira mais fácil de obter acesso ao ambiente de compilação completo é conectar seu ESP8266 a /dev/ttyUSB0 e executar a imagem 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 construir a versão L2 WiFi Repeater, basta usar a opção VARIANT=bridge para o 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 o ambiente de compilação do zero e compilar este binário, baixe e instale o esp-open-sdk (sugiro esta versão com o NONOS SDK base 2.2: https://github.com/xxxajk/esp-open-sdk). Certifique-se de que consegue compilar e baixar o exemplo "blinky" incluído.
Em seguida, baixe esta árvore de código fonte em um diretório separado e ajuste a variável BUILD_AREA no Makefile e quaisquer opções desejadas em user/user_config.h. Alterações na configuração padrão podem ser feitas em user/config_flash.c. Compile o firmware esp_wifi_repeater com "make". "make flash" grava no esp8266.
A árvore de código fonte inclui uma versão binária do liblwip_open mais os includes adicionais necessários do meu fork do esp-open-lwip e um binário da ferramenta rboot. *Nenhuma ação de instalação adicional é necessária para isso.* Apenas se você não quiser usar a biblioteca pré-compilada, faça checkout dos fontes de https://github.com/martin-ger/esp-open-lwip . Use-o para substituir o diretório "esp-open-lwip" na árvore do esp-open-sdk. Execute "make clean" no diretório esp_open_lwip e novamente um "make" no diretório superior esp_open_sdk. Isso irá compilar um liblwip_open.a que contém os recursos NAT. Substitua liblwip_open_napt.a por esse binário. Também você pode compilar o binário "rboot.bin" de https://github.com/raburton/rboot e substituí-lo no diretório raiz do projeto.
*Atualização*: se você leu em algum lugar na web instruções de instalação usando "0x10000.bin" - devido ao OTA isso foi alterado para "0x02000.bin" agora.
Se você quiser usar os binários de firmware pré-compilados completos, pode gravá-los com "esptool.py --port /dev/ttyUSB0 write_flash -fs 4MB -ff 80m -fm dio 0x00000 firmware/0x00000.bin 0x02000 firmware/0x02000.bin" (use -fs 1MB para um ESP-01). Para o esp8285 você deve usar -fs 1MB e -fm dout.
No Windows você pode gravá-lo usando a "ESP8266 Download Tool" disponível em https://espressif.com/en/support/download/other-tools. Baixe os dois arquivos 0x00000.bin e 0x02000.bin do diretório firmware. Para um ESP12 genérico, um NodeMCU ou um Wemos D1 use as seguintes configurações (para um ESP-01 altere FLASH SIZE para "8Mbit"):
<img src="https://raw.githubusercontent.com/martin-ger/esp_wifi_repeater/master/FlashRepeaterWindows.jpg">
Se o modo "QIO" falhar no seu dispositivo, tente "DIO". Também dê uma olhada nas "Informações Detectadas" para verificar o tamanho e o modo do chip flash. Se o firmware baixado ainda não iniciar corretamente, verifique com as somas de verificação anexadas se os arquivos binários estão possivelmente corrompidos. Se você tiver dúvidas sobre a corrupção dos binários do firmware, baixe o repositório completo como zip e extraia os binários desse zip - isso evita problemas de download HTTP (por exemplo, conversões CR-LF).
# Suporte a atualização OTA (Over the air)
Baseado no uso da biblioteca rboot: https://github.com/raburton/rboot e agradecimentos à contribuição de christianchristensen.
O processo de compilação cria duas cópias do binário esp_wifi_repeater no diretório firmware: 0x02000.bin e 0x82000.bin. Para uma instalação inicial, basta gravar 0x00000.bin (o boot loader rboot) e 0x02000.bin (uma cópia do programa). O esp_wifi_repeater funcionará.
Se você tiver pelo menos 1MB de flash, pode fazer uma atualização OTA com outra versão. Isto é, você pode carregar interativamente um novo binário da CLI e alternar para ele. O outro binário é carregado na localização de memória atualmente não ativa (0x02000 (rom0) ou 0x82000 (rom1)) e iniciado em caso de sucesso. Você também pode alternar interativamente entre dois binários instalados. A configuração atual será usada para ambos os binários (desde que seu formato não tenha sido alterado).
Você pode controlar os recursos OTA com os seguintes comandos:
- show ota: mostra o binário atualmente ativo e a URL da próxima atualização
- set ota_host _hostname_: define o hostname ou endereço IP do servidor OTA (padrão: "none")
- set ota_port _portno_: define o número da porta do servidor OTA (padrão: 80)
- ota update: tenta baixar um novo binário (0x02000.bin ou 0x82000.bin) via HTTP a partir de ota_host:ota_port e o inicia
- ota switch: alterna para o outro binário (se instalado)
Para testar o recurso OTA, configure seu ESP (como STA ou AP) para estar conectado à rede com o servidor de atualização. Lá, inicie um servidor web simples no diretório firmware, por exemplo;```
cd firmware
python -m SimpleHTTPServer 8080
Defina o parâmetro hostname para o hostname ou IP do seu computador, defina portno para 8080 e "save". Em seguida, digite na CLI:``` ota update
Se configurado corretamente, a atualização será iniciada e o ESP será reiniciado com o novo binário.
# Problemas Conhecidos
- Devido às limitações da implementação SoftAP do ESP, há um máximo de 8 estações conectadas simultaneamente.
- O ESP8266 requer uma boa fonte de alimentação, pois produz picos de corrente de até 170 mA durante a transmissão (consumo médio típico é cerca de 70 mA quando o WiFi está ligado). Verifique a fonte de alimentação primeiro, se o seu ESP funcionar de forma instável e reiniciar de vez em quando. Um capacitor grande entre Vdd e Gnd pode ajudar se você tiver problemas aqui.
# Licenças
O software é de código aberto. Arquivos de origem de terceiros têm seu próprio cabeçalho de licença. Para todos os outros arquivos, a licença MIT se aplica.