Teste de bancada da imagem no EAP225-Outdoor v3

Objetivo

Compilar uma imagem com sucesso não é suficiente para concluir que ela funciona no equipamento real.

Depois da instalação, precisamos verificar separadamente:

1. se o hardware foi reconhecido corretamente;
2. se a configuração esperada foi criada;
3. se os rádios e as interfaces de malha estão presentes;
4. se existe associação 802.11s real com outro nó;
5. se os protocolos de roteamento encontram vizinhos e trocam rotas;
6. se os componentes adicionais do perfil foram incorporados à imagem;
7. quais funções ainda precisam de testes específicos.

Esta página documenta a primeira rodada de testes em bancada da imagem personalizada construída nos tutoriais anteriores.

O equipamento testado foi:

TP-Link EAP225-Outdoor v3
OpenWrt 24.10.7
LibreMesh master 0b6b5c5
ath79 / generic

Os resultados descritos abaixo correspondem a essa combinação específica de hardware e firmware.

1. Confirme hardware, sistema e versão

Depois do boot:

ubus call system board
cat /etc/openwrt_release
cat /etc/os-release
uptime

Na reprodução, o sistema identificou:

Model: TP-Link EAP225-Outdoor v3
Board: tplink,eap225-outdoor-v3
Kernel: 6.6.141
OpenWrt: 24.10.7
Target: ath79/generic

O LibreMesh incorporado à imagem corresponde ao commit:

0b6b5c53c6ec1805bd74aaf27237ad2c31a63a7c

A mesma identificação pode ser conferida no LuCI:

A hora local mostrada pela interface pode estar incorreta enquanto o equipamento estiver sem sincronização de horário pela rede. Para identificar a firmware, prefira modelo, target, versão e commit.

2. Observe também o estado no LimeApp

O LimeApp apresenta uma visão resumida do equipamento e da conectividade:

Nesta captura o equipamento estava sem uplink para a Internet. Por isso, os indicadores IPv4, IPv6 e DNS aparecem com falha.

Em outro momento da bancada, ao conectar o EAP225 diretamente a uma rede Ethernet com acesso à Internet, a conectividade passou a funcionar. Não foi possível manter simultaneamente esse uplink e o mesmo caminho de acesso administrativo usado para produzir as capturas, portanto esse resultado ficou registrado textualmente e não por screenshot.

3. Verifique as interfaces de rede

Pelo terminal:

ip addr
ip -4 route
ip -6 route
ubus call network.interface dump

Na bancada foram observadas, entre outras:

br-lan
anygw
bat0
wlan0-mesh
wlan0-mesh_17
wlan0-mesh_29
wlan1-mesh
wlan1-mesh_17
wlan1-mesh_29

O LuCI também permite visualizar como o LibreMesh organizou essas interfaces.

As interfaces principais incluem bat0, lan, anygw e a interface Babel criada sobre Ethernet:

Na sequência aparecem as interfaces relacionadas à malha de 5 GHz, incluindo a interface principal, Babel e Batman-adv:

Também são criadas as interfaces equivalentes para o outro rádio:

A presença dessas interfaces confirma que a configuração esperada pelo LibreMesh foi criada. Ela, sozinha, não prova que exista um vizinho de malha.

4. Verifique os rádios e as interfaces de acesso e mesh

Pelo terminal:

iw dev
iw phy

No EAP225-Outdoor v3 foram criadas interfaces de acesso e de malha nos dois rádios.

Na reprodução:

2,4 GHz
- AP LibreMesh
- AP específico do nó
- mesh point

5 GHz
- AP LibreMesh
- AP específico do nó
- mesh point

O LuCI mostra essa composição de forma visual:

O iw phy confirmou que os dois PHYs suportam os modos AP e mesh point.

5. Confirme que existe um vizinho 802.11s real

A existência de uma interface mesh point não é suficiente para afirmar que a malha está funcionando. É necessário verificar se existe outro nó efetivamente associado.

