Discuta este tópico no fórum

Se este conteúdo te ajudou, deixe um presente!

segunda-feira, 4 de novembro de 2024

OpenWrt: múltiplos APs e fast roaming (e o tal de mesh)

Mais um artigo da série sobre o OpenWrt.

A frase "a internet está horrível hoje" certamente já foi dita por todos em algum momento. Com muita frequência, isso é devido a perda de pacotes. Qualquer perda de pacotes acima de 1% torna a conexão inviável. E qual o problema de perder uns pacotinhos se ainda tem os outros 99%?

De forma bem simplificada, o protocolo de transmissão de dados mais usado, o TCP, oportunisticamente vai aumentando rapidamente a velocidade que os pacotes são enviados até que esgotamos a capacidade de transmissão de dados em algum ponto entre a origem e o destino. Nesta situação, ocorre a perda de pacotes. O protocolo, então, volta a uma velocidade baixa e novamente vai aumentando a velocidade, repetindo o ciclo. Perder pacotes nesta situação é o esperado pois serve como um sinal de que o canal está cheio. O problema ocorre quando esta perda de pacotes é devido a um problema no canal, que faz o pacote se perder muito antes de você usar a capacidade disponível. O protocolo se confunde com a perda, achando que o canal está congestionado, e reinicia o processo de subida da velocidade de transmissão lá de baixo. Como a velocidade nunca sobe muito, você terá a sensação da "internet horrível".

Quando eu era pequeninho lá em Barbacena (link se você não tem idade para ter entendido a referência), o grande vilão que gerava perda de pacotes era o ruído do canal analógico da conexão discada. Porém, hoje com conexões digitais, fibra e planos de centenas de megabits por segundo, é mais difícil o problema ser o canal com a operadora (se for o seu caso, saiba que isso não é normal). O mais comum mesmo é perder pacotes dentro da rede local, ou melhor, perder pacotes na conexão da WiFi. Não importa muito o motivo da redução na qualidade do sinal da Wifi (espelho, estrutura de ferro, canos de água), mas a solução varia entre colocar um AP com mais potência e melhor antena ou multiplicar a quantidade de APs.

Nota: vou usar AP (access-point) aqui como o equipamento que oferece uma rede Wifi. Se ele faz o papel de roteador ou não, isso é uma questão da camada de rede e não é importante para o tema deste texto. Roteador wifi é apenas um roteador com função de AP (e normalmente switch também).

O que eu mais vejo nas varreduras de Wifi são múltiplos APs com nomes do tipo: "Fulano Sala", "Fulano Quarto" ou "Repetidor cozinha", ou ainda "Rede 5Ghz" e "Rede 2.5Ghz". Todavia, desde os primórdios da Wifi, muito antes da era dos smartphones, a Wifi foi desenvolvida para tratar diversas redes com o mesmo nome. Então, a solução de quem desenvolveu o protocolo era colocar todas as redes com o mesmíssimo nome (e, obviamente, configuração da autenticação) e deixar o cliente da Wifi decidir qual é a melhor opção.

Então, se é uma maravilha, por que ninguém faz assim? Bem, o problema de usar o mesmo nome tem relação com o "deixar o cliente da Wifi decidir". Tivemos casos de clientes que não lidavam bem com isso pois era um cenário não muito bem testado pelos fabricantes mais rústicos. Porém, faz tempo que todos os clientes usuais (geralmente um android ou IOS) trabalham super bem com redes homônimas. Outro problema é que os clientes são apegados a rede que eles conectaram. Até perder o sinal e o cliente buscar uma nova rede, ele não trocava de AP. Então, se o sinal estava fraco mas operacional, o seu celular ia ficar conectado no AP inicial, mesmo se você estivesse do lado de um outro roteador. A solução de contorno nesta situação era desligar e religar a wifi para o cliente escolher novamente o melhor AP (alguns fabricantes fizeram ajustes neste comportamento para serem mais proativos). Não é muito diferente de ter duas redes com nomes diferentes configuradas, com a desvantagem de você não saber explicitamente qual rede está conectado. Neste caso, até faz sentido a proliferação das redes de nomes duplos pois, ao menos, você saberia onde está conectado e economiza um clique na troca manual. 

Então é isso? Continuo com minha rede "Repetidor Cozinha"? Não, podemos fazer muito melhor do que isso. Temos uma evolução do protocolo (já antiga, de 2008) chamada 802.11r (fast roaming). Nestas redes de mesmo nome, o cliente é orientado a proativamente verificar se um outro AP de mesmo nome mas com sinal melhor está funcional. O cliente faz uma autenticação acelerada e, estando tudo OK, muda a rede quase que de forma imperceptível. Isso vale tanto para trocar de AP como de 2.5 Ghz para 5 Ghz. Simplesmente funciona.

Comercialmente, o 802.11r geralmente aparece em produtos vendidos com a característica comercial "Mesh". Porém, apesar de geralmente estar junto, mesh (ou malha) refere-se ao protocolo 802.11s (ou algo similar proprietário do fabricante) usando na comunicação entre APs e não entre o AP e o cliente. No caso de redes em malha, o AP pode falar com o outro por um canal sem fio, podendo fazer isso de forma direta ou saltando por outros APs membros da rede. Se ligar um cabo entre os dois APs, o recurso "mesh" perde o sentido.

Mas um repetidor Wifi não faz exatamente isso? Sim, especialmente se forem apenas 2 APs. Se os APs ficarem estáticos e sempre ligados, não faria diferença em configurá-los como repetidores usando WDS ou como rede mesh. Redes Mesh é questão de software e seu roteador velho de guerra de 10 anos atrás poderia sim fazer uma rede Mesh se a firmware permitisse (ex: se suportar OpenWrt e ter uma driver compatível). Mas como já falei, Mesh entre 2 APs não é melhor do que colocar um deles como um repetidor WDS e configurar nos dois o mesmo nome de rede. E, para melhor experiência do usuário, ative o 802.11r para que a transição entre APs seja imperceptível.

"Mas eu troquei para roteadores Mesh e minha rede melhorou muito!" Claro que trocar seu roteador velho e seu repetidor de R$ 49,90 por dois roteadores mesh de R$ 700,00, a qualidade da rede deve melhorar. Não pelo uso de mesh em si, mas por serem equipamentos melhores e mais novos.

Agora um resumão:
  • Vou um novo AP, vale a pena comprar um do tipo mesh? O mesh não faz sentido sozinho. Se não for comprar mais de um, não compre pelo "mesh", mas o HW deles tende a ser bom;
  • Vou comprar dois novos APs, vale a pena comprar do tipo mesh? O mesh ainda não faz sentido para apenas 2 APs. A função de repetidor WDS com fast roaming seria equivalente, mas o HW deste tipo de roteador "mesh" tende a ser bom. Se for conectá-los por cabo, o mesh é ainda menos importante. O importante é usar o mesmo nome e ter o 802.11r. Contudo, a linha mesh pode facilitar a configuração igual nos dois APs;
  • Vou comprar diversos APs para cobrir uma região grande, vale a pena comprar do tipo mesh? Bem, se for um galpão ou coisa do tipo, faz sentido comprar uma linha empresarial. Os APs empresariais normalmente possuem conectividade mesh e um gerenciamento centralizado melhor. Não acho que a linha residencial deva ser usada nestes caso;
  • Tenho um AP repetidor conectado no outro por WDS. Devo usar o mesmo nome de rede? Provavelmente sim, principalmente se puder ativar o 802.11r. Se já usa OpenWrt  recente nos dois, a resposta é sim pois suporte para 802.11r é software e não depende de driver. Você também pode criar redes ocultas adicionais nos mesmos APs quando quiser forçar um teste em um deles. Eu as configuro nos clientes, mas sem conexão automática.
  • Tenho um AP repetidor WDS antigo que não suporta 802.11r, devo usar o mesmo nome de rede? Pode usar, mas você pode sentir falta de saber qual rede está conectado. No Android, tem uma opção de desenvolvedor para mostrar o endereço MAC (BSSID) do AP conectado que pode te ajudar. Mas, com conexões de internet acima de 100 Mbps, tira o escorpião do bolso e compra algo melhor. O diferencial para o usuário é oferecer o 802.11r.
