Personalizando a imagem LibreMesh para o perfil Nupef

Estado de validação: a compilação desta etapa foi reproduzida com sucesso em OpenWrt 24.10.7, usando o mesmo commit do LibreMesh e do feed de perfis observado na firmware Nupef 0.6.1 publicada. A imagem resultante reproduz o perfil funcional Nupef sobre a base LibreMesh validada, mas não é uma reprodução binária exata da 0.6.1, que foi construída sobre OpenWrt 24.10.8. Instalação no equipamento, boot e comportamento da malha ainda precisam ser homologados em hardware real.

Objetivo

A etapa anterior produziu uma imagem funcionalmente básica:

OpenWrt 24.10.7
+
LibreMesh
+
TP-Link EAP225-Outdoor v3

Agora acrescentamos as funções usadas pelo perfil operacional do Nupef, tomando como referência a firmware 0.6.1 publicada.

O procedimento desta página não consiste em copiar uma lista histórica de pacotes. A ordem usada foi:

imagem LibreMesh base validada
        ↓
firmware Nupef publicada
        ↓
manifest + buildinfo
        ↓
comparação de pacotes
        ↓
classificação por função
        ↓
menuconfig
        ↓
make defconfig
        ↓
build
        ↓
novo manifest
        ↓
comparação com a referência

Isso permite distinguir três coisas diferentes:

• pacotes escolhidos intencionalmente;
• dependências incluídas automaticamente;
• diferenças deliberadas ou decorrentes da versão do OpenWrt.

1. O que pertence ao perfil reproduzido

A referência 0.6.1 confirmou quatro grupos principais de personalização.

Interface local: LuCI em português

A firmware publicada contém LuCI completo, módulos de administração, dashboard e tradução pt-BR.

Entre os componentes confirmados estão:

luci
luci-light
luci-mod-admin-full
luci-mod-dashboard
luci-mod-network
luci-mod-status
luci-mod-system
luci-app-babeld
luci-app-commands
luci-app-firewall
luci-app-openwisp
luci-app-package-manager
luci-proto-batman-adv
luci-proto-ipv6
luci-proto-ppp
luci-proto-wireguard
luci-theme-bootstrap

A configuração de referência também habilita:

CONFIG_LUCI_LANG_pt_BR=y

com os pacotes de tradução correspondentes.

OpenWISP: gerenciamento e monitoramento

A referência contém:

openwisp-config
openwisp-monitoring
netjson-monitoring

OpenWISP fornece a camada central de gerenciamento e monitoramento. O envio de métricas não depende, por princípio, de uma VPN: o equipamento pode iniciar comunicação com o controller.

WireGuard: rede de administração

Na implantação do Nupef, WireGuard compõe a rede privada de administração.

A referência contém:

kmod-wireguard
wireguard-tools
luci-proto-wireguard

A relação conceitual é:

roteador
   │
   ├── OpenWISP → registro, configuração e métricas
   │
   └── WireGuard → conectividade privada de administração

WireGuard não é o sistema de monitoramento. Ele é a tecnologia de VPN usada pelo desenho atual da infraestrutura.

Pirania: portal cativo

A referência contém:

pirania
shared-state-pirania

Pirania implementa o portal cativo e pode ser instalado na firmware sem precisar estar ativo o tempo todo.

tmate: capacidade de suporte remoto

Também estão presentes:

tmate
ubus-tmate

A presença desses pacotes na firmware não significa que o recurso esteja sendo usado no fluxo operacional atual. A documentação deve distinguir composição da imagem de uso corrente de uma função.

O que não entrou

A referência e a evolução das versões permitiram evitar a reintrodução de componentes históricos que não pertencem ao baseline reproduzido:

zerotier
sshtunnel
luci-app-statistics
collectd

ZeroTier apareceu em variante específica para EAP235-Wall. Statistics/collectd foram retirados quando o monitoramento centralizado passou a cumprir essa função.

2. Preserve a imagem LibreMesh base

Antes da personalização:

cd ~/openwrt

Preserve a configuração e o manifest da etapa anterior:

cp .config config-eap225-outdoor-v3-libremesh-base-final

