Troca de saberes Brasil – Índia

No ano de 2022 a APC iniciou uma nova iniciativa, um programa chamado CoP (do inglês Community of Pratice, ou comunidade da pratica) com o objetivo de reunir pessoas de todas as redes comunitárias para trabalharem juntos em 5 temas diferentes.

No CoP relacionado ao Openwrt/LibreMesh foi decidido por uma intercambio entre o nosso coletivo e o coletivo de redes comunitárias da India o coletivo Janastu.

Dentre os desafios dessa troca de saberes estavam algumas dos temas mais custosos para as redes comunitárias que utilizam redes mesh wifi. Em geral as redes comunitárias utilizam o famoso libremesh que é baseado em openwrt e nesse programa decidimos por uma imersão na India onde fomos por 3 meses para um convívio profundo e enriquecedor para tentar resolver as questões relacionadas com esse sistema.

Dos Desafios

Como dito anteriormente a maioria das redes comunitárias que utilizam libremesh para criarem suas redes acabam tendo dificuldades muito particulares dependendo do contexto e da necessidade de cada uma, mas os pontos primordiais que nos trouxeram a essa troca de saberes foram os seguintes:

  1. Portar novos dispositivos para funcionar com o Libremesh
  2. Entender como identificar erros e problemas na rede mesh
  3. Controle de trafego no libremesh

Suporte para novos dispositivos

O trabalho de dar suporte para novos dispositivos para o Libremesh pode ser feito de duas maneiras, a depender se o dispositivo já está suportado para o OpenWRT ou não. Se o dispositivo já estiver suportado para OpenWRT vai depender da versão do OpenWRT que o dispositivo recebeu suporte e se o dispositivo não tiver suportado para OpenWRT precisamos saber se o chip do roteador já tem suporte ou não, para facilitar veja o diagrama.

Esse é um processo bem básico e necessário para começar o suporte para novos dispositivos no libremesh. Como pode se notar os temas vão sempre passar de alguma maneira pelo entendimento mais profundo do openwrt que o sistema base do libremesh.

Para começar a entender tudo isso foi escolhido um roteador aleatório disponível no mercado brasileiro, o intelbrass wom 5a, todos os detalhes técnicos dessa jornada foi e está sendo registrado no forum do openwrt. Nesse caso o roteador não tem suporte para OpenWRT mas o chip tem suporte e o trabalho a ser feito vai ser de montar o suporte a partir do chip que já está suportado para OpenWRT.

Dispositivos no contexto Indiano

No contexto Indiano encontramos 4 dispositivos para trabalhar o suporte, e foi muito interessante desenhar esse caminho para cada um deles.

CPE 510 v3

O CPE501 v3 é um equipamento que ja usamos a muito tempo nas nossas instalações no Brasil e não seria nenhum problema utilizar o suporte para ele, porem encontramos alguns percalços para esse dispositivo.

O CPE510v3 ja tem suporte para openwrt porem na versão anterior para utilizarmos ele só fazíamos o cherry pick pois havia compatibilidade das versões. O chery pick consiste em uma técnica de trazer as modificações dos arquivos que alguém ja realizou em outro projeto, dessa maneira trazemos as modificações necessárias para que o suporte desenvolvedor fez para algum outro projeto de OpenWRT. Isso precisa ser feito com muito cuidado pois o código pode estar mal escrito ou pode não haver compatibilidade das versões uma vez que o OpenWRT pode ter realizado profundas mudanças de uma versão para outra.

Nesse caso as modificações por cherry Pick funcionaram para esse dispositivo, porem a placa de ethernet (que faz o cabo de rede funcionar) apresentou uma instabilidade, e ao que parece a versão do OpenWRT 19 atualizou o kernel linux e nessa atualização houve um problema com o drive do chip da entrada ethernet.

Porem na ultima versão do OpenWRT (versão 22) esse problema foi resolvido, assim para esse dispositivo ou devemos mexer no kernel linux e resolver o problema ou trabalhar no Libremesh para atualizar o suporte para a nova versão do OpenWRT.

CPE 220 v3

Esse dispositivo já tem suporte para OpenWRT na versão 19 assim foi simples obter o firmware, apenas entrando no sistema de compilação e selecionando o dispositivo na sessão target.

Imagem 1 – Menu de configurações do compilador para Libremesh mostrando o CPE220v3 como candidato

Ubiquiti Unifi AC mesh

Igualmente esse dispositivo já tem suporte ao OpenWRT e no sistema de compilação está presente nos targets.

Imagem 2 – Menu de configurações do compilador para Libremesh mostrando o UniFi AC-mesh como candidato

TP-Link EAP225-Outdoor v3

Esse equipamento já tem suporte nas novas versões do OpenWRT porem como foi um suporte recente e houve uma grande alteração no OpenWRT que foi a migração do comando switch para o DSA esse equipamento só vai poder ter suporte quando atualizar o Libremesh para a versão mais recente do OpenWRT, pois nos arquivos internos do Libremesh a criação dos perfis de conexão estão utilizando switch.