E você vai saber que a Wifi está boa quando não precisar pensar nela, mesmo naquele cômodo distante da casa.

Em um próximo texto eu mostro alguns detalhes da configuração do 802.11r residencial no OpenWrt. Porém, é tão simples que talvez nem precise de uma postagem específica.

Até a próxima.

domingo, 11 de agosto de 2024

OpenWrt: switches D-Link DGS 1210-28 F3 e DGS 1210-52 F3 - instalando o OpenWrt

Mais um artigo da série sobre o OpenWrt.

No artigo anterior, mostrei os problemas que eu enfrentei com a firmware original dos switches D-Link DGS 1210-28 F3 e DGS 1210-52 F3. Neste artigo vamos às limitações do OpenWrt e o processo de instalação.

O OpenWrt 23.05 está com o suporte bem estável para estes modelos e outros da mesma linha. Não recomendo as versões anteriores pois, além de não ter mais suporte, ela tinha alguns recursos faltando e vinha com uma configuração inicial que acabava exigindo o uso da serial (interna). Na versão atual, 23.05, temos uma configuração inicial mais clássica, com acesso inicial pela 192.168.1.1. Ainda estou trabalhando para fornecer uma firmware que possa ser gravada pela interface WEB (ops, ela reinicia, lembra do último artigo?) CLI do fabricante.

Com o OpenWrt, o switch funciona muito bem, fazendo o trabalho de encaminhamento de pacotes com competência. O desempenho é o mesmo pois este trabalho é do hardware. A interface de gerência é a que se espera do OpenWrt, com opção de uso do SSH ou pela Web. E, incrivelmente, ela não se perde e reinicia sozinha depois de um tempo! Você pode, até o limite da flash, instalar pacotes extras ou mesmo subverter o switch transformando ele em um roteador ou outra coisa qualquer. O OpenWrt é uma distribução Linux e ela não impõe como você vai usar o seu equipamento, desde que o hardware dele dê conta. Só lembre-se que ele tem uma CPU fraca e não vai conseguir, por exemplo, fazer NAT muito mais do que uns 200Mbps. Não testei o LACP (link aggregation), mas o STP (para evitar loops) parece ter algum problema e não impediu uma tempestade de broadcast. As portas combo (SFP+ethernet) também podem não estar funcionando para alguns modelos.

O switch possui "partições" na flash para armazenar o kernel e o sistema raiz (rootfs). Bem, no caos, 2 de cada pois temos suporte para 2 firmwares. Além disso temos outras partições com informações do sistema (como o endereço MAC), gerenciar de boot, configuração do gerenciador de boot e uma partição de dados onde a firmware original grava seus dados. Algo assim:

devsizeerasesizename
mtd00008000000010000BOOT
mtd10004000000010000BDINFO
mtd20004000000010000BDINFO2
mtd30018000000010000KERNEL1
mtd400c0000000010000ROOTFS1
mtd50018000000010000KERNEL2
mtd60004000000010000SYSINFO
mtd700c0000000010000ROOTFS2
mtd8003c000000010000JFFS2
O problema é que o kerrnel do OpenWrt é maior do que a partição de kernel. Mas temos como dar uma contornada nesta limitação. As "partições" na flash são só uma declaração no sistema operacional de intervalos da flash, com os endereços de início e tamanho. O gerenciador de boot, por exemplo, não considera estes limites para iniciar o sistema e apenas precisa do endereço do começo do kernel para carregá-lo. Então, a solução para encaixar o kernel maior do OpenWrt foi colocar o kernel até onde couber em KERNEL1 e continuar o resto (kernel, rootfs e a overlay) na ROOTFS1.

Para a instalação inicial do OpenWrt na firmware original da D-Link, foi utilizado este subterfúgio de dividir o kernel no meio (nossa vantagem é que eles não validam o conteúdo). Depois de instalado, dentro do OpenWrt, isso é tratado de forma transparente pois temos uma declaração de partição que já aglutina as duas áreas. Só tem um porém: no espaço reservado da segunda imagem, temos uma partição SYSINFO entre KERNEL2 e ROOTFS2. Então, esta estratégia só funciona se o OpenWrt for instalado na posição da imagem 1.

Como podemos fazer ele gravar na posição da imagem 1? A firmware original grava sempre na outra da que está em uso. Então, primeiro pela CLI (telnet ou SSH) ou pela web da firmware original, mude a imagem padrão para image2 e reinicie o switch. Só para lembrar, se o switch estiver com a configuração de fábrica, o endereço IP inicial é 10.90.90.90 e somente o telnet estará habilitado. Pela CLI ficaria assim (depois de conectar pelo telnet):

DGS-1210-20> config firmware image_id 2 boot_up
DGS-1210-20> save
DGS-1210-20> reboot
(acho que o save não precisa, mas eu não testei sem)

Depois que subir novamente o sistema original, você pode enviar a nova firmware OpenWrt para o switch. Infelizmente, você precisará utilizar o modo CLI (telnet ou SSH) pois a interface web reinicia se você enviar qualquer nova firmware (mesmo a original!). Você precisará também de um servidor TFTP. Tem várias opções no mercado. Considerando que o IP do servidor TFTP é 1.2.3.4, você pode usar:

DGS-1210-20> download firmware_fromTFTP 1.2.3.4 openwrt-realtek-rtl838x-d-link_dgs-1210-28-squashfs-factory_image1.bin image_id 1
DGS-1210-20> reboot 

Ao reiniciar, você deve estar com o OpenWrt rodando. O endereço IP inicial é o mesmo de qualquer OpenWrt: 192.168.1.1 e procure usar sempre a primeira porta para fazer a configuração inicial pois, para todo equipamento que usa DSA, só ela irá funcionar caso você inicie o modo failsafe do OpenWrt.

E se eu quiser voltar para a firmware original? Tem como? Sim, e de uma forma até fácil. Lembra que não tocamos na firmware da posição image 2? Bem, podemos selecioná-la para iniciar no próximo boot:

root@OpenWrt:/# fw_setenv bootcmd run addargs\; bootm 0xb4e80000
root@OpenWrt:/# fw_setenv image /dev/mtdblock7
root@OpenWrt:/# reboot
Depois que a firmware original iniciar, o sistema ainda vai estar achando que está usando a image 1 pois, aparentemente, ele guarda isso também dentro da configuração. Para resolver esta inconsistência, basta forçar a reconfiguração novamente:

DGS-1210-20> config firmware image_id 2 boot_up

E se quiser voltar novamente ao OpenWrt:

DGS-1210-20> config firmware image_id 1 boot_up
DGS-1210-20> save
DGS-1210-20> reboot

Estes switches e diversos roteadores do OpenWrt estão migrando para drivers de switch DSA. Isso muda algumas coisa na forma de gerenciar as portas. Talvez eu escreva algo sobre isso.

Até a próxima!

domingo, 4 de agosto de 2024

OpenWrt: switches D-Link DGS 1210-28 F3 e DGS 1210-52 F3 - problemas com a firmware original

Mais um artigo da série sobre o OpenWrt.