cp \
  bin/targets/ath79/generic/openwrt-ath79-generic-tplink_eap225-outdoor-v3.manifest \
  manifest-eap225-outdoor-v3-libremesh-base.txt

Crie uma área para a validação:

mkdir -p validacao/perfil-nupef/referencia-0.6.1

3. Consulte a firmware Nupef publicada

Para esta reprodução, a referência foi obtida no diretório:

http://compilador.nupef.org.br:5000/firmwares/ath79full/0.6.1/

Baixe primeiro o índice:

cd ~/openwrt/validacao/perfil-nupef/referencia-0.6.1

BASE_URL='http://compilador.nupef.org.br:5000/firmwares/ath79full/0.6.1/'

curl -fsS "$BASE_URL" -o index.html

Liste os arquivos anunciados:

grep -oE 'href="[^"]+"' index.html \
  | cut -d'"' -f2 \
  | sort

Na reprodução, o manifest para o EAP225-Outdoor v3 era:

openwrt24.10.8-libremeshmaster-npf-v0.6.1-mt-ath79-generic-tplink_eap225-outdoor-v3.manifest

Defina o nome e baixe efetivamente o arquivo:

MANIFEST='openwrt24.10.8-libremeshmaster-npf-v0.6.1-mt-ath79-generic-tplink_eap225-outdoor-v3.manifest'

curl -fsS "${BASE_URL}${MANIFEST}" \
  -o nupef-0.6.1-ath79full.manifest

Confirme antes de continuar:

ls -lh nupef-0.6.1-ath79full.manifest
head -n 10 nupef-0.6.1-ath79full.manifest

Erro encontrado durante a reprodução: definir a variável MANIFEST não baixa o arquivo. Tentar executar awk antes do curl acima resulta em No such file or directory. A checagem com ls evita seguir com arquivos de comparação vazios.

Baixe também os metadados:

curl -fsS "${BASE_URL}config.buildinfo" -o config.buildinfo
curl -fsS "${BASE_URL}feeds.buildinfo" -o feeds.buildinfo
curl -fsS "${BASE_URL}version.buildinfo" -o version.buildinfo
curl -fsS "${BASE_URL}sha256sums" -o sha256sums

4. Registre a procedência da referência

A firmware 0.6.1 publicada informa:

version.buildinfo:
r29233-443ec4032a

Os feeds publicados são:

packages   23abaa6f3b0fdfd76b570031107e5718476ff0c8
luci       cac97ed67cfbcad90db49f5f3b1245c2c4cbfae5
routing    946e9ff93be935fce6c03f4c02124833c35c2f56
telephony  92892fa285360b8981f62bf4e0a097e6449e7e33
libremesh  0b6b5c53c6ec1805bd74aaf27237ad2c31a63a7c
profiles   0965de26aaa4703ce300093cc94f07edb6ef12db

O config.buildinfo confirma o mesmo target usado nesta documentação:

CONFIG_TARGET_ath79=y
CONFIG_TARGET_ath79_generic=y
CONFIG_TARGET_ath79_generic_DEVICE_tplink_eap225-outdoor-v3=y

A principal diferença de base é:

referência Nupef 0.6.1 → OpenWrt 24.10.8
reprodução desta página → OpenWrt 24.10.7

Por isso, o resultado desta página é chamado de perfil Nupef em validação, e não de reprodução exata da 0.6.1.

O commit do LibreMesh, entretanto, é exatamente o mesmo usado na nossa árvore:

0b6b5c53c6ec1805bd74aaf27237ad2c31a63a7c

O mesmo ocorre com network-profiles:

0965de26aaa4703ce300093cc94f07edb6ef12db

5. Compare o manifest com a imagem LibreMesh base

Volte para:

cd ~/openwrt

Extraia somente os nomes dos pacotes da base:

awk '{print $1}' \
  manifest-eap225-outdoor-v3-libremesh-base.txt \
  | sort -u \
  > validacao/perfil-nupef/pacotes-base.txt

Faça o mesmo para a referência:

awk '{print $1}' \
  validacao/perfil-nupef/referencia-0.6.1/nupef-0.6.1-ath79full.manifest \
  | sort -u \
  > validacao/perfil-nupef/pacotes-nupef-0.6.1.txt

Pacotes presentes na referência e ausentes na nossa base:

comm -13 \
  validacao/perfil-nupef/pacotes-base.txt \
  validacao/perfil-nupef/pacotes-nupef-0.6.1.txt \
  | tee validacao/perfil-nupef/pacotes-adicionais-0.6.1.txt

A comparação encontrou, entre outros, LuCI, OpenWISP, WireGuard, Pirania, tmate e módulos adicionais de shared-state.

Pacotes presentes na base mas ausentes na referência:

comm -23 \
  validacao/perfil-nupef/pacotes-base.txt \
  validacao/perfil-nupef/pacotes-nupef-0.6.1.txt \
  | tee validacao/perfil-nupef/pacotes-base-a-revisar.txt

Resultado:

lime-hwd-ground-routing
wpad-mesh-mbedtls

A referência, por sua vez, contém wpad-basic-mbedtls.

Essa diferença foi preservada intencionalmente nesta reprodução. A imagem LibreMesh base havia sido compilada com:

CONFIG_PACKAGE_lime-hwd-ground-routing=y
# CONFIG_PACKAGE_wpad-basic-mbedtls is not set
CONFIG_PACKAGE_wpad-mesh-mbedtls=y

Não reverta uma decisão já validada para a base mesh apenas para tornar dois manifests textualmente iguais. O comportamento de rádio ainda deverá ser homologado em equipamento real.

6. Abra o menuconfig

Preserve mais um checkpoint:

cp .config \
  config-eap225-outdoor-v3-libremesh-base-antes-personalizacao

Abra:

make menuconfig

Não altere:

Target System  → Atheros ATH79
Subtarget      → Generic
Target Profile → TP-Link EAP225-Outdoor v3

O perfil de hardware permanece o mesmo usado nas etapas anteriores.

Use / para localizar pacotes pelo nome. Quando um pacote deve ser incorporado à imagem, deixe-o como <*> ou [*], não <M>, salvo quando esta documentação indicar explicitamente o contrário.

7. Selecione LuCI e português brasileiro

Selecione o metapacote:

luci

Depois confirme ou selecione as funções usadas pelo perfil:

luci-app-babeld
luci-app-commands
luci-app-firewall
luci-app-openwisp
luci-app-package-manager
luci-proto-batman-adv
luci-proto-wireguard

Habilite português brasileiro:

CONFIG_LUCI_LANG_pt_BR=y

O metapacote luci resolve automaticamente grande parte da estrutura, incluindo módulos administrativos, rede, status e tema. Na reprodução, a primeira seleção não trouxe o dashboard; a comparação com config.buildinfo da referência mostrou que ainda faltavam:

luci-mod-dashboard
luci-i18n-dashboard-pt-br

Eles foram então selecionados explicitamente.

O metapacote luci incorpora a interface web e resolve vários componentes associados.

O idioma pt-BR foi habilitado para a interface LuCI.

8. Selecione OpenWISP e WireGuard

Selecione:

openwisp-config
openwisp-monitoring
wireguard-tools

Confirme kmod-wireguard. Se ele já tiver sido ativado como dependência, não é necessário forçá-lo novamente.

Também mantenha:

luci-proto-wireguard

Não selecione manualmente todas as dependências criptográficas. O sistema de dependências deve resolver componentes como bibliotecas de criptografia, túneis UDP, curl e netjson-monitoring.

Os agentes de configuração e monitoramento do OpenWISP são incorporados à imagem.

WireGuard compõe a rede de administração usada no perfil reproduzido.

9. Selecione Pirania, shared-state e suporte remoto

Selecione:

pirania
shared-state-pirania
tmate
ubus-tmate

A comparação com o config.buildinfo da referência mostrou que o perfil 0.6.1 também habilita explicitamente:

shared-state-babel_links_info
shared-state-bat_links_info
shared-state-dnsmasq_servers
shared-state-network_nodes
shared-state-node_info
shared-state-ref_state_commons
shared-state-wifi_links_info