Identificando problemas com o Libremesh

Usando a rede Cowmesh, que foi desenvolvida pelo coletivo Janastu, vamos identificar os problemas da rede e entender como resolver alguns utilizando comandos básicos de Linux e os arquivos de log do Libremesh.

Inicialmente a rede se encontrava totalmente instável com muitos problemas de conexão nos pontos da rede pois a rede foi desenvolvida para ser uma rede cabeada mas com Libremesh em alguns dos roteadores. Isso gerou e ainda gera uma incompatibilidade muito grande de conceito, pois o protocolo mesh foi criado para que os roteadores se conectem por wifi (ja que o protocolo mesh é um protocolo de wifi) e não por cabo.

Inicialmente com um simples mtr foi possível ver que muitos pontos de acesso conectados pelo cabo estavam com o mesmo ip na rede e isso gerava uma série de conflitos, sendo assim modificamos esses ips para resolver sumariamente o problema.

Mantendo a estrutura de cabos e agora com uma nova topologia utilizando o libremesh a rede ficou dessa maneira:

Diagrama 2 – Nós da rede Cowmesh

E fazendo isso percebemos um problema muito maior, que por conta das múltiplas conexões de cabo encontramos o problema do loop na rede. Esse problema foi identificado olhando a saida do log do comando dmesg:

[1212624.132801] br-lan: received packet on bat0 with own address as source address (addr:90:9a:4a:80:28:71, vlan:0)
[1212630.036780] net_ratelimit: 1034 callbacks suppressed

Esse problema se dá quando em uma rede se conecta um cabo de rede em duas portas do mesmo roteador:

Imagem 3 – loop issue

Supostamente não é exatamente isso que está acontecendo, o que acontece é que o quando se conecta cabos para fazer a conexão dos nós, e não só cabos, todas as antenas em amarelo no diagrama representam conexões de cabo para o sistema também já que estão conectadas como bridge. E assim o BATMAM-adv, que é o protocolo no libremesh que gerencia as conexões em camada 2 (conexões ethernet) entende que todos os equipamentos conectados por cabo (linhas vermelhas no diagrama) estão conectadas no mesmo switch causando assim a ideia resumida na imagem do loop.

Para entender mais sobre o que é o loop e como pode ser resolvido no BATMAM-adv essa documentação tenta trazer uma solução. Que seria adicionar uma opção ao protocolo para que evite o problema do loop esse problema foi reportado ao time de desenvolvedores do Libremesh e depois de alguns testes, se funcionar bem, deverá ser incorporado na próxima versão.

Problemas para configuração do DNS de serviços locais

Uma grande questão ainda em aberto sobre simples e importantes configurações no Libremesh é sobre o cadastro de dominios locais no Libremesh. Na rede Cowmesh foram testados dois servidores locais com diferentes aplicativos instalados atrás de um ngnix-proxy. Em resumo isso significa que cada servidor pode ter muito mais que apenas um site ou aplicativo instalado nele, isso acaba gerando um nivel de complexidade para a configuração de DNSs locais no Libremesh.

O Libremesh foi desenhado para não ter que fazer muitas configurações de DNS na rede, a ideia por trás é que simplesmente deve se editar o hostname do servidor e o libremesh reconhece esse hostname como o DNS do serviço seguido do domínio da rede que por padrão vem como thisnode.info ou minodo.info, assim o endereço de cada serviço automaticamente vai ser http://hostname.thisnode.info ou http://hostname.minodo.info, e ainda pode ser acessado somente como http://hostname/ a depender do navegador.

Porem os serviços locais com mais de um site ou aplicativo vai ter mais de um domínio relacionado a ele, assim precisamos cadastrar os domínios em um arquivo especial localizado em `/etc/dnsmasq.d/local_server.conf` e o conteúdo do arquivo segue esse padrão:

cname=serv1.iruway.in,lokal-ahh-2022
cname=matrix.iruway.in,serv1.iruway.in
cname=chat.iruway.in,serv1.iruway.in
cname=kiwix.iruway.in,serv1.iruway.in
cname=meet.iruway.in,serv1.iruway.in
cname=learn.iruway.in,serv1.iruway.in
cname=torrent.iruway.in,serv1.iruway.in
cname=assets.iruway.in,serv1.iruway.in
cname=jellyfin.iruway.in,serv1.iruway.in

Onde nesse exemplo lokal-ahh-2022 é o hostname do servidor.

Uma complexidade maior foi encontrada para esse servidor em especifico que não estava aceitando ip por dhcp, para isso foi necessário fixar um ip para ele, editando o arquivo localizado em `/etc/config/dhcp` e no final do arquivo adicionado uma sessão como:

config hostrecord 'lokal-server'                                       
        list name 'lokal-ahh-2022'                                     
        list name 'serv1.iruway.in'                                    
        option ip '10.56.161.104'            

Para mais detalhes técnicos -> https://md.coolab.org/waqhC-3ERQKph1D-yTvuEA?view