Sim, faz tempo que não tem postagens. Vou tentar postar sobre alguns assuntos que trabalhei nos últimos meses/ano mas ainda não escrevi sobre. Porém, muito desses assuntos são mais divertidos e curiosidades. Todavia, nas últimas semanas entrei em uma nova seara: switches. Não exatamente switches, com os quais trabalho faz tempo, mas switches com OpenWrt. Esse sim é algo que pode ser útil para outras pessoas da mesma forma que resolveu um monte de problemas que eu estava tendo.

O mártir, digo, switch alvo são na verdade 2: D-Link DGS 1210-28 e o D-Link DGS 1210-52, ambos versão de hardware F3. Perto de um roteador, um switch é um equipamento quase sem graça: configura algumas VLANs, algumas portas, o básico de monitoramento e autoria e esquece. No máximo, eventualmente uma ou outra porta é ajustada (quando a designação de VLAN não for dinâmica) e, com sorte, uma ou outra atualização de firmware para corrigir problemas de segurança. Porém, esta linha de switches se superou frente a qualquer coisa que eu tenha visto. Ele se anuncia como um switch gerenciável, mas ele é mais um switch adolescente: depois de um tempo ele para de te escutar e se torna autônomo (também conhecido como não responde mais na interface de gerenciamento). Vamos primeiro ao "por que não a firmware da D-Link" ou os problemas encontrados.

O datasheet do produto diz que ele tem IPv6 e que tem suporte a SLAAC, mais precisamente "RFC2462, RFC4862 IPv6 Stateless Address Auto-configuration (SLAAC)". Porém, não tem uma forma de "ativar o SLAAC". Ele usa IPv6 fixo ou pede pelo DHCP. Eventualmente aparece o endereço SLAAC funcionando mas não sei qual alinhamento de planetas precisa acontecer. E se reiniciar, não vai funcionar novamente.

OK, esquece o SLAAC, vamos de DHCPv6. Tudo sai funcionando e você acha que contornou o problema até que depois de alguns minutos... o switch não responde mais na rede IPv6. Parece que ele esquece o roteador padrão da rede. E isso ocorre independentemente se este roteador está usando um endereços e rotas estáticos ou DHCPv6 (só lembrando que o DHCPv6 não informa a rota padrão, que ainda vem do Router Advertisement). Também ocorre quando você configura o DHCPv4 depois que o IPv6 estava funcionando.

Bem, nos resta o IPv4. Para mim, é uma opção pior pois a rede IPv4 onde estará o switch está atrás de uma NAT. Por IPv6 teria um endereço acessível. Mas tudo bem, fazemos o SSH ao roteador de depois SSH ao switch. Aí vem a próxima surpresinha: a interface SSH é algo que eles chamam de "Compact CLI". Mas que diabos é isso? Traduzindo, é uma interface de gerenciamento que não gerencia. Só permite regravar e chavear a firmware e a configuração em uso (tem suporte para armazenar 2 configurações e duas flashes), definir a senha do admin (o único usuário), configurar o IPv4 e.... não, é só isso mesmo. E o pior de tudo que é uma trava em software. Se olhar com carinho a firmware original, vai ver todos os comandos de uma interface de gerenciamento completa, que é desativada quando você a acessa.

"Mas eu provavelmente farei a geração de configuração em lote e só preciso enviar ela..." só que não. A configuração não é textual: é um formato binário. Para modificar a configuração, você precisaria ter um switch que funciona, subir a configuração remota, fazer a modificação, salvar, baixar a configuração binária e enviar ao switch remoto comandando um download TFTP na "Compact CLI". Sem IPv6 nem um CLI útil, nos resta a interface WEB pelo IPv4, acessada fazendo túneis pelo roteador.

E funciona? No geral sim... por alguns dias. Até que eventualmente o IPv4 também escuta algo que não gosta, fica de mal e não quer mais falar com você. Isso parece ocorrer quando eu reinicio o roteador da rede, mas não estou certo ainda. Só sei que acontece. Acho que a interface de gerenciamento se perde e trava se uma tentativa de solicitação de DHCPv4 falhar depois que ela já estava funcionando. Só volta se reiniciar e, em geral, neste e em outros problemas já listados, só se fizer um reinício "à frio" (desligando a energia). Agora coloque uns 600 quilômetros entre você e o switch e terá uma ideia do tamanho do problema.

E esses são só os problemas mais sérios do gerenciamento da firmware original. Temos vários outros:
  1. NTP não funciona para endereços IPv4 terminados com .0 (sim, tão válidos como qualquer outro se a máscara for maior que /24), não funciona para IPv6 (e olha que ele te obriga a informar 3 servidores!);
  2. Todo upload enviado pela web reinicia o roteador, seja chave SSH, firmware e provavelmente configuração (os dois últimos ainda dá para enviar pela "Compact CLI");
  3. O campo da tabela do endereço IPv6 é pequeno: corta o final do endereço (demorei para perceber);
  4. Tem uma figura no fundo da árvore de itens (menu lateral) de uma pilha de swiches que acaba ficando em baixo dos itens se o item do menu aberto tem muitas entradas. Atrapalha bastante a leitura;
(Deve ter mais, mas não investi tempo nisso. Esses foram os que eu tropecei e ainda lembro.)

Mas o equipamento não é todo ruim. Pelo preço, ele tem algo de muito bom: ele tem o recurso de ter 2 firmwares e 2 configurações. Se ele estiver remoto e der algum problema na configuração ou em uma atualização, ele vai reiniciar e voltar a configuração que funciona, certo? Não. Ele diz tem o recurso mas não implementaram a lógica o gerenciador de boot (u-boot) que se esperaria para usar duas imagens. Se uma firmware travar e reiniciar, ele NUNCA vai chavear para a outra. NUNCA. E não tem nem mesmo como dar uma dica. Não tem "apertar RESET", "dar três pulinhos", "tomar água de cabeça para baixo", nada vai fazer ele chavear a outra imagem ou configuração. Aqui vem a melhor parte: você só consegue chavear para a outra firmware de uma firmware que está funcionando. E se a que foi escolhida para iniciar falhar, é tão ruim como se ela fosse a única, anulando quase qualquer vantagem de ter duas. 

Mas espere, na documentação tem um procedimento para gravação emergencial de firmware. Segura o RESET por 12 segundos e envia pelo software proprietário da D-Link (mas precisa ser uma versão antiga dele). Sim, funciona mas.... pegadinha do Malandro! Novamente só se iniciado de uma firmware D-Link que está funcionando. "Luiz, acho que você escreveu algo errado. Isso não faz sentido. Para que ter uma gravação emergencial se ela só funciona a partir de uma firmware que está funcionando?". Primeiro eu achei que estava fazendo algo de errado. Entrei em contato com a D-Link e pedi orientações. A solução? RMA (para quem não conhece, enviar para a assistência). Tudo bem, posso enviar, mas se voltar a acontecer? Tem como arrumar o problema? E se acontecer em um equipamento distante? D-Link: "RMA". E se for em vários? D-Link: "RMA". O botão simplesmente não funciona a partir de um boot frio, nem para zerar a configuração. A única forma de forçar o modo de gravação emergencial no boot frio é corrompendo ambas as firmwares. Até chegar nisso, você já tentou iniciar uma firmware com problema e já transformou seu switch em um peso de papel.

A impressão que tenho é que o equipamento foi montado para atender "requisitos" no papel. Ele tem tudo que se espera mas quase tudo não faz direito. Parece que o plano de testes dele foi bem "simples", próximo da linha do "go horse". Funcionou em um caso? Check! (se é que ao menos algo simples assim tenha ocorrido).

E sim, a D-Link está ciente dos problemas. Mas não tenho esperança que algum dos problemas seja resolvido.