Esses componentes foram acrescentados à configuração para reproduzir o conjunto funcional da referência.

Pirania adiciona a capacidade de portal cativo à firmware.

A firmware de referência contém suporte remoto via tmate e ubus-tmate, embora esse recurso não faça parte do fluxo operacional atual.

Os módulos adicionais de shared-state foram selecionados conforme a configuração da referência 0.6.1.

Não selecione nesta trilha:

zerotier
sshtunnel
luci-app-statistics
collectd

10. Preserve as decisões da base mesh

Não altere nesta etapa:

CONFIG_PACKAGE_lime-hwd-ground-routing=y
# CONFIG_PACKAGE_wpad-basic-mbedtls is not set
CONFIG_PACKAGE_wpad-mesh-mbedtls=y
CONFIG_PACKAGE_odhcpd-ipv6only=m

Também mantenha, até a homologação física, os drivers/firmwares ath10k já usados pela imagem base.

A eventual diferença entre variantes -ct e não-CT deve ser tratada como uma questão de teste de rádio/802.11s, e não misturada à adição de LuCI, OpenWISP ou Pirania.

11. Normalize a configuração

Salve .config, saia do menu e execute:

make defconfig

Atenção ao nome: o comando é defconfig. Durante a reprodução foi digitado por engano make deconfig, que falhou porque esse alvo não corresponde ao procedimento desta página.

Nesta árvore, make defconfig exibiu avisos de dependências ausentes em feeds não utilizados e também:

recursive dependency detected!
PACKAGE_profile-freifunk-80211s-sae-bmx7-batadv
...
PACKAGE_wpad-mesh-wolfssl

O profile Freifunk citado não foi selecionado para o EAP225. O comando informou No change to .config, e a configuração do nosso target permaneceu intacta. Registre esse warning; não tente resolvê-lo alterando aleatoriamente pacotes do perfil Nupef.

Confirme os pontos críticos:

grep -E \
'CONFIG_PACKAGE_(lime-hwd-ground-routing|wpad-basic-mbedtls|wpad-mesh-mbedtls|odhcpd-ipv6only)' \
.config

Na reprodução:

CONFIG_PACKAGE_lime-hwd-ground-routing=y
# CONFIG_PACKAGE_wpad-basic-mbedtls is not set
CONFIG_PACKAGE_wpad-mesh-mbedtls=y
CONFIG_PACKAGE_odhcpd-ipv6only=m

Confirme a personalização:

grep -Ei \
'^CONFIG_PACKAGE_.*(openwisp|wireguard|luci|pirania|tmate|shared-state).*=(y|m)$' \
.config \
| sort

E confirme que componentes fora do baseline não entraram:

grep -Ei \
'^CONFIG_PACKAGE_.*(zerotier|collectd|statistics|sshtunnel).*=(y|m)$' \
.config

Na reprodução, esse último comando não retornou nenhuma linha.

12. Compare a configuração funcional com a referência

Crie uma lista a partir do config.buildinfo Nupef:

grep -Ei \
'^CONFIG_PACKAGE_.*(openwisp|wireguard|luci|pirania|tmate|shared-state).*=(y|m)$' \
validacao/perfil-nupef/referencia-0.6.1/config.buildinfo \
| sort \
> /tmp/config-nupef-referencia.txt

Faça o mesmo com a nossa configuração:

grep -Ei \
'^CONFIG_PACKAGE_.*(openwisp|wireguard|luci|pirania|tmate|shared-state).*=(y|m)$' \
.config \
| sort \
> /tmp/config-nossa-personalizacao.txt

Compare:

diff -u \
  /tmp/config-nupef-referencia.txt \
  /tmp/config-nossa-personalizacao.txt

Na reprodução, após selecionar o metapacote LuCI, os módulos adicionais de shared-state e finalmente luci-mod-dashboard + sua tradução pt-BR, o diff desse subconjunto funcional ficou sem diferenças.

Isso não torna as duas firmwares idênticas: continuamos usando OpenWrt 24.10.7 e preservando as diferenças de wpad/ground-routing.

13. Salve um checkpoint antes do build