Para 5 GHz:

iw dev wlan0-mesh station dump

Para 2,4 GHz:

iw dev wlan1-mesh station dump

Durante o teste de 5 GHz foi observado um peer com:

mesh plink: ESTAB
authorized: yes
authenticated: yes
associated: yes

Também havia contadores de pacotes recebidos e transmitidos.

O LuCI permite observar o mesmo peer entre as estações associadas. Na captura abaixo aparece o equipamento legado LiMe-2020b1.thisnode.info como Ponto de Malha, além de uma estação conectada ao ponto de acesso:

Isso comprova que foi estabelecido um enlace 802.11s real e bidirecional em 5 GHz.

No primeiro teste não foi observado peer correspondente na interface de 2,4 GHz.

O que este resultado permite afirmar

A combinação abaixo funcionou no EAP225-Outdoor v3 testado:

OpenWrt 24.10.7
+
LibreMesh 0b6b5c5
+
wpad-mesh-mbedtls
+
kmod-ath10k-ct
+
ath10k-firmware-qca9888-ct

Esse resultado valida essa composição neste hardware e neste build. Ele não deve ser generalizado automaticamente para outros modelos, rádios ou versões do OpenWrt.

6. Verifique o Babel

Consulte os vizinhos:

ubus call babeld get_neighbours

Consulte as rotas recebidas:

ubus call babeld get_routes

E as rotas exportadas pelo nó:

ubus call babeld get_xroutes

No teste com um equipamento LibreMesh legado, o Babel encontrou o vizinho pela interface de 5 GHz e recebeu rotas IPv4 e IPv6.

Entre elas apareceu uma rota padrão:

0.0.0.0/0

O kernel chegou a instalá-la como:

default via 10.13.32.177 dev wlan0-mesh_17 proto babel onlink

Também foi recebida uma rota para:

10.0.2.0/24

7. Confirme a comunicação IP com o vizinho

O vizinho Babel observado possuía o endereço IPv6 link-local:

fe80::929a:4aff:fe20:20b0

A comunicação foi testada incluindo a interface:

ping6 -c 4 'fe80::929a:4aff:fe20:20b0%wlan0-mesh_17'

Resultado:

4 packets transmitted
4 packets received
0% packet loss

Também é útil consultar a tabela de vizinhança:

ip neigh show dev wlan0-mesh_17

Esse teste confirma comunicação IP através do enlace de malha.

8. Teste o Batman-adv separadamente

O fato de 802.11s e Babel funcionarem não permite concluir automaticamente que o Batman-adv também encontrou um vizinho.

Verifique:

batctl if
batctl n
batctl o

No primeiro teste:

• wlan0-mesh_29 estava ativa;
• wlan1-mesh_29 estava ativa;
• não apareceu vizinho em batctl n;
• não apareceu originator em batctl o.

As capturas do LuCI confirmam que as interfaces Batman foram criadas, mas isso não demonstra por si só a existência de um peer Batman.

Portanto, nesta rodada foi validada a criação das interfaces Batman-adv, mas não o funcionamento do Batman-adv entre dois nós.

9. Registre a interoperabilidade com firmware legado

O primeiro peer encontrado pelo EAP225 não executava a mesma imagem.

Era um equipamento legado:

TP-Link Archer C50 v4
LibreRouterOs - Nupef V4.01 rT 2022
IPv4: 10.13.32.177

Esse cenário foi útil para testar interoperabilidade entre gerações.

Foram observados:

802.11s em 5 GHz            OK
vizinho Babel               OK
troca de rotas Babel        OK
IPv6 link-local             OK
IPv4 para 10.13.32.177      não funcionou
Internet através do peer    não funcionou

O C50 anunciava uma rota padrão e a interface LimeApp do equipamento legado indicava conectividade IPv4 e DNS. Ainda assim, o novo EAP225 não conseguiu alcançar o endereço IPv4 do peer nem encaminhar tráfego para a Internet através dele.