Fora os problemas nas funcionalidades, temos outros requisitos "não funcionais" problemáticos. Não é algo específico desde equipamento mas as firmwares de muitos equipamentos são compostas por uma SDK fornecida pelo fabricante do chip (SoC), incorporada com uma interface de gerenciamento padronizada da empresa da marca. E isso nem sempre é feito pela "marca", mas por uma terceira figura que faz a junção dos dois lados da solução. Pode ser por isso que esses produtos parecem ser um "cachorro sem dono." As SDK dos fabricantes quase sempre ficam congeladas no tempo. No caso deste switch, é um kernel 2.6.19 (de nov/2006), com um busybox e uma uclibc da época. Imagina a quantidade de vulnerabilidades que ocorreram desde então que muito provavelmente não foram aplicadas nesses ambientes. O uso de bibliotecas sem suporte e o compartilhamento de SDK entre fabricantes é o que provoca problemas que estranhamente afetam diversas linhas de fabricantes distintos, como esse problema do uclibc que, diferentemente do que foi divulgado em diversas matérias, NÃO AFETA VERSÕES SUPORTADAS DO OPENWRT, nem mesmo a já abandonada 19.07 pois não usam mais o uclibc e sim o musl.

E o OpenWrt está livre de todos os problemas? Não. Ao menos não todos estes listados aqui. No próximo artigo vamos à instalação do OpenWrt e também suas limitações.

Até a próxima.

segunda-feira, 6 de setembro de 2021

OpenWrt: atualizando para a versão 21.02

Mais um artigo da série sobre o OpenWrt.

Enfim temos uma nova versão do OpenWrt. Mãos a obra para atualizar!

Parece repeteco do artigo de upgrade do 19.07, mas é assim mesmo. O 19.07 seria o último com suporte para o alvo ar71xx. Agora, a migração para o ath76 é obrigatório. No 19.07 os modelos com pouca RAM e Flash poderiam apresentar problemas, mas ainda eram "suportados". Agora com o 21.02 eles não terão mais uma imagem pronta. Quem quiser e souber como fazer, deve usar o Image Builder e fazer sua própria firmware.

Para começar, o upgrade só é suportado vindo da 19.07.x. Então, se estiver saltando da 18.06.x, dê uma paradinha na 19.07 antes de prosseguir.

96,72% dos problemas com instalação/atualização com OpenWrt que ajudo é em relação a escolha incorreta da imagem da firmware. O OpenWrt tem uma página que simplifica a busca pela firmware correta, mas nada é à prova de pessoas criativas. Pegue o arquivo no download da última versão estável e nunca em um endereço qualquer, mesmo que seja em um artigo na wiki do OpenWrt (lembre-se como funciona uma wiki). Normalmente a wiki referência a versão em desenvolvimento, que não é a que você quer. As versões dentro de "(stables) releases", exceto as com o rc (release candidate) são estáveis. Pegue preferencialmente a mais nova (com número maior). Evite qualquer firmware que tenha no caminho palavras como "trunk", "snapshot" ou "rc1", "rc2"... exceto se estiver testando algo. As versões estáveis também mencionam a respectiva versão do OpenWrt no nome do arquivo como em "openwrt-21.02.0-ath79-generic-tplink_archer-c7-v4-squashfs-sysupgrade.bin", ao contrário da versão instável/em desenvolvimento "openwrt-ath79-generic-tplink_archer-c7-v4-squashfs-sysupgrade.bin".

A nomenclatura da versão é adota o formato: ano.mês.correção. O ano/mês se referem ao momento que foi criado um ramo nos fontes para o lançamento da nova versão e não propriamente quando o lançamento final ocorreu. Já o último número é apenas um sequencial de correção. Então, para quem usa uma versão 21.02.x, a próxima 21.02.x+1 deverá conter apenas bugs resolvidos (em especial, os de segurança) e deve ser considerada como recomendada. Estas versões de correção são lançadas com certa frequência. É bom acompanhar (e atualizar).

Na página principal, temos um atalho para cada versão lançada com o nome "Download a firmware image for your device (firmware selector)". Essa é a versão amigável de escolha da firmware buscando por texto. Observe sempre a versão do hardware! Para upgrades entre versões do OpenWrt, sempre use o "sysupgrade" e "factory "para instalações da firmware original de fábrica.

Finalmente, é muito importante ler a wiki do seu roteador independente se ele já funcionava na versão anterior! São poucos minutos de leitura que podem salvar horas de trabalho ou mesmo seu roteador. A wiki atual está ainda aquém do que era mas sempre vale a busca. Para modelos antigos, a antiga ainda tem seu valor.

Bem, se eu simplesmente ir na interface, fornecer a nova imagem, ele vai funcionar? Provavelmente, mas talvez não é a maneira que dê menos trabalho. A atualização pode preservar as configurações mas não os programas instalados. Se você tem raiz expandida em unidade externa, a encrenca é ainda maior.

"Mas eu nunca instalei um programa!" OK, use a interface web e provavelmente todas as configurações serão migradas sem problemas. Já testei isto em mais de um roteador e funcionou sem problemas. Mas faça o backup antes! Caso tenha instalado algum pacote, continue lendo.

Se está migrando da ar71xx para a ath79, o backup não poderá ser aplicado às cegas. Será necessário migrar manualmente ou refazer a configuração do zero. Se quiser arriscar, as configurações "incompatíveis" serão as que referenciam os LEDs (leds em system), o arranjo da rede (switches e vlans no network) e os rádios (radio em wireless). O resto é, na sua grande maioria, reaproveitável até mesmo para outras arquiteturas.

Em primeiro lugar, precisamos do plano de retorno caso a nova versão não se comporte como o esperado. Faça sempre um backup geral do seu sistema. No processo de upgrade, eu sugiro que sejam feitas as três formas diferentes de backup que eu comento no artigo sobre o tema: backup padrão gerado pelo sistema, lista de pacotes instalados e todos os arquivos do overlay. Este último serve apenas para o plano de retorno caso algo importante não funcione para você na nova versão (e para recuperar algo que não entrou no backup do sistema).

Recomendo estes backup:

# cd /tmp
# sysupgrade -o -k -u -b backup.tgz

Em resumo:
  • '-u': salva tudo da /overlay, exceto aquilo que vem dos pacotes, mas inclui os arquivo de configuração modificados e os listados em /etc/sysupgrade.conf
  • '-o': ignora os arquivos que são idênticos ao /rom (já estavam assim na firmware)
  • '-k': inclui uma lista de pacotes instalados para reinstalação
  • '-b': somente gera um backup, não atualiza o sistema
Dá até para fazer por SSH:

pc1$ ssh router sysupgrade -o -k -u -b - > backup.tgz

Mantenha seu backup.tgz em um lugar seguro, não no /tmp do roteador que se apaga ao reiniciar!

Agora, finalmente, você está pronto para enviar a nova firmware. Se você usa um armazenamento externo para expandir a raiz, leia até o final deste post antes de iniciar o processo!

Você pode optar por fazer o upgrade pela interface web ou pelo terminal. Inclusive, você pode baixar o arquivo diretamente no roteador. Só cuidado ao colar a URL. O openwrt.org usa HTTPS por padrão mas o "wget" do OpenWrt não tem suporte para HTTPS (por padrão). Se tiver problemas, remova o "s" de "https". E sempre salve no /tmp.

E pode fazer pela Wifi? Os fabricantes não recomendam usar sempre um computador "conectado por cabo"? Sim, e já tive problemas com atualização a partir da firmware do fabricante por não escutar isto. Mas não com OpenWrt. Se estiver atualizando (e não instalando a primeira vez!), pode fazer pela Wifi sem problemas. Quando a gravação for iniciada, todo o processo já está independente do computador cliente. Só não pode faltar energia 😉