cp .config \
  config-eap225-outdoor-v3-libremesh-perfil-nupef-pre-build

Registre a procedência:

{
  echo "=== OpenWrt ==="
  git describe --tags --always
  git rev-parse HEAD

  echo
  echo "=== LibreMesh ==="
  git -C feeds/libremesh rev-parse HEAD

  echo
  echo "=== Profiles ==="
  git -C feeds/profiles rev-parse HEAD

  echo
  echo "=== Data UTC ==="
  date -u
} | tee validacao/perfil-nupef/proveniencia-pre-build.txt

Nesta reprodução:

OpenWrt
v24.10.7
b40dfac0a31695596f7c1f5f1519302ca8237f6e

LibreMesh
0b6b5c53c6ec1805bd74aaf27237ad2c31a63a7c

Profiles
0965de26aaa4703ce300093cc94f07edb6ef12db

14. Baixe novas dependências

time make download 2>&1 \
  | tee download-eap225-outdoor-v3-perfil-nupef.log

Se o comando falhar, não inicie a compilação. Inspecione o log primeiro.

15. Compile a imagem personalizada

Nesta reprodução foi usado:

time make V=s -j5 2>&1 \
  | tee build-eap225-outdoor-v3-perfil-nupef.log

Não foi executado make clean: a árvore já continha os artefatos da compilação LibreMesh base.

Por isso, o tempo abaixo representa build incremental da personalização, não uma compilação limpa:

real    6m15.813s
user   11m32.281s
sys     4m12.589s

O comando terminou com código:

0

16. Artefatos produzidos

O diretório:

ls -lh bin/targets/ath79/generic/

continha:

9.2M openwrt-ath79-generic-tplink_eap225-outdoor-v3-initramfs-kernel.bin
9.9M openwrt-ath79-generic-tplink_eap225-outdoor-v3-squashfs-factory.bin
9.9M openwrt-ath79-generic-tplink_eap225-outdoor-v3-squashfs-sysupgrade.bin
8.1K openwrt-ath79-generic-tplink_eap225-outdoor-v3.manifest

A imagem ficou maior que a LibreMesh base, como esperado após adicionar interface web, gerenciamento, monitoramento, VPN, portal cativo e suporte remoto.

17. Valide os hashes

cd ~/openwrt/bin/targets/ath79/generic
sha256sum -c sha256sums

Na reprodução, todos os arquivos esperados retornaram OK:

config.buildinfo: OK
feeds.buildinfo: OK
openwrt-ath79-generic-tplink_eap225-outdoor-v3-initramfs-kernel.bin: OK
openwrt-ath79-generic-tplink_eap225-outdoor-v3-squashfs-factory.bin: OK
openwrt-ath79-generic-tplink_eap225-outdoor-v3-squashfs-sysupgrade.bin: OK
openwrt-ath79-generic-tplink_eap225-outdoor-v3.manifest: OK
profiles.json: OK
version.buildinfo: OK

Isso valida a geração e a integridade dos artefatos no ambiente de compilação.

18. Preserve o resultado

cd ~/openwrt

cp .config \
  config-eap225-outdoor-v3-libremesh-perfil-nupef-final

cp \
  bin/targets/ath79/generic/openwrt-ath79-generic-tplink_eap225-outdoor-v3.manifest \
  validacao/perfil-nupef/manifest-perfil-nupef-validacao.txt

Também é recomendável preservar os metadados produzidos pelo build:

cp bin/targets/ath79/generic/config.buildinfo \
  validacao/perfil-nupef/config.buildinfo-build-validacao

cp bin/targets/ath79/generic/feeds.buildinfo \
  validacao/perfil-nupef/feeds.buildinfo-build-validacao

cp bin/targets/ath79/generic/version.buildinfo \
  validacao/perfil-nupef/version.buildinfo-build-validacao

19. Compare o manifest final com a 0.6.1

Extraia os pacotes do build:

awk '{print $1}' \
  validacao/perfil-nupef/manifest-perfil-nupef-validacao.txt \
  | sort -u \
  > validacao/perfil-nupef/pacotes-build-validacao.txt

Pacotes presentes na 0.6.1 mas ausentes no nosso build:

comm -23 \
  validacao/perfil-nupef/pacotes-nupef-0.6.1.txt \
  validacao/perfil-nupef/pacotes-build-validacao.txt \
  | tee validacao/perfil-nupef/faltam-em-relacao-0.6.1.txt

Resultado:

kmod-crypto-kpp
lime-docs
wpad-basic-mbedtls

Pacotes presentes no nosso build mas ausentes na referência:

comm -13 \
  validacao/perfil-nupef/pacotes-nupef-0.6.1.txt \
  validacao/perfil-nupef/pacotes-build-validacao.txt \
  | tee validacao/perfil-nupef/extras-em-relacao-0.6.1.txt

Resultado:

lime-hwd-ground-routing
wpad-mesh-mbedtls

Como interpretar as diferenças

wpad-basic-mbedtls versus wpad-mesh-mbedtls é uma diferença deliberadamente preservada. A base LibreMesh desta documentação já havia exigido a retirada de wpad-basic-mbedtls para evitar conflito de empacotamento com wpad-mesh-mbedtls.

lime-hwd-ground-routing também foi mantido na base reproduzida, mesmo ausente do manifest 0.6.1 publicado.

lime-docs está na referência enquanto a base desta documentação usa lime-docs-minimal; essa diferença está relacionada à documentação embarcada, não foi tratada como requisito para a funcionalidade operacional reproduzida.

kmod-crypto-kpp não foi selecionado manualmente apenas para aproximar os manifests. A composição de módulos de kernel pode variar entre OpenWrt 24.10.7 e 24.10.8, e o build 24.10.7 gerou kmod-wireguard com sucesso. A função deve ser validada no equipamento, em vez de forçar uma dependência apenas por comparação textual.

20. Recursos observados

Antes e depois desta compilação, o filesystem de 40 GB permanecia em:

16 GB usados
23 GB disponíveis
41% de utilização

Depois da personalização:

/home/compila/openwrt/dl          885 MB
/home/compila/openwrt/build_dir   11 GB
/home/compila/openwrt/staging_dir 741 MB
/home/compila/openwrt/bin          40 MB

O diretório completo ~/openwrt ocupava aproximadamente:

13 GB

A memória observada após o build era:

7.6 GiB total
6.8 GiB disponível
sem swap

Esses valores são medições após a execução, não representam o pico de RAM durante o build e não devem ser publicados como requisitos mínimos universais.

21. O que esta etapa valida

A reprodução demonstrou que é possível, nesta árvore:

• partir da imagem LibreMesh base já validada;
• usar o manifest e os buildinfo da firmware Nupef como referência;
• acrescentar LuCI/pt-BR;
• acrescentar OpenWISP e WireGuard;
• acrescentar Pirania e os componentes shared-state observados;
• manter tmate/ubus-tmate presentes na composição;
• evitar ZeroTier, Statistics/collectd e sshtunnel neste baseline;
• compilar com sucesso;
• gerar factory, sysupgrade e initramfs;
• validar os hashes;
• comparar o manifest final com o publicado.

Ela não valida ainda:

• gravação da imagem no TP-Link EAP225-Outdoor v3;
• boot do equipamento;
• acesso à interface LuCI;
• formação real da malha 802.11s;
• funcionamento do rádio 5 GHz com a composição ath10k usada;
• registro real no OpenWISP;
• estabelecimento do túnel WireGuard;
• funcionamento do Pirania;
• funcionamento do tmate;
• comportamento em campo.

Esses itens pertencem às próximas etapas de instalação e homologação.

22. O que fica fora deste tutorial

Não misture nesta página:

• provisionamento do servidor OpenWISP;
• playbooks do controller;
• servidor ou automação WireGuard;
• organizações, tokens e secrets;
• credenciais;
• lime-community;
• lime-node;
• arquivos injetados em files/;
• rc.local;
• configurações específicas de owr, wg0 ou controllers;
• ajustes do EAP235-Wall;
• instalação física e homologação de campo.

Esses assuntos dependem de infraestrutura, configuração operacional ou hardware e devem ser tratados em páginas próprias.