O resultado deve ser registrado como interoperabilidade parcial com firmware legado, e não como falha geral da imagem nova.

10. Teste o uplink Ethernet separadamente

Para separar o comportamento da nova imagem das limitações observadas no equipamento legado, o EAP225 foi conectado diretamente a uma rede Ethernet com acesso à Internet.

A rede de bancada utilizava a faixa:

10.0.2.0/24

Com esse uplink conectado, o EAP225 passou a ter acesso à Internet.

Para repetir o teste pelo terminal:

ip -4 route
ubus call network.interface dump
ping -c 4 8.8.8.8
nslookup libremesh.org

Durante esse teste, o caminho administrativo usado anteriormente para acessar 10.13.235.6 deixou de estar disponível a partir da estação de bancada. Por isso não foi produzida uma captura do LimeApp com os indicadores de Internet ativos.

Esse resultado é útil porque separa duas situações:

Internet através do C50 legado: não funcionou

Internet com uplink Ethernet direto: funcionou

A forma como uma porta Ethernet deve ser configurada para atuar como gateway em uma implantação definitiva depende do equipamento e do perfil de rede. Essa configuração será tratada separadamente.

11. Verifique os componentes adicionais do perfil

Para conferir os pacotes instalados:

opkg list-installed | grep -Ei \
'openwisp|wireguard|pirania|tmate|shared-state'

Na reprodução foram encontrados, entre outros:

kmod-wireguard
wireguard-tools
luci-proto-wireguard
openwisp-config
openwisp-monitoring
pirania
tmate
ubus-tmate
shared-state

A presença de um pacote confirma que ele foi incorporado à imagem, mas não significa que sua operação esteja homologada.

OpenWISP

Os arquivos instalados podem ser conferidos com:

ls -l /etc/init.d/ | grep -Ei 'openwisp|netjson'
opkg files openwisp-config
opkg files openwisp-monitoring

Na bancada foram encontrados:

/etc/init.d/openwisp-config
/etc/init.d/openwisp-monitoring

A configuração e a integração com um servidor OpenWISP ainda não foram testadas.

O mesmo princípio vale para WireGuard, Pirania e tmate.

12. Registre o resultado sem transformar teste parcial em homologação total

Validado nesta rodada

• instalação por sysupgrade no EAP225-Outdoor v3;
• boot após instalação limpa;
• hardware identificado corretamente;
• OpenWrt 24.10.7 em hardware real;
• configuração LibreMesh criada;
• interfaces AP em 2,4 GHz e 5 GHz;
• interfaces mesh point em 2,4 GHz e 5 GHz;
• associação 802.11s real em 5 GHz;
• tráfego bidirecional com peer 802.11s;
• wpad-mesh-mbedtls em hardware;
• ath10k-ct com 802.11s nesta combinação;
• vizinho Babel;
• recepção de rotas Babel;
• comunicação IPv6 link-local com o peer;
• acesso à Internet com uplink Ethernet direto;
• presença dos pacotes adicionais do perfil.

Ainda pendente

• peer 802.11s em 2,4 GHz;
• Batman-adv entre dois equipamentos compatíveis;
• malha homogênea entre dois EAP225 usando a mesma imagem;
• propagação de Internet entre dois nós com a mesma firmware;
• configuração operacional do OpenWISP;
• rede administrativa WireGuard;
• operação do Pirania;
• operação do tmate;
• EAP235-Wall;
• configuração do equipamento destinado a gateway;
• teste prolongado de estabilidade.

Próximo teste recomendado

O próximo teste de maior valor é utilizar dois EAP225-Outdoor v3 com a mesma imagem.

Esse cenário elimina a variável introduzida pela firmware legada:

EAP225 A
   │
   │ 802.11s
   │ Babel
   │ Batman-adv
   │
EAP225 B

Depois disso, os componentes de gerenciamento e os equipamentos usados como gateway podem ser testados em etapas independentes.