Se optar pela interface Web, vá no menu para gravar a nova firmware, informe o arquivo .bin baixado. Confirme e reze. Se só tinha configurações e nada instalado a mais, a opção para preservar as configurações será suficiente. Caso contrário, poderá optar por preservar (ou não) as configurações e aplicar o backup gerado por "sysupgrade -o -k -u -b" na sequência. Se for fazer pela linha de comando, pode até usar o sysupgrade diretamente sem buscar um backup externo "sysupgrade -o -k -u openwrt-21.02-....img"

Se optar por preservar as configurações, tudo que seria guardado em um backup do sistema (os arquivos listado pelo "sysupgrade -l") será restaurado. Se você instalou algum pacote e guardou a lista do que foi instalado (lembra que eu sugeri há alguns parágrafos atrás?), esta é a hora que você reinstala os pacotes desejados. Se for instalar manualmente, procure instalar os pacotes de mais alto nível (ex: "luci-app-minidlna" antes de "minidlna"), pois eles irão, por dependência, baixar os pacotes necessários. No final do processo, é bom refazer a listagem do que está instalado e comparar com o que você tinha na versão anterior.

Caso tenha gerado o backup com "sysupgrade -o -k -u", você pode aplicá-lo depois da instalação, independentemente de ter optado por preservar as configurações durante a instalação.

Agora falta reinstalar os pacotes. A opção '-k' do backup gerou uma lista de pacotes instalados. Vamos aproveitá-la:

# opkg update
# grep "\toverlay" /etc/backup/installed_packages.txt | cut -f1 | xargs -r opkg install
# rm /etc/backup/installed_packages.txt
# reboot

Podem ser criados arquivos sufixados com "-opkg" em /etc/. Este são arquivos de configuração originais do pacote e são criados pois você modificou algo na configuração. Sugiro que verifique se não existe alguma coisa introduzida neste pacote que deveria ser adicionada no seu arquivo de configuração. Eu gosto do diff ou do "vim -d" para este trabalho comparando o arquivoconf com arquivoconf-opkg. Ao final do processo, eu gosto de apagar qualquer -opkg para deixar claro que apliquei tudo que queria.

As atualizações de segurança serão disponibilizadas por meio de atualização de pacotes (exceto as que exijam mudar o kernel). Para listar os pacotes atualizáveis:

# opkg update
# opkg list-upgradable

O maior problema é que estas atualizações de segurança, quando de pacotes embutidos oriundos na firmware instalada, ocuparão o espaço duas vezes no roteador pois ao substituir arquivos existentes na firmware inicial, ainda será preservado a versão em somente leitura para recuperação. Se for um problema para seu caso, a alternativa é esperar a próxima versão com a correção ou gerar uma nova firmware com o pacote atualizado.

Por fim, faça um novo backup geral. É sempre bom preservar o seu trabalho. Lembre-se que agora você pode gerar o backup com:

# cd /tmp
# sysupgrade -o -k -u -b backup.tgz

Só não esqueça de tirá-lo do /tmp pois ele será perdido ao desligar o roteador.

Se precisar retornar a versão anterior do OpenWrt, realize a gravação da firmware antiga, entre no modo de recuperação, monte a raiz e restaure o backup.

Se você não usa uma unidade externa para expandir o espaço interno, seu trabalho acabou. Para os demais, o processo é um pouco mais complicado. Ao atualizar o sistema, você terá um kernel novo que é incompatível com os módulos de kernel ou mesmo com as bibliotecas existentes na unidade externa, que ainda pertencentes à versão anterior. Você precisaria reinstalá-los. Esta é a sugestão de como proceder.

Em primeiro lugar, gere os backups sugeridos anteriormente. É importante preservar seu trabalho anterior. Ainda sem instalar a nova firmware, reinicie o sistema sem a unidade externa. Se você seguiu minha sugestão de manter uma configuração básica na flash interna, você ainda terá um ambiente funcional. Com isto, ele vai usar somente a flash interna (com a configuração que você tinha antes de usar a unidade externa).

Com a unidade externa conectada, faça o backup como sugerido anteriormente. Reinicie o roteaador sem a unidade externa e faça o procedimento de atualização descrito neste artigo para quem não usa raiz expandida, inclusive com a etapa de backups. Você terá que preservar os dois conjuntos de backups: com e sem a unidade externa em uso. Ao final do processo, você deverá ter a sua configuração básica restabelecida. Caso tenha optado por não preservar as configurações na gravação, você pode aproveitar o backup gerado quando a unidade externa estava desconectada (o segundo) para restaurar as configurações.

Neste momento, a unidade externa ainda está com os programas da versão anterior, que são geralmente incompatíveis com a nova versão (os módulos de kernel sempre o são). Por isto, precisamos nos livrar de todos os arquivos da versão anterior do OpenWrt presentes na unidade externa. Na unidade externa, na partição usada como overlay, remova todo o conteúdo ou mova tudo para um subdiretório (ou para outra unidade se não estiver com espaço livre) afim de que este não seja usado. Como sugestão, crie um "openwrt-versao-xxx" e mova tudo para lá. Refaça a configuração de uso de uma unidade externa (que no mínimo será reinstalar os pacotes necessários). Reinicie o sistema. Você deve estar agora com mais espaço na raiz.

Neste ponto, você ainda terá as mesmas configurações que tinha quando usou o sistema sem a unidade externa. Envie o primeiro backup da versão anterior feito com a unidade externa conectada (primeiro backup). Na sequência, reinstale os pacotes extras, assim como é feito para ambientes sem a raiz expandida. Complete o trabalho com aquele backup final.

Espero que apreciem a nova versão. De agora em diante, vou apenas focar em configurações específicas para OpenWrt 21.02, que ainda podem funcionar nas versões anteriores.

Até a próxima.

domingo, 5 de setembro de 2021

OpenWrt: versão 21.02 lançada!

Mais um artigo da série sobre o OpenWrt.

Enfim, a 21.02 foi lançada! Demorou bem mais do que o que seria o esperado mas antes tarde que mais tarde. Vamos as novidades:

Primeiro, se você tem um dispositivo com 4 MB de flash e 32 MB de RAM, vai ficar difícil para você. O mínimo agora é 8 MB de flash e 64 MB de RAM. É o fim da linha para muitos entre o TL-WR740ND e TL-WR1043ND. Se souber o que está fazendo, pode customizar a firmware removendo supérfluos com a interface web. Porém, mesmo removendo coisas, a memória RAM limitada pode acabar te sabotando. Eu ainda uso esporadicamente um TL-WR740ND como AP, mas não arriscaria minha internet com ele como roteador, em especial pela Wifi. Minha sugestão? Agradeça a seu velho companheiro e compre um roteador novo. Ou você pode segurar por mais um tempo no 19.07 que ainda terá atualizações de correções e segurança até a próxima versão maior do OpenWrt.

"E qual modelo você recomenda?"A recomendação é buscar modelos com 16 MB de flash e 128 MB de RAM. E a oferta no mercado não está ajudando, principalmente no Brasil. Só não se apegue na esperança que vai surgir um novo modelo lindo, cheio de recursos e barato. Nada de revolucionário surgiu por anos e o velho TP-Link Archer C7 ainda desponta na lista das recomendações. Os baseados em Broadcom nunca tiveram e não vão ter drivers da Wifi, o que elimina quase metade dos modelos acessíveis. Resta dos econômicos um ou outro modelo da TP-Link, D-Link ou Xiaomi ou adicionar um dígito no preço e comprar um Linksys, ASUS,.... Se está aguardando algo com IEEE 802.11ax (vulgo Wifi 6), por enquanto só tem suporte alguns roteadores que usam MediaTek.

