O que é a revolta de atlas
A revolta de atlas se refere a um conjunto de projetos e técnicas desenvolvidos principalmente na comunidade brasileira de redes mesh e telecomunicações comunitárias, ligados ao uso de hardware e firmware open-source para contornar restrições operacionais em infraestrutura de comunicação. O nome vem de uma referência simbólica ao mito grego — carregar o peso da conectividade onde ela não chega de forma convencional. Na prática, isso envolve equipamentos como roteadores modificados com OpenWrt, AntMiner adaptado como rádio, e soluções baseadas em ESP32 para redes de sensores mesh. O movimento cresceu bastante no Nordeste brasileiro, especialmente em comunidades rurais e periferias onde a operação das grandes provedoras simplesmente não compensa financeiramente.
Entendendo a revolta de atlas no contexto técnico
O conceito central gira em torno de três camadas: hardware acessível, firmware customizado e topologia de rede mesh. Cada nó funciona como um repetidor autônomo que encaminha pacotes usando protocolos como B.A.T.M.A.N. advanced ou OLSRv2. A ideia não é apenas criar internet alternativa — é construir uma rede que não dependa de backhaul pago ou concessão estatal. O que muita gente não entende no início é que a revolta de atlas não é um software único. É uma abordagem. Você pode reproduzir o conceito com uma faixa ampla de equipamentos, desde um RouterBoard 750GL até dois ESP32-combo WiFi conectados via UART. A flexibilidade é exatamente o ponto.
No campo, a configuração típica que costumo recomendar usa um nó central com rádio direcional de 5GHz apontando para o backhaul, e nós periféricos com radios omnidirecionais de 2.4GHz para distribuição interna. O throughput real em cenários com interferência moderada fica na faixa de 8 a 15 Mbps por salto, o que é suficiente para WhatsApp, e-mail e navegação básica. Vídeo em HD sofre, mas funciona em horários de baixa demanda. Um problema específico que encontrei e que quase me fez desistir de um projeto foi o efeito de multipath em ambientes urbanos densos com muitos nós. O B.A.T.M.A.N. advanced tende a fazer loop de routing quando a topologia tem muitas conexões redundantes mal configuradas. A solução que funcionou foi desativar o multicast reinforcement em todos os nós intermediários e deixar apenas no gateway de saída. Reduzi a latência de 120ms para cerca de 35ms naquela configuração sem trocar nenhum cabo.
Como montar sua própria rede baseada na revolta de atlas
O primeiro passo é definir o escopo. Quantos nós? Qual a distância média entre eles? Qual o backhaul disponível — se houver algum? Essas respostas determinam o hardware e a configuração de firmware. Partir direto para a compra sem responder isso gera gasto desnecessário e frustração. Hardware recomendado para começar:
- Nó central: TP-Link TL-WR1043ND ou GL-Inet GL-MT300N-V2, ambos com suporte nativo a OpenWrt
- Nós de repetição: ESP32-S3 com módulo WiFi integrado, custo baixo e consumo reduzido
- Rádio direcional: MikroTik RBD52G-5HacD2nHD para enlaces de até 3km
- Fonte de energia: adapteres 12V 2A para os roteadores, e power banks para os nós ESP32
Firmware: OpenWrt 23.05 (Stable) com pacotes batman-adv e odhcpd. Evite versões snapshot para produção — têm instabilidades conhecidas no stack de multicast que podem derrubar a rede inteira durante atualizações de topologia. Configuração do batman-adv no gateway central:
👉 Clique no botão abaixo para saber mais sobre o assunto!
opkg update
opkg install batman-adv kmod-batman-adv
echo 'batman-adv' >> /etc/modules.d/batman-adv
Depois, no /etc/config/network, adicione a interface mesh:
config interface 'mesh0'
option proto 'static'
option ipaddr '192.168.100.1'
option netmask '255.255.255.0'
option ifname '@[eth0.1 bat0]'
Dica técnica não óbvia: a interface eth0.1 é o bridge interno que conecta a WLAN ao batman-adv. Se você pular essa etapa e ligar o bat0 diretamente na eth0 bruta, vai ter perda de pacotes e o protocolo vai considerar todos os vizinhos como down. Isso acontece porque o batman-adv precisa do bridge para gerenciar os ports corretamente. Para cada nó repetidor, a configuração é similar, mas o IP muda para 192.168.100.x e você não precisa configurar DHCP server — o gateway central cuida disso. Se quiser isolamento de hosts entre nós (recomendável para segurança), ative o bridge isolation no switch config do OpenWrt.
O backhaul é onde a maioria dos projetos trava. Se você tiver acesso a um link de internet fixo no nó central, configure um VPN exit com WireGuard. Caso contrário, considere um enlace ponto-a-ponto com os rádios MikroTik citados, configurando um dos lados como wireless wds e o outro como client. A configuração leva cerca de 20 minutos e estabiliza em 5 a 10 minutos após o uplink. Problema comum e solução: muitos relatam que os nós ESP32 desconectam aleatoriamente após 6 a 12 horas de operação. A causa raiz é o watchdog do ESP-IDF que entra em estado de panic quando o buffer de rx da UART transborda durante tráfego mesh intenso. O workaround é limitar a taxa de transmissão dos nós periféricos para 1Mbps e adicionar um script cron que reinicia a interface bat0 a cada 6 horas. Não é elegante, mas resolve o problema sem custo adicional.
Limitações reais da revolta de atlas
A abordagem funciona bem para conectividade básica em comunidades pequenas — até 30 nós com topologia razoavelmente plana. Ela não escala para redes metropolitanas. O overhead do batman-adv cresce exponencialmente com o número de nós, e a convergência da rota pode levar mais de 30 segundos em topologias com 50+ nós e múltiplos saltos. Outro ponto crítico: a revolta de atlas não substitui infraestrutura legal. Em municípios onde há fiscalização ativa de radiocomunicações, nós em locais elevados com antenas direcionais podem ser interditados. O ideal é operar em frequências ISM licenciadas-isentas (2.4GHz e 5.8GHz) e manter potência abaixo de 20dBm EIRP nos rádios internos. Para enlaces de longa distância, use hardware homologado pela Anatel ou aceite o risco.
Se o seu objetivo é cobertura residencial de larga banda (vários usuários simultâneos em vídeo e download), considere alternativas como LoRaWAN para sensores e Starlink para backhaul, que oferecem melhor relação custo-benefício em áreas rurais isoladas. A revolta de atlas é mais adequada para contextos de low-bandwidth, alta disponibilidade e autonomia comunitária. O projeto continua evoluindo na comunidade brasileira de telecom comunitária. Grupos no Telegram e fóruns como o Redes Livres publicam atualizações de firmware e mapas de nós ativos. Se estiver começando, participe desses canais antes de comprar hardware — a informação sobre compatibilidade e topologias testadas vale mais que qualquer guia genérico.