A grande novidade da versão é a introdução do DSA no lugar do swconfig. Antes, era como se o OpenWrt fosse um computador com uma porta (ou mais) ligada a um switch gerenciável e o swconfig era o software para configurar este switch. Agora com o DSA, as portas do switch se apresentam como portas do sistema operacional (aparecem no "ip link") e elas são agrupadas como já ocorre com pontes em software (pelo comando "ip"). O sistema operacional cuida, de forma transparente, de escolher como arranjar as portas para usar os recursos em hardware. Mas isso dá algum benefício ao usuário final? Não muito. Uma vantagem é que mudanças no link das portas agora são visíveis ao sistema operacional. Antes o OpenWrt não tinha como saber que a porta usada pela Wan está sem link. Para quem administra o OpenWrt, talvez o DSA seja mais intuitivo pois, para os iniciantes, era difícil ver que a única interface de rede que o sistema operacional via (eth0) não era nenhuma das 5 portas que ele via externamente. Para o projeto a mudança é muito bem vinda pois o DSA já está no kernel do Linux, enquanto o swconfig nunca foi e nunca será aceito. Assim, pode-se reduzir os custos de manter as modificações em paralelo.

"Ótimo, vou logo instalar o 21.02 para ver como o DSA..." Pera aí! A maioria dos modelos não foi migrada. Acredito que o próximo esforço do projeto será migrar tudo para DSA mas, por enquanto, a lista de modelos suportados é pequena. Todavia, a introdução do DSA trouxe uma nova família de produtos para o OpenWrt: switches gerenciáveis de rede. Por enquanto são só modelos (de diversos fabricantes) baseados em Realtek. Não vejo a hora de poder padronizar a gestão de switches de rede em OpenWrt.

O DSA exigiu uma mudança na configuração e aproveitaram o embalo para trocar uns nomes. A configuração antiga ainda vale mas uma configuração nova irá usar nomes diferentes para algumas seções e campos e a interface web vai migrar algumas coisas no primeiro uso. Vai exigir uma pequena adaptação mas vejo como uma mudança para o bom sentido pois temos configurações bem isolada mostrando o que é camada 2 ("device") e camada 3 ("interface").

Ah, se for atualizar para um modelo que migrou para DSA, você verá um erro assustador dizendo que a imagem não é compatível por causa dele. Infelizmente a única forma de instalar de dentro do OpenWrt é forçando a instalação. O problema é "forçar" permite também a instalação de uma imagem errada. Faça com cuidado e preferencialmente em modelos com um método de recuperação de firmware corrompido.

Outra novidade é a inclusão do WPA3 na imagem padrão. Já era possível usar WPA3 no 19.07, mas era preciso instalar e trocar alguns pacotes. E como o WPA3 precisa de uma implementação de SSL, tudo que dependeria de SSL sai quase "de graça", como a interface web por https://. Isso foi um dos motivos (mas não o único) da incompatibilidade com flashes de 4 MB.

Para quem ainda não migrou do ar71xx para o ath76, como esperado, o ar71xx não existe mais. A maioria dos modelos foram migrados e, apesar de não existir uma migração automática, muito da migração é um copia/cola.

E como qualquer nova versão, temos muitas atualizações, com destaque ao kernel 5.4. Ativaram também a aleatorização dos endereços de memória (ASLR) e recursos necessários para containers. Logo poderemos ver os serviços do OpenWrt conteinerizados.

Por fim, esta versão foi lançada com um problema sério conhecido. Para quem depende da aceleração do NAT por software (software offload) para conseguir usar a velocidade de internet contratada, existe o problema de perda de pacotes com o IPv6. Então, para estes, talvez seja bom esperar por uma versão com este problema corrigido.

Vale a pena atualizar? Realmente é uma pergunta difícil de responder. A nova versão trouxe pouco para o OpenWrt. Claro que junto com a nova versão temos uma miríade de pacotes adicionados e atualizados que podem ter melhorias de seu interesse. Mas para quem não instala nada no OpenWrt além da imagem padrão, fica difícil justificar o trabalho do upgrade (mesmo que pequeno). Eu vou atualizar meus equipamentos pelas atualizações nos pacotes e por obrigação de ofício. Depois envio uma postagem sobre o upgrade.

Até a próxima.

sexta-feira, 10 de janeiro de 2020

OpenWrt: atualizando para a versão 19.07

Mais um artigo da série sobre o OpenWrt.

Enfim temos uma nova versão do OpenWrt. Mãos a obra para atualizar!

No post anterior, comentei sobre o lançamento do OpenWrt 19.07. Dois pontos importantes para relembrar:
  • se seu dispositivo tem 4 MBytes de flash, talvez não funcione e você terá que fazer um downgrade. Vou fazer um artigo sobre isso;
  • para os usuários da plataforma ar71xx na versão 18.06, temos a opção de se manter no ar71xx (mas na versão 19.07) ou migrar para a ath76.
96,72% dos problemas com instalação/atualização com OpenWrt/LEDE que ajudo é em relação a escolha incorreta da imagem da firmware. O OpenWrt tem uma página que simplifica a busca pela firmware correta, mas nada é à prova de pessoas criativas. Pegue o arquivo no download da última versão estável e nunca em um endereço qualquer, mesmo que seja em um artigo na wiki do OpenWrt (lembre-se como funciona uma wiki). Normalmente a wiki referência a versão em desenvolvimento, que não é a que você quer. As versões dentro de "(stables) releases", exceto as com o rc (release candidate) são estáveis. Pegue preferencialmente a mais nova (com número maior). Evite qualquer firmware que tenha no caminho palavras como "trunk", "snapshot" ou "rc1", "rc2"... exceto se estiver testando algo. As versões estáveis também mencionam a respectiva versão do OpenWrt no nome do arquivo como em "openwrt-19.07.0-ath79-generic-tplink_archer-c7-v4-squashfs-sysupgrade.bin", ao contrário da versão instável/em desenvolvimento "openwrt-ath79-generic-tplink_archer-c7-v4-squashfs-sysupgrade.bin".

A nomeclatura da versão é adota o formato: ano.mês.correção. O ano/mês se referem ao momento que foi criado um ramo nos fontes para o lançamento da nova versão e não propriamente quando o lançamento final ocorreu. Já o último número é apenas um sequencial de correção. Então, para quem usa uma versão 19.07.x, a próxima 19.07.x+1 deverá conter apenas bugs resolvidos (em especial, os de segurança) e deve ser considerada como recomendada. Estas versões de correção são lançadas com certa frequência. É bom acompanhar (e atualizar).

Na página principal, temos um atalho para cada versão lançada com o nome "Download a firmware image for your device". Isso irá redirecionar uma tabela de hardware suportáveis, com filtragem dinâmica. Alternativamente, você sempre pode optar por clicar em "All firmware images" e buscar manualmente sua firmware, como ocorria com versões anteriores. Na dúvida, se você já é um usuário do OpenWrt, você pode descobrir a plataforma olhando o arquivo /etc/openwrt_release ou /etc/os-release:

root@router:~#  grep _TARGET /etc/openwrt_release 
DISTRIB_TARGET='ar71xx/generic'

root@router:~# grep _BOARD /etc/os-release
LEDE_BOARD="ar71xx/tiny"

root@router:~# grep _BOARD /etc/os-release
OPENWRT_BOARD="ramips/mt7620

OK, chegamos a uma lista enorme de firmwares! Vamos entender o que significa cada parte do nome do arquivo. Tomemos por exemplo "openwrt-19.07.0-ath79-generic-tplink_archer-c7-v4-squashfs-sysupgrade.bin":
  • openwrt é o sistema operacional que você está instalando 😉
  • 19.07.0 é a versão do openwrt. Em firmwares instáveis, este campo não existe!
  • ath79 é a plataforma do seu dispositivo. Você descobre isso na wiki do projeto ou na tabela de hardware (ToH), campo "Target".
  • generic é o subtipo do layout da flash. Normalmente será o "generic", exceto para casos especiais como roteadores com 4 MB que usam "tiny".
  • tplink_archer-c7-v4 este é o modelo do seu roteador. Observe em especial a versão do HW (v4) pois ela pode mudar completamente o dispositivo, inclusive de família do SoC e se é suportado pelo OpenWrt.
"squashfs" é o tipo do armazenamento da imagem. Nesta, existe uma cópia imutável dos arquivos (ROM) e o resto da flash é usada para, de forma transparente, guardar as modificações (overlay). Tudo parece editável para o usuário. A diferença é que você pode, a qualquer momento, apagar as diferenças e restaurar o sistema pós-instalação. Existem outros formatos como o jffs2 (com escrita total sem recuperação), initram (rodar sem gravar na flash), mas normalmente são para casos marginais.

"sysupgrade" é a função da firmware. Esta é para atualizar de um OpenWrt para outro (e, em alguns casos, de outros firmwares alternativos como DD-WRT). Porém, não deve ser reconhecido pela firmware original do roteador. Para primeira instalação, ainda com a firmware original, use a variante "factory".

Finalmente, é muito importante ler a wiki do seu roteador independente se ele já funcionava na versão anterior! São poucos minutos de leitura que podem salvar horas de trabalho ou mesmo seu roteador. A wiki atual está ainda aquém do que era mas sempre vale a busca. Para modelos antigos, a antiga ainda tem seu valor.

Bem, se eu simplesmente ir na interface, fornecer a nova imagem, ele vai funcionar? Provavelmente, mas talvez não é a maneira que dê menos trabalho. A atualização pode preservar as configurações mas não os programas instalados. Se você tem raiz expandida em unidade externa, a encrenca é ainda maior.

"Mas eu nunca instalei um programa!" OK, use a interface web e provavelmente todas as configurações serão migradas sem problemas. Já testei isto em mais de um roteador e funcionou sem problemas. Mas faça o backup antes! Caso tenha instalado algum pacote, continue lendo.

Se optou por migrar da ar71xx para a ath79, o backup não poderá ser aplicado às cegas. Será necessário migrar manualmente ou refazer a configuração do zero. Se quiser arriscar, as configurações "incompatíveis" serão as que referenciam os leds (leds em system), o arranjo da rede (switches e vlans no network) e os rádios (radio em wireless). O resto é, na sua grande maioria, reaproveitável até mesmo para outras arquiteturas.

Em primeiro lugar, precisamos do plano de retorno caso a nova versão não se comporte como o esperado. Faça sempre um backup geral do seu sistema. No processo de upgrade, eu sugiro que sejam feitas as três formas diferentes de backup que eu comento no artigo sobre o tema: backup padrão gerado pelo sistema, lista de pacotes instalados e todos os arquivos do overlay. Este último serve apenas para o plano de retorno caso algo importante não funcione para você na nova versão (e para recuperar algo que não entrou no backup do sistema).

A partir da versão 19.07 (depois dela estar instalada) teremos mais opções para gerar o backup. Se estiver familizarizado com a CLI, as novas opções facilitam em muito o processo. Tudo que você precisará está no backup gerado com:

# cd /tmp
# sysupgrade -o -k -u -b backup.tgz

Em resumo:
  • '-u': salva tudo da /overlay, exceto aquilo que vem dos pacotes, mas inclui os arquivo de configuração modificados e os listados em /etc/sysupgrade.conf
  • '-o': ignora os arquivos que são idênticos ao /rom (já estavam assim na firmware)
  • '-k': inclui uma lista de pacotes instalados para reinstalação
  • '-b': somente gera um backup, não atualiza o sistema
Para atualizações da versão anterior, você pode baixar o novo sysupgrade no /tmp e usá-lo com:

# cd /tmp
# wget http://luizluca.github.io/sysupgrade
# chmod +x ./sysupgrade
# ./sysupgrade -o -k -u -b backup.tgz

E salve seu backup.tgz em um lugar seguro.

Agora, finalmente, você está pronto para enviar a nova firmware. Se você usa um armazenamento externo para expandir a raiz, leia até o final deste post antes de iniciar o processo!

Vocẽ pode optar por fazer o upgrade pela interface web ou pelo terminal. Inclusive, você pode baixar o arquivo diretamente no roteador. Só cuidado ao colar a URL. O openwrt.org usa HTTPS por padrão mas o "wget" do OpenWRT não tem suporte para HTTPS (por padrão). Se tiver problemas, remova o "s" de "https". E sempre salve no /tmp.

E pode fazer pela Wifi? Os fabricantes não recomendam usar sempre um computador "conectado por cabo"? Sim, e já tive problemas com atualização a partir da firmware do fabricante por não escutar isto. Mas não com OpenWRT. Se estiver atualizando (e não instalando a primeira vez!), pode fazer pela Wifi sem problemas. Quando a gravação for iniciada, todo o processo já está independente do computador cliente. Só não pode faltar energia 😉

Se optar pela interface Web, vá no menu para gravar a nova firmware, informe o arquivo .bin baixado. Confirme e reze. Se só tinha configurações e nada instalado a mais, a opção para preservar as configurações será suficiente. Caso contrário, poderá optar por preservar (ou não) as configurações e aplicar o backup gerado por "sysupgrade -o -k -u -b" na sequência.

Se optar por preservar as configurações, tudo que seria guardado em um backup do sistema (os arquivos listado pelo "sysupgrade -l") será restaurado. Se você instalou algum pacote e guardou a lista do que foi instalado (lembra que eu sugeri há alguns parágrafos atrás?), esta é a hora que você reinstala os pacotes desejados. Se for instalar manualmente, procure instalar os pacotes de mais alto nível (ex: "luci-app-minidlna" antes de "minidlna"), pois eles irão, por dependência, baixar os pacotes necessários. No final do processo, é bom refazer a listagem do que está instalado e comparar com o que você tinha na versão anterior.

Caso tenha gerado o backup com "sysupgrade -o -k -u -b", você pode aplicá-lo depois da instalação, independentemente de ter optado por preservar as configurações. A diferença é que o processo de reinstalação de pacotes é simplificado.

# opkg update
# grep "\toverlay" /etc/backup/installed_packages.txt | cut -f1 | xargs -r opkg install
# rm /etc/backup/installed_packages.txt
# reboot

Podem ser criados arquivos sufixados com "-opkg" em /etc/. Este são arquivos de configuração originais do pacote e são criados pois você modificou algo na configuração. Sugiro que verifique se não existe alguma coisa introduzida neste pacote que deveria ser adicionada no seu arquivo de configuração. Eu gosto do diff ou do "vim -d" para este trabalho comparando o arquivoconf com arquivoconf-opkg. Ao final do processo, eu gosto de apagar qualquer -opkg para deixar claro que apliquei tudo que queria.

As atualizações de segurança serão disponibilizadas por meio de atualização de pacotes (exceto as que exijam mudar o kernel). Para listar os pacotes atualizáveis:

# opkg update
# opkg list-upgradable

O maior problema é que estas atualizações de segurança, quando de pacotes embutidos oriundos na firmware instalada, ocuparão o espaço duas vezes no roteador pois ao substituir arquivos existentes na firmware inicial, ainda será preservado a versão em somente leitura para recuperação. Se for um problema para seu caso, a alternativa é esperar a próxima versão com a correção ou gerar uma nova firmware com o pacote atualizado.

Por fim, faça um novo backup geral. É sempre bom preservar o seu trabalho. Lembre-se que agora você pode gerar o backup com:

# cd /tmp
# sysupgrade -o -k -u -b backup.tgz

Só não esqueça de tirá-lo do /tmp pois ele será perdido ao desligar o roteador.

Se precisar retornar a versão anterior do OpenWRT, realize a gravação da firmware antiga, entre no modo de recuperação e restaure a overlay.

Se você não usa uma unidade externa para expandir o espaço interno, seu trabalho acabou. Para os demais, o processo é um pouco mais complicado. Ao atualizar o sistema, você terá um kernel novo que é incompatível com os módulos de kernel ou mesmo com as bibliotecas existentes na unidade externa, que ainda pertencentes à versão anterior. Você precisaria reinstalá-los. Esta é a sugestão de como proceder.

Em primeiro lugar, gere os backups sugeridos anteriormente. É importante preservar seu trabalho anterior. Ainda sem instalar a nova firmware, reinicie o sistema sem a unidade externa. Se você seguiu minha sugestão de manter uma configuração básica na flash interna, você ainda terá um ambiente funcional. Com isto, ele vai usar somente a flash interna (com a configuração que você tinha antes de usar a unidade externa).

Com a unidade externa conectada, faça o backup como sugerido anteriormente. Reinicie o roteaador sem a unidade externa e faça o procedimento de atualização descrito neste artigo para quem não usa raiz expandida, inclusive com a etapa de backups. Você terá que preservar os dois conjuntos de backups: com e sem a unidade externa em uso. Ao final do processo, você deverá ter a sua configuração básica restabelecida. Caso tenha optado por não preservar as configurações na gravação, você pode aproveitar o backup gerado quando a unidade externa estava desconectada (o segundo) para restaurar as configurações.

Neste momento, a unidade externa ainda está com os programas da versão anterior, que são geralmente incompatíveis com a nova versão (os módulos de kernel sempre o são). Por isto, precisamos nos livrar de todos os arquivos da versão anterior do OpenWrt presentes na unidade externa. Na unidade externa, na partição usada como overlay, remova todo o conteúdo ou mova tudo para um subdiretório (ou para outra unidade se não estiver com espaço livre) afim de que este não seja usado. Como sugestão, crie um "openwrt-versao-xxx" e mova tudo para lá. Refaça a configuração de uso de uma unidade externa (que no mínimo será reinstalar os pacotes necessários). Reinicie o sistema. Você deve estar agora com mais espaço na raiz.

Neste ponto, você ainda terá as mesmas configurações que tinha quando usou o sistema sem a unidade externa. Envie o primeiro backup da versão anterior feito com a unidade externa conectada (primeiro backup). Na sequência, reinstale os pacotes extras, assim como é feito para ambientes sem a raiz expandida. Complete o trabalho com aquele backup final.

Espero que apreciem a nova versão. De agora em diante, vou apenas focar em configurações específicas para OpenWrt 19.07, que ainda podem funcionar nas versões anteriores.

Até a próxima.

OpenWrt: versão 19.07 lançada!

Mais um artigo da série sobre o OpenWrt.

Enfim, depois de muito tempo (era para ser 19.01) e alguns atrasos (o 7 na versão significa julho), temos uma nova versão do OpenWrt! E obviamente temos um batalhão de correções e algumas novidades interessantes.

Uma primeira e mais impactante é a introdução da plataforma ath79 que irá substituir o muito popular ar71xx. Se você tem um dispositivo TP-Link, tem uma grande probabilidade de usar o ar71xx. A plataforma compartilha um kernel e normalmente atende a uma família de SoC (no caso do ar71xx e ath79, Qualcomm Atheros ar71xx, ar72xx, ar91xx, ar93xx, qca95xx). Só para não misturar, plataforma não é o mesmo que ISA (conjunto de instruções), que pode ser compartilhado entre diversas plataformas como ARM, MIPS (big e little endian), RISC-V e x86. O maior problema do ar71xx era que a descrição do hardware era feita por código C em arquivos tipo march. Cada vez que aparecia um novo dispositivo, mais um pedacinho de código era anexada no kernel (lembra que ele é compartilhado na plataforma?) e isso vai fazendo ele crescer. A alternativa é usar Device Tree, que descreve o hardware de cada dispositivo em uma linguagem própria. Esse arquivo é compilado para cada dispositivo e é anexado ao kernel durante a montagem da firmware. Assim, cada firmware terá apenas a descrição do seu próprio hardware, salvando alguns escassos kbytes de flash. O ath79 é basicamente a migração do ar71xx para o Device Tree. E, principalmente, nos últimos anos, nada entra no Linux que não use Device Tree. Isso permite iniciar os trabalhos de subir o ath79 do OpenWrt para o kernel principal. Agora, vou tentar antecipar algumas perguntas:

P: Meu dispositivo usa ar71xx no 18.06. Posso migrar para ath79?
R: Provavelmente, mas nem todos foram portado. E o ar71xx ainda continua a existir no 19.07.

P: Posso só fazer um sysupgrade do ar71xx para o ath79?
R: Sim, mas as configurações não são exatamente compatíveis. Migrações sem preservar as configurações funcionarão perfeitamente quando o modelo estiver suportando em ambas.

P: Posso manter a configuração do ar71xx no ath79?
R: Na sua essência sim, mas a migração do march para Device Tree permitiu arrumar a casa. Então o nome de LEDs e o caminho das placas Wireless mudaram. O nome dos modelos do roteador também podem ter mudado. É possível que, simplesmente aplicando a configuração do ar71xx, diversas coisas deixem de funcionar, o que exigiria um retrabalho a mais. Sugiro fazer um bom backup e começar do zero, restaurando pontualmente os arquivos.

P: Devo migrar agora do ar71xx para o ath79?
R: Para novos dispositivos, sim. Para upgrades limpos (sem preservar a configuração), sim. Todavia, provavelmente a migração será mais suave (ou não) na próxima versão quando a plataforma ar71xx será removida definitivamente.

Outra novidade interessante é a padronização do kernel na versão 4.14. Isso traz o suporte para a aceleração do roteamento a um bom nível para boa parte das plataformas. Infelizmente poucos têm uma internet de mais de 200 Mbps para usufruir desta melhoria.

Um outro recurso interessante é o suporte ao 802.11r Fast Transition ou Fast Roaming. Para ambientes com múltiplos APs com o mesmo nome/senha, o 802.11r permite a rápida troca de APs. Só não vai funcionar com o wpad-mini (o wpad-basic é o suficiente).

Temos também o suporte para WPA3. Porém, deve exigir o wpad-openssl (o wpad-wolfssl está com problemas).

Agora umas pequenas melhorias de autoria deste que vos escreve.
  1. trafficshaper: pacote para configurar limitação, reserva e priorização de taxa de transferência para classes de máquinas. Era uma pedida frequente.
  2. sysupgrade agora pode gerar backups mais limpos ignorando arquivos não modificados (-u), mais completos, salvando além da configuração (-o) e com uma lista dos pacotes instalados e sua "origem" (-k). Comentei sobre estas opções no passado. No artigo da atualização, devo citá-las novamente.

Provavelmente cada um carece de uma postagem própria.

Por fim, o lado ruim. Como grande parte das atualizações, tudo cresceu de tamanho. Os proprietários de dispositivos com flash de 4 MBytes podem não conseguir atualizar. Para os dispositivos que ainda funcionam, esta será a sua última versão pois o plano é encerrar o suporte para flash pequenas (4 Mbytes ou menos) ou com pouca memória RAM (32 MBytes ou menos) depois da versão 19.07. É o fim da linha para o TL-WR740ND.

Até a próxima.