luizluca

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

2024-11-04T00:12:00.000-03:00

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.

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

2024-08-11T10:52:00.003-03:00

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:

dev	size	erasesize	name
mtd0	00080000	00010000	BOOT
mtd1	00040000	00010000	BDINFO
mtd2	00040000	00010000	BDINFO2
mtd3	00180000	00010000	KERNEL1
mtd4	00c00000	00010000	ROOTFS1
mtd5	00180000	00010000	KERNEL2
mtd6	00040000	00010000	SYSINFO
mtd7	00c00000	00010000	ROOTFS2
mtd8	003c0000	00010000	JFFS2

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!

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

2024-08-04T16:13:00.000-03:00

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:

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!);
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");
O campo da tabela do endereço IPv6 é pequeno: corta o final do endereço (demorei para perceber);
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.

OpenWrt: atualizando para a versão 21.02

2021-09-06T10:00:00.007-03:00

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.

OpenWrt: versão 21.02 lançada!

2021-09-05T00:56:00.002-03:00

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.

OpenWrt: atualizando para a versão 19.07

2020-01-10T11:30:00.000-03:00

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!

2020-01-10T00:08:00.000-03:00

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.

trafficshaper: pacote para configurar limitação, reserva e priorização de taxa de transferência para classes de máquinas. Era uma pedida frequente.
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.

OpenWrt: desativando horário de verão (pela última vez?)

2019-11-12T23:46:00.000-03:00

Mais um artigo da série sobre o OpenWrt.

Essa vai ser uma postagem relâmpago! Neste ano, para a alegria e tristeza de muitos, não teremos mais horário de verão. Como diversos sistemas, o OpenWrt também irá exigir uma pequena configuração para resolver o "problema".

O OpenWrt, na verdade, não tem o banco de dados com as regras do fuso horário. Ele simplesmente tem um campo system.@system[0].timezone onde você pode configurar quando ocorre a mudança no horário e outro system.@system[0].zonename com o "nome fantasia" do fuso horário. Quem provê uma lista com os nomes dos fusos e "regras" é o Luci (interface web), com toda limitação inerente a esta forma de representação das regras (como o caso onde o fim do horário de verão era postergado em uma semana se ele fosse coincidir com o Carvanal).

Mas vamos a prática. Rode:

uci set system.@system[0].timezone='BRT3'
uci commit
reboot

E seja feliz.

Agora, vamos combinar: não tenho uma opinião forte quanto a ter ou não o horário de verão. SÓ PARE DE MUDAR A REGRA! Muito obrigado.

Até a próxima.

OpenWrt: horário de verão novo

2018-10-22T02:36:00.000-03:00

Mais um artigo da série sobre o OpenWRT/LEDE.

Senta que lá vem a história... (se quiser só a parte técnica, pule para o final)

Era uma vez, em uma terra sombria, existiam computeiros que sofriam todos os anos do mesmo mal: horário de verão. Não por acordar mais cedo, que geralmente também é verdade, mas pelo trabalho de reconfigurar dezenas, centenas, milhares de equipamentos com uma regra de mudança de horário mais volúvel que uma pluma ao vento. E pior, era definido em cima da hora. Parecia algo insolúvel, digno dos teoremas de Fermat. Porém, quando todos já haviam perdido a esperança, surge do alto do seu cavalo branco um ser iluminado que define uma regra fixa! Eureka! E todos viveram feliz para sempre... até este ano. A partir deste ano, o horário começa na primeira semana de novembro. E talvez mude de novo no próximo ano, e de novo....

Mas para que mexer?! Bem, existe uma lenda de um estado chamado Acre. Eles usam um horário com 2 horas a menos que Brasília. Com o horário de verão, esta diferença fica de 3 horas. E eu com isso?! Veja bem, a cada quatro anos, temos eleições nacionais. E para não influenciar os que ainda estão votando, não são divulgados os resultados parciais até o horário de encerramento da votação. Lembra do Acre? Eles também votam para presidente! Então, no primeiro turno, a primeira parcial nacional divulgada é às 19 horas (Brasília). Já no segundo turno, com o Acre ainda mais atrasado (no horário!), eles votam até às 20 horas (bem, tem mais brasileiro no exterior que no Acre e que ainda estarão votando... mas não vem ao caso). Depois de três horas do fim da votação, quase todos os votos já foram totalizados e, normalmente, temos uma boa ideia do resultado final. Uns dizem que isso traz ansiedade à sociedade. Outros que pode passar a ideia que estão "modificando o resultado". Tem até gente que diz que "perde a graça", meio como "ejaculação precoce".

Em resumo: para não influenciar os eleitores do Acre mas ainda divulgar o resultado às 19h, mudaram o início do horário para o primeiro domingo depois das eleições (ou primeiro domingo de novembro). Valeu Temer! Ótimo trabalho! Dane-se o custo de reconfigurar milhões de dispositivos, dane-se quem já planejava eventos anuais para não coincidir com a troca (ENEM?), dane-se quem vai perder uma hora de sono com trocas antecipadas do horário, DANE-SE TUDO! Eu acho que é mais importante saber o resultado PARCIAL das eleições nacionais uma hora antes. Eu quero e pronto!

Pergunta para qualquer um se eles querem ser acordados por engano uma hora antes ou ter o resultado parcial das eleições nacionais uma hora antes? Se já sabe a resposta, era só seguir. Isso é mais ou menos o que seria uma tal de democracia.

Só uma observação: no Acre temos 547.680 eleitores. Se eles votarem de forma bem distribuída ao longo das 10 horas de votação, a divulgação às 19h de Brasília poderia influenciar 10% do eleitorado, ou 54.768 eleitores. Se descontar os históricos 30% de brancos, nulos e abstenções, seriam um pouco mais de 38.000 eleitores! Agora pense quantos destes mudariam o voto sabendo da PARCIAL nos outros estados. Se for uns 20%, são míseros 7.667 eleitores. TUDO ISSO PARA ISSO?!

Início parte técnica

Mas voltando ao OpenWrt, ele não usa banco de dados de horário. A configuração do fuso já incluí o horário de verão.

# uci show system.@system[0].timezone

system.cfg01e48a.timezone='BRT3BRST,M10.3.0/0,M2.3.0/0'

Se você configurou pela interface web (Luci) o fuso de São Paulo, ele tem um banco de dados com essas regras e preenche para você. Se você estiver como Luci atualizado, este banco está atualizado. Porém, ele é usado apenas durante a mudança de configuração pelo Luci. Se mudar a regra, ele não vai automaticamente trocar a configuração.

Para resolver:

# uci set system.@system[0].timezone='BRT3BRST,M11.1.0/0,M2.3.0/0'

# uci commit

# reboot

Também pode trocar o fuso pela interface web ou editar o /etc/config/system. Fica a gosto do cliente.

O formato da configuração é bem simples. Nota-se que o retorno está definido no terceiro domingo de fevereiro. E não é que temos uma exceção? Essa regra quebra se a volta for no carnaval (algo raro). Para não dar mais uma hora de folia, adia-se o final para o próximo final de semana.

Então é isso. Bom sono a todos. Até a próxima.

OpenWrt: atualizando para a versão 18.06

2018-08-19T00:34:00.000-03:00

Mais um artigo da série sobre o OpenWRT/LEDE.

No post anterior, comentei sobre o lançamento do OpenWrt 18.06. Agora vamos instalá-lo.
Sim, este artigo repete diversos pontos do artigo da versão LEDE 17.01 e a anteanterior.

Só um aviso: já foi lançada a versão 18.06.1 devido a uma vulnerabilidade no kernel.

96,72% dos problemas com instalação/atualização com OpenWrt/LEDE que ajudo é em relação a escolha incorreta da imagem da firmware. Como sempre, recomendo a versão squashfs, que possui modo de recuperação. A variante jffs2 e ext4 nem estão mais disponível por padrão para a maioria dos dispositivos. Pegue o arquivo no download da última versão estável e nunca em um endereço qualquer, mesmo que seja na wiki do OpenWrt. 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-18.06.1-ar71xx-generic-archer-c7-v4-squashfs-sysupgrade.bin", ao contrário da versão instável/em desenvolvimento "openwrt-ar71xx-generic-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 18.06.x, a próxima 18.06.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).

Em downloads, navegue para releases, a versão desejada (ex: 18.06.x), a "arquitetura alvo" em uso no seu roteador. Se você já é um usuário do OpenWRT, você pode vê-la olhando o arquivo /etc/openwrt_release:

root@router:~# grep _TARGET /etc/openwrt_release

DISTRIB_TARGET='ar71xx/generic'

Ou:

root@router:~# grep _BOARD /etc/os-release

LEDE_BOARD="ar71xx/tiny"

OK, chegamos a uma lista enorme de firmwares! Vamos entender o que significa cada parte do nome do arquivo. Tomemos por exemplo "openwrt-18.06.1-ar71xx-generic-archer-c7-v4-squashfs-sysupgrade.bin":

openwrt é o sistema operacional que você está instalando ;-)
18.06.1 é a versão do openwrt. Em firmwares instáveis, este campo não existe!
ar71xx é a família do SoC (chip) do seu dispositivo. Você descobre isso na wiki do projeto ou abrindo o seu roteador e lendo os CI.
generic é o subtipo do layout da flash. Normalmente será o "generic", exceto para casos especiais como roteadores com 4 MB que agora usam "tiny".
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. Pode existir também o formato jffs2. Neste, não existe uma ROM e tudo pode ser realmente apagado. Alterou o arquivo errado? Vai ter que recuperar pela serial, JTAG ou arrancando a flash. Não recomendo!
sysupgrade é a função da firmware. Esta é para atualizar de um OpenWrt/LEDE 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.

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.

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 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).

Eu fiz uma proposta de melhoria do backup do OpenWrt para simplificar este processo. Vamos ver como será a aceitação. Mais abaixo mostro como usá-la.

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! Faça o upgrade pela interface web ou pelo terminal. Inclusive, você pode baixar o arquivo diretamente no roteador. Só cuidado ao colar a URL. O downloads.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 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 ;-)

E depois do "Enter"/"Gravar", é a hora que você reza. Sempre dá um frio na barriga.

Se optar por preservar as configurações, tudo que seria guardado em um backup do sistema (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.

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.

Se estiver familizarizado com um terminal, você pode experimentar os novos modos de backup que eu comentei anteriormente. As novas opções são:

'-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

Isso simplifica em muito as instalações mais complexas, com arquivos e pacotes extra. O resultado final é próximo ao que você tem em uma atualização de distribuição no Linux, onde os arquivos são preservados e os pacotes reinstalados:

# cd /tmp

# wget http://luizluca.github.io/sysupgrade

# chmod +x ./sysupgrade

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

# wget https://downloads.openwrt.org/releases/.../openwrt....bin

# sysupgrade -f backup.tgz openwrt...-sysupgrade.bin

# opkg update

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

# rm /etc/backup/installed_packages.txt

# reboot

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 todos 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).

Ainda com a unidade externa desconectada, 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 18.06, que ainda podem funcionar nas versões LEDE 17.01, OpenWRT 15.05, 14.07, 12.09 e 10.03.1.

Se pintar um problema, tem sempre o fórum deste blog. Até a próxima.

OpenWrt: Lançada a versão 18.06!

2018-08-05T00:07:00.000-03:00

Mais um artigo da série sobre o OpenWRT.

Enfim temos novamente uma nova versão do OpenWrt: a versão 18.06!

OpenWrt? E o LEDE? Para quem perdeu a novela, tem a versão "mais" "longa". Vai um resumo: os desenvolvedores do OpenWrt se estranharam com os "fundadores", criaram um novo projeto levando quase todo mundo. O LEDE se tornou um projeto vibrante enquanto o OpenWrt mor-ré-u de solidão. Diante da situação, os dois grupos conversaram e resolveram se unir novamente. Basicamente aproveitaram o nome do OpenWrt e todo o resto do LEDE (código, wiki, fonte, ...). Então, o OpenWrt 18.06 é muito mais próximo do LEDE 17.01 do que do OpenWrt 15.05. Independentemente se estava usando OpenWrt ou LEDE, a sua próxima versão será OpenWrt 18.06.

E o que temos de novidades? Sim! Como sempre, o kernel muitos softwares foram atualizados. Vamos aos destaques:

Dois kernels

Teremos alguns roteadores com o kernel 4.14 e outros com o 4.9:

Kernel 4.9.111 for ar7, ar71xx, arc770, at91, brcm2708, brcm63xx, ixp4xx, lantiq, layerscape, mpc85xx, orion, rb532 and uml
Kernel 4.14.52 for apm821xx, archs38, armvirt, ath25, bcm53xx, brcm47xx, cns3xxx, gemini, imx6, ipq40xx, ipq806x, kirkwood, malta, mediatek, mvebu, mxs, octeon, octeontx, omap, oxnas, pistachio, ramips, sunxi and x86

E isso importa para o usuário final? Sinceramente, geralmente não. Porém, o próximo item depende da versão do kernel.

Aceleração de fluxo de rede

Até agora, eu mencionava que uma das poucas desvantagens do OpenWrt é que ele tem um desempenho menor de NAT do que a firmware proprietária. Isso devido a uma gambi^H^H^H^H^H^H^H^H^H^H um "mecanismo de acelaração de NAT em hardware" existente somente nas firmwares proprietárias. Bem, desenvolveram uma solução equivalente e aceita pela comunidade Linux, com alternativa de aceleração tanto em software puro como com auxĩlio de hardware. Blah, blah, blah... o que significa tudo isso? Bem, antes um roteador "normal", (aquele que você deve ter em casa e não os multi-ultra-dual-core), conseguia rotear WAN entre LAN algo entre 200 Mbps e 400 Mbps, mesmo com ambas sendo GigabitEthernet. Agora, com a aceleração, é possível ver taxas próximas a velocidade do "fio" (1000Mbps) como transferência de 940 Mbps, mesmo em roteadores mais simples.

Mas tem um grande porém.... só vale para os roteadores cujo algo já utilizem o kernel 4.14. E grande parte dos vendidos no Brasil com suporte ao OpenWrt usam ar71xx.

Mas pera aí. É sério isso Luiz? Você realmente acha que conseguir rotear acima de 200 Mbps com um roteador caseiro vai mudar a vida de alguém no Brasil? Bem, ainda não. Mas quem sabe no futuro próximo poderemos ter internet de algumas centenas de Mbps pagável por pessoas que ainda usam roteadores "normais" com OpenWrt. Enfim, o destaque vale mesmo pelo fato de não ser mais um ponto negativo.

Atualização do CAKE

Para quem não conhece, um algoritmo de escalonamento de pacotes é o cara que controla a(s) fila(s) de pacotes entrando e saindo. O CAKE é um desses e busca preservar a latência sempre baixa, sem necessidade de qualquer configuração além de ativá-lo. Na atualização, ele consegue lidar melhor com pacotes que chegam no seu roteador (vindos da internet). Na prática, é o que mais sentimos e o mais difícil de controlar.

Para quem usa o QoS no roteador, será uma atualização bem vinda.

Aumento do tamanho da firmware

Isso é um problema a cada nova versão. O normal é que novas versões de programas ocupem mais espaço. Isso vale para os programas do OpenWrt. Então, a vida já difícil de quem tinha um roteador com 4 MBytes de flash se tornará ainda pior. Podem ter casos de ser tão pequeno o espaço livre que não será possível preservar as configurações. Se isso ocorrer com você, é bom abrir um bug.

Para minimizar isso, foi criada uma variante tiny (ex: ar71xx/tiny em oposição ao ar71xx/generic) que preserva as funcionalidades mas remove os símbolos do kernel, poupando alguns sagrados kbytes. Então, seu roteador TL-WR740ND v1 ainda pode ser usado (eu uso!).

Wireguard

O Wireguard não é propriamente uma novidade desta versão. Porém, é nela que começa a aparecer o suporte para valer no OpenWrt. Para quem não conhece, o Wireguard é uma nova solução de VPN que busca ser muito mais simples do que as "padrão de mercado", como o IPSec (se conseguir, fuja disso mais rápido que puder) e OpenVPN. Quem já configurou qualquer uma dessas e se deparar com uma configuração do wireguard irá se perguntar: "OK, só isso? Não pode já estar funcionado". O wireguard é tão bem vindo que o Linus, que tem mais coisa para fazer, se meteu no desenvolvimento de rede do Linux para aclamá-lo. Teve até carta de senador gringo para o NIST para recomendar sua avaliação como alternativa às VPN existentes (IPSec e OpenVPN). Mas isso fica para outro artigo.

________________________________________

Parece pouca novidade e nada que me interessa. E então, devo atualizar? Provavelmente sim. A versão 15.05 chegou ao seu fim de vida e a 17.01 caminha para o mesmo destino. Sem atualização, fatidicamente você estará no futuro exposto a alguma vulnerabilidade. Se ela for explorável remotamente, ela será, nem que seja para minerar bitcoin no seu roteador. Mas meu roteador é muito lento para minerar bitcoin! Sim, mas ele também pode injetar o minerador nas páginas que você acessar e quem vai minerar será seu computador, celular, TV...

Minha recomendação é "se o hardware não é um limitador, atualize". Se seu roteador não aguenta a nova versão (por questão de espaço), é bom avaliar o que é menos ruim: comprar um novo roteador de R$ 100,00 ou manter seu roteador antigo?

No próximo artigo, algumas dicas do procedimento de atualização. No fundo, o dito para o 17.01 ainda vale.

Se pintar um problema, tem sempre o fórum deste blog. Até a próxima.

OpenWrt: Configurando IPv6 (6 anos depois)

2018-04-17T02:50:00.002-03:00

Mais um artigo da série sobre o OpenWrt/LEDE.

O que motivou iniciar o uso do OpenWrt não foi os inúmeros recursos a mais que você pode fazer com ele. O real motivador foi que eu queria usar IPv6 na minha rede. Escrevi sobre isso em 2012. Acho que cabe retomar o assunto.

Na época, o IPv6 no OpenWrt era opcional. As operadoras entregarem IPv6 era lenda urbana, quando não queriam te "vender" o pacote extra IPv6. O acesso IPv6 era coisa de universidade. A única alternativa era criar um túnel (lento) para um broker IPv6. De lá para cá, muita coisa mudou.

Hoje, todas as operadoras que se consideram minimamente significativas oferecem IPv6 a seus clientes. Então, se você não tem IPv6, já sabe o nível da sua operadora. As operadoras já estão com falta de IPv4 faz um tempo, tendo que apelar para técnicas como CGN (NAT na operadora) que, basicamente, coloca uma NAT na frente da sua NAT. O problema é que a sua NAT você tinha um certo nível de controle, podendo abrir/encaminhar portas. Já a NAT da operadora... Isso quebra um monte de coisas que iriam conectar na sua casa (ex: torrent, VPN, Câmera IP...). Se sua operadora tem que usar CGN, mas ao menos entrega IPv6, é a vida. Procure migrar suas coisas para IPv6. Se ela usa CGN mas não entrega IPv6... ela é incompetente. Procure trocar de operadora.

No mundo do OpenWrt, o IPv6 melhorou muito. Hoje em dia, ele vem autoconfigurado para IPv6. O normal é ele funcionando tão bem quanto IPv4, sem a necessidade de qualquer configuração. Não precisa de pacotes extras, ele simplesmente sai funcionando.

Vamos a um básico IPv6. Primeiro, o endereço. O IPv4 usava 32-bit, que dava um pouco mais de 4 bilhões de endereços (2^32). Deste tanto, tinha que tirar algumas faixas reservadas, um tanto para equipamentos intermediários, endereço de rede, broadcast. No fim, temos endereços para bem menos do que 4 bilhões de equipamentos. E com 7 bilhões de pessoas no planeta, isso era insuficiente. No IPv6, o pessoal exagerou e resolveu aumentar de 32-bit para 128-bit. Fica um trambolho deste tamanho:

2001:db8:85a3:8d3:1319:8a2e:370:7348

Cada conjunto separado por ":" tem 16-bit, ou 65536 variações. Com dois destes poderíamos colocar a internet IPv4 inteira (e temos 8 aqui). Como os números começaram a ficar grandes, resolveram usar notação hexadecimal, que inclui os algarismos normais e as letras de A até F. Isto permite usar endereços legíveis engraçadinhos. Caso tenha uma sequência de zeros, usa-se a notação "::", mas somente uma vez no endereço.

Existem variações para endereços especiais, como multicast, link-local, mas no caso geral, o endereço IPv6 pode ser dividido em duas partes, cada uma com 64-bit. No exemplo anterior, seriam as partes verdes e azul. A verde é seu prefixo de rede, que identifica uma rede IPv6 no mundo. A parte azul é o identificador da interface. Para fazer a analogia com algo que todos têm familiaridade, seria algo assim no IPv4 privado da sua rede atual:

192.168.3.131/24

Então, com IPv4 você normalmente trabalha com redes /24 com 254 endereços "livres". Com IPv6, no mínimo temos 18.446.744.073.709.551.616 (2^64). Para quê tudo isso? Bem, assim você pode usar o endereço MAC da sua placa (48-bit) e obter automaticamente um endereço sem chance de conflito. Esse é o método de obtenção de endereços sem estado (SLAAC). Funciona assim:

equipamento: olá! tem um roteador aí? Eu preciso de uma rede!

roteador: Oi, eu sou o roteador no endereço fe80::1234:1234:3214:1234. Eu ofereço o prefixo de rede 2001:db8:85a3:8d3::/64

E o equipamento começa a usar 2001:db8:85a3:8d3:1319:8a2e:370:7348 usando fe80::1234:1234:3214:1234 como roteador padrão. Sem mais nenhum passo. Sem nenhuma negociação ou confirmação.

Este endereço, apesar de parecer "aleatório", será sempre igual, claro, se mantido o prefixo de rede. Equipamentos mais simples (IoT) podem só funcionar desta forma. E o DNS? Esse pode vir pelo serviço RDNSS, que vem junto com a resposta do roteador. Mas nem todos os clientes e roteadores suportam isso.

E não tem DHCPv6? Tem sim. Ele funciona de uma forma bem parecida com DHCPv4, mas pode tanto gerar os endereços dos clientes da mesma forma que o SLAAC ou da forma tradicional do IPv4: alocando de uma faixa de endereços (que podem ser fixados).

O prefixo de rede ainda pode ser dividido em duas partes: prefixo de roteamento e um identificador de subrede. O prefixo de roteamento é o que identifica todas as redes gerenciadas pelo seu roteador. Então, qualquer rede "acessível globalmente" no seu roteador compartilha essa parte inicial. O que sobra até atingir os 64-bit é usado pelo seu roteador para subdividir a rede em múltiplas redes locais.

Vamos ao OpenWrt.

Ao ligar o OpenWrt, ele cria aleatoriamente um endereço de rede local (ULA). Sim, o recomendado é ser aleatório mesmo. Esse endereço é um /48 e sempre começa com "fd". Ex:

fdab:1234:1343::/48

Você pode ver (ou modificar) este endereço na aba "network/interfaces", lá no final. Isto seria equivalente a sua rede privada 192.168.1.0/24 do IPv4. Diferentemente do IPv4, eu não recomendo que mude este valor.

O OpenWrt usa o "prefixo de roteamento" fdab:1234:1343:: e adiciona um identificador de subrede para formar uma rede final, normalmente de tamanho /64, mas pode ser modificado pela opção "ip6assign". E de onde ele pega identificador de subrede? Do campo "ip6hint". Se não definido, ele usa zero. Para o endereço anterior, ficaria:

fdab:1234:1343::/64

Mas é igual? Não! Agora tem um monte de zeros até chegar ao /64. De 48 para 64 são 16-bit ou 4 algarismos/letras em hexadecimal. Seria igual a isso:

fdab:1234:1343:0000::/64

Onde o magenta é o identificador da subrede. Se ele fosse "12", o resultado seria:

fdab:1234:1343:0012::/64

Simples? Por enquanto estamos só na rede local. O DHCPv6 pode ser configurado no mesmo local onde era configurado o IPv4, ao final da edição de cada interface. Lá você pode configurar se o roteador se anunciará como roteador (para SLAAC), se terá DHCPv6 e qual modo de endereços será distribuído pelo DHCPv6: SLAAC, por atribuição ou ambos.

E como ficariam os endereços de rede? O OpenWrt normalmente usa o identificador de rede ::1 para si. Então, na subrede fdab:1234:1343:123A::/64, ele ficaria com:

fdab:1234:1343:0012::1/64

Mas o "::1" pode ser modificado pelo campo ip6ifaceid. E uma máquina na rede? Se ela tiver o endereço MAC 11:22:33:44:55:66, por SLAAC ela teria o endereço:

fdab:1234:1343:0012:1322:33ff:fe44:5566/64

Note que o MAC sofre uma pequena alteração, mas ele é visível no endereço. E se for por atribuição DHCPv6, será dinâmico (com relativa estabilidade) como no DHCPv4. E se eu quiser fixar? Assim como a interface tem o atributo "ip6ifaceid", a entrada DHCP onde você fixa o IPv4 terá um campo "hostid" (na interface WEB está como "IPv6-Suffix") onde você pode preencher o que quiser lá (até 64-bit ou 16 algarismos hexadecimais). Se for "cafe", o endereço ficaria:

fdab:1234:1343:0012::cafe/64

Pronto. Temos uma rede local que fala IPv6. Isto vai estar disponível em qualquer OpenWrt recente, mesmo que sua operadora não ofereça IPv6. Os endereços fd00::/8 não são (normalmente) roteáveis para a internet. Só devem ser usados dentro da sua rede doméstica ou corporativa.

Agora vamos falar com a Internet.

O básico de um roteador é ter uma interface WAN e uma ou mais LAN. Normalmente o endereço WAN IPv6 é obtido por DHCPv6 (ex: NetVirtua) ou por PPPoE/PPPoA (ex: Oi). Como é um protocolo diferente do IPv4, no OpenWrt é necessário usar uma segunda interface (ex: wan6) que utiliza o mesmo dispositivo físico da wan IPv4. Por padrão, ele já vem com uma wan6 configurada como DHCPv6, que resolve em grande parte dos casos.

O que muda do DHCPv4? Na requisição do DHCPv6, além de pedir um endereço para a interface WAN, existe um pedido de um campo adicional chamado de "prefixo de rede delegada" (Prefix Delegated - PD). Você receberá da sua operadora um endereço WAN para seu roteador e um prefixo de rede com endereços reais (globais) para distribuir dentro da sua rede. O tamanho do prefixo solicitado pode ser modificado pelo campo "reqprefix", mas as operadoras não vão respeitar mesmo. Você receberá algo como:

IPv6 WAN: 2804:14d:baba:1000::17d7/64

IPv6 prefixo delegado: 2804:14d:baba:1f00::/56

Se a WAN IPv6 utilizar endereço IP fixo, você pode informar a rede delegada manualmente.

O que o OpenWrt faz com isso? O IPv6 WAN é usado para a interface WAN. Ele pode ser, inclusive um /128. Já o prefixo delegado é distribuído para todas as LANs internas. Da mesma forma que ocorreu com a rede ULA, ele utilizará o prefixo roteado em conjunto com o identificador da subrede para criar prefixos de rede para cada rede interna. No exemplo, a operadora ofereceu um prefixo /56 (ex: Oi ADSL residencial), que permitiria subdividi-lo em 256 redes. É o suficiente para uma residência ou mesmo para um pequeno negócio.

( Bem, tem algumas operadoras que entregam apenas um /64 para seus clientes. Sim NetVirtua, estou apontando para você. Pode ser trauma da escassez de IPv4 mas não se justifica no mundo IPv6. Até a Oi, que normalmente não é usada como bom exemplo, oferece uma rede /56. Com uma rede /64, eu não tenho espaço para subdividir a rede em múltiplas redes LAN e ainda usar SLAAC. Isto quer dizer que não tenho como criar uma segunda LAN com IPv6. Mas quem precisa de duas LAN? Isso é coisa de empresa! Claro, o vizinho que eventualmente fez uma visita e precisou conectar na Wifi aqui em casa jamais irá enviar um vídeo por engano ao meu Chromecast, nem mesmo irá olhar sem querer na babá eletrônica... realmente a segunda rede é desnecessária. Não preciso dizer qual foi a resposta do Call Center da Net. Mas voltando... )

Com as redes do exemplo, a LAN do roteador passa a ter estes dois endereços:

fdab:1234:1343:0012::1/64

2804:14d:baba:1f12::1/64

E a máquina que tem o endereço MAC 11:22:33:44:55:66? Se usar tanto o SLAAC como o sufixo "cafe", teremos todos estes endereços configurados:

fdab:1234:1343:0012:1322:33ff:fe44:5566/64

fdab:1234:1343:0012::cafe/64

2804:14d:baba:1f12:1322:33ff:fe44:5566/64

2804:14d:baba:1f12::cafe/64

E para cada outra LAN no roteador, basta configurar o campo ip6hint dela com um identificador diferente das demais LAN e ela receberá seu cunhão de endereços automaticamente.

E se não tiver espaço para uma segunda LAN? O que posso fazer? E se minha operadora não entregar um prefixo delegado? Infelizmente, ainda temos a alternativa de usar NAT66 (NAT entre duas redes IPv6).

Beleza. Acabei de olhar a interface do meu computador e tem esses quatro endereços aí e mais um monte! Sim, temos ainda endereços usados apenas no contexto do enlace local (link-local), que começam com "fe80". Ele seria equivalente ao famigerado 169.254.0.0/24 do IPv4.

fe80::1322:33ff:fe44:5566/64

Este endereço normalmente nem responde aos serviços de rede normais. Ele é usado para as tarefas administrativas do IPv6, como encontrar um outro equipamento na mesma rede ou o seu roteador. É necessário.

Mas tenho muito mais endereços! Bem, o endereço MAC não é algo muito "mutável" nas máquinas. Como ele começou a fazer parte do endereço visível na internet, ficou fácil rastrear os equipamentos que usam SLAAC. Mesmo que você mude o prefixo, o final sempre será o mesmo. Com isso você obtem o MAC e individualiza o computador. Solução? Uma extensão de privacidade. Além de todos os endereços listados anteriormente, a máquina pode periodicamente criar novos endereços com o identificador de interface (parte verde) aleatória. Quando usada a extensão de privacidade, o endereço SLAAC fixo é usado para receber conexões que queiram se conectar no computador enquanto os endereços aleatórios são usados pelo computador para acessar serviços remotos. Depois de um tempo, o endereço aleatório é desativado e outro é criado. Com isso, o serviço remoto não tem como rastrear o equipamento apenas pelo endereço de origem. Se deixar um computador que usa a extensão de privacidade muito tempo ligado, é normal ver uma lista mais de uma dezena de endereços IPv6.

E tem mais assuntos IPv6? Tem! Firewall IPv6, NAT66 (sim, NAT para IPv6 as vezes é necessário), multihoming (duas WANs), VPN sobre IPv6, e assim por diante. Mas isso fica para outro artigo.

Se pintar uma dúvida, temos o fórum.

Até a próxima.

OpenWrt/LEDE: fazendo seus backups no roteador (e distribuindo-os): parte 3

2018-04-11T01:01:00.000-03:00

Mais um artigo da série sobre o OpenWrt/LEDE.

No primeiro artigo deste tema, comentei o que uma solução de backup deveria ter. Passei pela solução que usava anteriormente (crashplan) e uma brevíssima introdução aos recursos do borg. Depois apresentei a configuração do backup em um HD externo no seu roteador. Neste artigo, iremos implementar a sincronia entre repositórios.

Só relembrando, esse é o esquema do backup:

O computador roda o borg e copia os arquivos (amarelo) para um repositório no roteador. Esse repositório é acessado por CIFS e aponta para um HD externo conectado na USB. Em um segundo momento, um rsync sincroniza esse repositório com um destino remoto utilizando o rsync. O destino remoto também é um roteador com um HD externo conectado, mas poderia ser qualquer destino com suporte a rsync. A comunicação do rsync é feita dentro de uma VPN, que interliga o roteador de origem e destino do repositório.

Este artigo aborda a parte verde do diagrama.

Sincronizando repositórios

Já ouvi a estória do "eu tinha backup, mas perdi junto". Incêndio, roubo, descarga elétrica durante o backup, não são se preocupar em "não queimar" o HD externo do seu backup. E o backup parece ter um certo magnetismo que o atrai para próximo da fonte original da informação, em especial antes de eventos catastróficos.

Como já havia comentado na parte 1 deste assunto, distribuir geograficamente o backup de forma automatizada era um requisito. A opção foi utilizando o rsync sobre uma VPN, onde o repositório do backup, conectado no roteador (que sempre está ligado), é enviado lentamente para um outro armazenamento remoto, também conectado em outro roteador (que sempre está ligado).

A parte da VPN é assunto antigo. O rsync pode ser feito pelo SSH, com autenticação por chaves. Porém, isso exige um certo grau de confiança da ponta remota pois as mesmas chaves podem abrir uma sessão no roteador remoto. Outra opção é um serviço rsyncd. Apesar de não ter autenticação, você pode controlar pelo firewall e pela restrição do próprio rsyncd quem pode acessar esse serviço. Se somente o teu roteador puder conectar no roteador remoto, só você poderá apagar algo indevidamente.

No roteador que receberá a cópia:

roteador-remoto# opkg update

roteador-remoto# opkg install rsyncd

A configuração não foi UCIficada e deve ser feita diretamente em /etc/rsyncd.conf. Só adicionar:

/etc/rsyncd.conf:

(...)

[fulano@gmail.com]

path = /mnt/HD-externo-XYZ/backup/borg/fulano@gmail.com
read only = no
fake super = yes

O identificador fulano@gmail.com é arbitrário. Eu gosto de usá-lo pois o repositório normalmente terá mais de um cliente. E nada melhor do que o email para lembrar o nome do repositório.

Agora, basta ativar e disparar o serviço:

roteador-remoto# /etc/init.d/rsyncd enable

roteador-remoto# /etc/init.d/rsyncd start

Opcionalmente, se já estiver usando o xinetd (por exemplo, para o scanner na rede - SANE), pode também usar o xinetd ao invés do serviço rsyncd:

service rsync

{

disable = no

socket_type = stream

port = 873

protocol = tcp

wait = no

user = root

server = /usr/bin/rsync

server_args = --daemon

log_on_failure += USERID

}

E falta, agora, somente a rotina que envia do meu roteador-local para o roteador-remoto.

rsync --bwlimit=30k --partial --archive --delete --delay-updates --delete-after /mnt/HD-externo-abc/borg/ roteador-remoto::fulano@gmail.com/

E se usar por cima do SSH:

rsync --bwlimit=30k --partial --archive --delete --delay-updates --delete-after /mnt/HD-externo-abc/borg/ roteador-remoto:/mnt/HD-externo-XYZ/backup/borg/fulano@gmail.com/

A primeira opção --bwlimit limita a taxa de transferência para o rsync. Ajuste para sua realidade. Como eventualmente teremos múltiplos gigabytes para serem enviados, o processo pode durar dias. A recomendação é sempre deixar um tanto para outros fins. O --partial permite continuar o envio quando a conexão foi perdida. Eu gosto de usar o --delay-updates --delete-after para manter o repositório íntegro durante a cópia. Se espaço for um problema do outro lado e ele não aguentar armazenar a mais a diferença a ser enviada, pode usar o --inplace e --delete-before. E sempre, man é seu amigo.

Agora é só colocar na cron. Como o processo pode rodar "por dias", é importante que ele não volte a rodar se o rsync anterior ainda estiver em execução. Por isso, podemos melhorar o comando usando o comando "lock":

lock -n /tmp/rsync.lock && { bwlimit=30k --partial --archive --delete --delay-updates --delete-after /mnt/HD-externo-abc/borg/ roteador-remoto::fulano@gmail.com/; lock -u /tmp/rsync.lock; }

Se rodar novamente este comando enquanto a execução anterior ainda estiver em curso, você vai receber um:

Can't lock /tmp/rsync.lock

E, como esperado, não teremos dois rsync em execução.

No OpenWrt, não temos os /etc/cron.* que usamos no Linux. Sendo assim, temos que usar o bom e velho 'crontab -e'. Para rodar todos os dias 1 AM:

0 1 * * * lock -n /tmp/rsync.lock && { bwlimit=30k --partial --archive --delete --delay-updates --delete-after /mnt/HD-externo-abc/borg/ roteador-remoto::fulano@gmail.com/; lock -u /tmp/rsync.lock; }

Outra funcionalidade interessante é abortar o processo quando ele demorar muito tempo. Assim você pode manter a rotina apenas durante a madrugada. Todavia, isso só faz sentido se usar a opção "--partial". Bem, a partir deste ponto, a linha do comando vai ficar muito longa, mesmo por um costumas one-liner. É hora de fazer um script:

#!/bin/sh
# Sincroniza repositorio local com remoto
#
RSYNC_TIMEOUT=${1:?Informe o tempo maximo em segundos deste script}; shift
REPO_LOCAL=${1:?Informe o repositorio local}; shift
REPO_REMOTE=${1:?Informe o repositorio remoto}; shift
REPO_LOCK=/tmp/rsync-remote.lock

lock -n "$REPO_LOCK" || {
echo "Falha ao obter lock! Existe um rsync-backup rodando?" >&2
exit 1
}
trap "lock -u '$REPO_LOCK'" EXIT

rsync --archive --partial --delete --delay-updates --delete-after "$@" "$REPO_LOCAL" "$REPO_REMOTE" &
pid_rsync="$!"
(sleep $RSYNC_TIMEOUT; echo "Estouro de tempo ($RSYNC_TIMEOUT segundos)" >&2; kill -TERM $pid_rsync) &
pid_timeout="$!"
# Deveria ser kill -TERM -$pid_timeout... mas com o ash nao fuciona ainda
trap "lock -u '$REPO_LOCK'; kill -TERM $pid_timeout $pid_rsync 2>/dev/null" EXIT
wait $pid_rsync
err=$?
exit $err

Que ficaria na cron assim:

# Roda todos os dias 1AM por 6 horas (21600 segundos)
0 1 * * * /caminho/para/rsync-backup.sh 21600 /mnt/HD-externo-abc/borg/ roteador-remoto::fulano@gmail.com/

E é isso. Agora você já tem um mecanismo de sincronia dos backups.

Recuperando dados

Primeiro, vamos imaginar o cenário onde você precisa recuperar os dados do repositório remoto. Você deve ter perdido os dados principais e também seu backup local. Nesta situação, é provável que você nem tenha mais o seu computador para recuperar os dados.

A primeira alternativa de recuperação é ir fisicamente onde o backup remoto está e copiar o repositório. O melhor seria primeiro reconstruir seu repositório local e depois recuperar o que você quiser com calma a partir dele.

Se o acesso físico for complicado, você pode simplesmente reconstruir seu repositório local fazendo um rsync inverso, como origem o repositório remoto e destino um caminho local. Vai demorar mas funciona.

Por fim, se precisar apenas de uma ou outra coisa, eu recomendaria testar a montagem remota em cima de rsync, como em fuse-rsync. Não testei mas deve funcionar perfeitamente.

Ah, e não se esqueça que você sempre precisa ter acesso a chave ou a senha usada na criação do repositório. E isso sem depender do próprio backup ;-)

Se pintar uma dúvida, tem sempre o fórum deste blog. Até a próxima.

OpenWrt/LEDE: fazendo seus backups no roteador (e distribuindo-os): parte 2

2018-01-29T01:57:00.001-02:00

Mais um artigo da série sobre o OpenWrt/LEDE.

No artigo anterior, comentei o que uma solução de backup deveria ter. Passei pela solução que usava anteriormente (crashplan) e uma brevíssima introdução aos recursos do borg. Neste artigo, vamos configurar o repositório.

O esquema ficou desta forma:

O computador roda o borg e copia os arquivos (amarelo) para um repositório no roteador. Esse repositório é acessado por CIFS e aponta para um HD Externo conectado na USB. Em um segundo momento, um rsync sincroniza esse repositório com um destino remoto utilizando o rsync. O destino remoto também é um roteador com um HD Externo conectado, mas poderia ser qualquer destino com suporte a rsync. A comunicação do rsync é feita dentro de uma VPN, que interliga o roteador de origem e destino do repositório. Muito complicado? Nem tanto. Como diria Jack, "vamos por partes...".

Neste artigo vou abordar apenas a flecha vermelha. No próximo trato da verde.

Instalação

O primeiro passo para usar o borg é a instalação. A versão do repositório do ubuntu 17.10 é suficiente:

pc# apt install borgbackup

Ou baixe diretamente do projeto. Eu prefiro a segunda opção. Este é um arquivo "autosuficiente", só baixar, dar permissão de execução e usar.

Repositório

O destino do repositório será no roteador. Como não vou rodar o borg lá, terei que acessar o disco do roteador por um sistemas de arquivos em rede. Optei pelo C IFS (samba). No lado do cliente, eu gosto de usar o autofs:

pc# apt install autofs cifs-utils

Eu gosto de configurar o /cifs, que monta sob demanda compartilhamentos CIFS:

/etc/auto.master:

/cifs /etc/auto.smb --timeout=300

E dispare o serviço

pc# systemctl enable autofs

pc# systemctl start autofs

Seu roteador estará acessível em /cifs/router/<compartilhamento>/

Iniciando o repositório

Para criar um novo repositório, é só rodar:

pc# borg init /cifs/router/<compartilhamento>/borg

Os repositórios borg podem ser protegidos por uma chave. Para uso interativo, isso não é problema. Contudo, se o objetivo é fazer backup agendado, não será a melhor opção. O borg permite informar uma chave por variável ambiente. Crie um arquivo de senhas ou gere um aleatoriamente.

pc# mkdir -p /etc/borg

pc# openssl rand -base64 32 > /etc/borg/borg.key

pc# chmod 400 /etc/borg/borg.key

Eu pessoalmente prefiro senhas boas mas que possam ser decoradas. Mas gosto é gosto.

Você agora pode passar essa senha chamando o borg desta maneira:

pc# BORG_PASSCOMMAND="$(cat /etc/borg/borg.key)" borg ...

Ou também pode usar diretamente o BORG_PASSPHRASE com o conteúdo da senha:

pc# BORG_PASSPHRASE="naoconteparaninguem" borg ...

Fazendo backups

O backup é feito com uma chamada simples do borg. Um exemplo já passando a senha seria:

pc# BORG_PASSPHRASE="naoconteparaninguem" borg create /cifs/router/<compartilhamento>/borg /meu/dir1 /meudir2 ...

Não vou me estender nas diversas opções disponíveis. Porém, é indicado colocar isso em um script para facilitar a chamada.

Os backups no borg são rápidos e econômicos. Ele só copia as diferenças e faz isso de forma bem eficiente. Normalmente uma chamada de backup sem alteração é executada em menos de 30 segundos. Ele tem um cache local dos índices e um novo backup sem muitas alterações gera pouca carga sobre o repositório. Já que é tão barato, resolvi fazer uma vez por hora. A chamada do "borg create" foi colocada em um script em /etc/cron.hourly/meubackup. Quem quiser, alternativamente, pode editar a cron diretamente com 'crontab -e'.

Pronto! Temos uma rotina de backup!

Limpando o repositório

OK, tudo lindo e maravilhoso... mas vai ficar fazendo backup toda hora (literalmente) e nunca apagar nada? Bem, um novo backup sem alteração é bem econômico e fazer muitos deles realmente não é algo significativo. Porém, as diversas versões de arquivos alterados e apagados, e mesmo os metadados, eventualmente encheriam o disco. E, em alguns casos, eliminar permanentemente alguns dados pode ser salutar, em especial quando iniciar um novo relacionamento.

Para apagar, o borg pode executar o prune baseado em critérios como "mantenha todos os últimos backups desta semana, um backup por dia nos últimos 10 dias com backup, 6 backups semanais...". Eu, por exemplo, estou usando:

pc# BORG_PASSPHRASE="naoconteparaninguem" borg prune --keep-within 1d --keep-hourly 20 --keep-daily 30 --keep-weekly 53 --keep-yearly 20 /cifs/router/<compartilhamento>/borg

Pode parecer estranho pedir para manter todos os backups das últimas 24 horas, mas somente um backup por hora nas últimas 20 horas. Bem, como o computador nem sempre está ligado, os 20 backups horários podem ser mais antigos do que "todos os backups das últimas 24 horas". Tudo isso depende de cada caso.

Como esta operação pode demorar mais tempo do que um backup normal, eu rodo semanalmente. Contudo, fica a gosto do cliente.

No próximo artigo, a parte de sincronia remota do repositório. Se pintar uma dúvida, tem sempre o fórum deste blog.

Até a próxima!

LEDE renomeado para OpenWRT: projetos "reunificados"

2018-01-06T17:34:00.000-02:00

Mais um artigo da série sobre o OpenWrt/LEDE.

Faz quase um ano que postei sobre o lançamento do LEDE, um fork do projeto OpenWrt. Enfim, muita água rolou e agora temos novidades significativas. Mas o que aconteceu desde o lançamento do LEDE?

O surgimento do LEDE atraiu todos os desenvolvedores do OpenWrt. Ficou somente os desenvolvedores originas, "donos da marca" e da infraestrutura. Bem, como eles já não faziam grandes contribuições por algum tempo, o OpenWrt parou de ter um desenvolvimento significativo. Em suma, o OpenWrt mo-rré-u. O LEDE, em contrapartida, estava mais vibrante que o OpenWrt antes dele.

Então, o tempo passou, houveram conversas, e chegaram a um acordo. Os desenvolvedores do OpenWrt não tinham muito o que barganhar além do nome. Por uma série de votações, ficou decido que:

Os desenvolvedores remanescentes do OpenWrt ganhariam acesso de escrita ao LEDE, se tornando efetivamente desenvolvedores do projeto (por meio de votação como para qualquer novo desenvolvedor);
O código usado seria do LEDE, com eventuais melhorias exclusivas do OpenWrt sendo submetidas para avaliação, como qualquer outro patch (bem, sendo GPL, qualquer um já poderia ter feito isso sem pedir autorização);
Mantém-se as regras do projeto LEDE;
O OpenWrt CC está, na prática, abandonado, sendo recomendado o uso do LEDE 17.04.x;
Todos os direitos do OpenWrt e do LEDE foram doados para uma entidade sem fins lucrativos isenta, para não ter mais um "dono da bola";
O nome do projeto LEDE será alterado para OpenWrt.

Este último ponto, sobre o nome, foi polêmico. Não houve uma maioria absoluta mas uma votação equilibrada entre: voltar ao OpenWrt, manter o LEDE e posição neutra. Por poucos votos (acho que foi um), ganhou a volta ao nome OpenWrt.

E o que muda de agora em diante? O LEDE já usa o nome OpenWrt na sua versão em desenvolvimento. A infraestrutura do LEDE deve assumir o domínio do openwrt.org. Os servidores antigos do OpenWrt serão absorvidos. A próxima versão do LEDE será chamada OpenWrt e o nome LEDE deve desaparecer com o tempo.

Falta ainda decidir outros pontos até o lançamento da próxima versão estável (nos próximos meses) como a solução de controle de bugs, fórum e wiki.

Resumão: O OpenWrt de antes mo-rré-u. LEDE foi renomeado para OpenWrt. O LEDE ganhou uns servidores e três desenvolvedores.

O lado bom é que os usuários do OpenWrt CC nem irão notar que mudaram de projeto. Quando a nova versão do LEDE...,digo, OpenWrt for lançada, será que nem uma nova versão do OpenWrt.

Até a próxima!

OpenWrt/LEDE: fazendo seus backups no roteador (e distribuindo-os): parte 1

2018-01-04T02:28:00.000-02:00

Mais um artigo da série sobre o OpenWrt/LEDE.

Neste artigo vou mostrar a estrutura de backup que, com o auxílio de roteadores OpenWRT/LEDE, permite o backup de arquivos na rede e o envio desse backup de forma eficiente para pontos remotos sem a necessidade de deixar o computador ligado. Como vai ficar muito longo, primeiro vou levantar os requisitos e comentar a solução selecionada. Em um segundo artigo mostro as configurações efetuadas.

Costumo dizer "não adianta rezar, só backup salva". Todo mundo sabe que é preciso fazer as cópias de segurança, que são importantes, etc, mas poucos realmente o fazem. Mesmo os "entendidos" não fazem backup por uma simples razão: dá trabalho e é chato.

Um bom backup é feito de forma automatizada. Na maioria dos casos, só vamos lembrar dele quando precisar recuperar algo. E surpresa? Não tinha o backup!

Um bom backup não é uma simples cópia. Um bom backup deve ter versões, pois você pode levar um tempo para ver em algum momento sumiram suas fotos. Se tiver só uma cópia e ela foi feito depois do problema, não tem o que recuperar.

Um bom backup deve ser geograficamente distribuído. Mas precisa? Pense que se alguém for roubar sua casa, ele pode querer levar aquele HD externo junto com o seu computador. Pode ocorrer um pico de tensão e queimar o HD e o computador enquanto o backup era feito. Pode pegar fogo na sala onde ambos estão. Preferencialmente, nunca deixe todas as suas cópias no mesmo local. Vai copiar em um HD externo? Use dois, de forma intercalada e não deixe as duas cópias e o seu computador juntos. E dizem que sou paranoico.

Como os backups podem estar afastados do seu controle (geograficamente distribuído), um bom backup é cifrado ("criptografado"). Não precisa ser algo para enfrentar a NSA, mas algo que o custo para quebrar seja maior que o valor de seus dados. Não precisa ser muito chato neste ponto: uma senha em texto plano pode cifrar os backups e este arquivo pode ficar aberto no seu computador. Afinal, se alguém roubar essa senha no seu computador, ele vai poder abrir os arquivos no backup, que ele já teve acesso para poder ler o arquivo de senhas.

Principalmente, um bom backup deve ser recuperável. De nada adianta fazer o backup e descobrir que você não pode recuperá-lo. Ele deve, no mínimo estar íntegro.

Como posso fazer tudo isso? Pague por um serviço de backup na nuvem. Ou tenha um pouco mais de trabalho e faça você mesmo. Neste artigo vou mostrar a infraestrutura que montei para fazer backups de forma a oferecer esses recursos com o mínimo de custo computacional e de forma mais automatizada possível.

Eu usei por anos o Code42 Crashplan. Porém, eles abandonaram a versão gratuita, que permitia o backup distribuído entre amigos. Ele funcionava surpreendentemente bem, fazendo o backup de forma oportuna tanto no meu roteador (montado por CIFS) como nos meus amigos remotos. O problema era ter que deixar o computador ligado por horas (ou dias) para enviar um novo lote de fotos. Era um desperdício de energia e vida-útil do computador. A parte mais triste era que o backup já estava disponível 24/7 em um disco conectado no roteador. Só não tinha como copiar para o local remoto. O Crashplan foi desenvolvido em Java e não tinha a menor condição de rodar em um roteador com 64 MBytes de RAM.

A sincronia dos repositórios de backup com o ponto remoto também poderia ser feita usando o rsync. Contudo, o formato do repositório de backup mudava tanto a cada novo backup que o volume de dados a ser copiado superava em muito os novos arquivos salvos. A solução, em tempos e tempos, era fisicamente levar um dos repositórios ao encontro do outro e copiar localmente os arquivos (mesmo com rsync e USB 3.0, levava horas).

Então, além dos que se espera de um bom backup, uma solução ideal deveria enviar os arquivos de forma minimamente eficiente para o roteador (ex: CIFS, SFTP). Alternativamente, também poderia ser viável utilizar um agente da solução diretamente no roteador. Todavia, portar novos programas para o ambiente do roteador nem sempre é possível.

O envio dos dados ao repositório remoto também era um requisito importante. Eu realmente queria evitar o computador ligado para enviar dados que já estão no roteador. A solução de backup, então, deve facilitar a replicação. Isto pode ser obtido se o formato do repositório for eficientemente sincronizável por rsync. Outra solução seria com o agente rodando no roteador, que dificilmente teria sucesso pelas restrições do roteador.

Nas pesquisas por uma solução de backup, encontrei o borg. Ele está disponível em algumas distribuições e também em um arquivo autossuficiente. Tem uma arquitetura bem simples. Nem configuração existe no computador. Você apenas aponta para o repositório e manda uma série de caminhos. É um software livre, que vai evitar o mesmo problema de abandono do Crashplan. Até tem uma interface web, mas realmente, estou mais interessado na linha de comando. Uma parte importante do borg é a estrutura do repositório de backup. Os dados são salvos em blocos deduplicados no repositório e um "backup" referência uma série de blocos que formam a estrutura de diretório. Novos backups só enviam a diferença. E os backups não sobrescrevem dados antigos. Assim, ele é excelente para ser sincronizado usando rsync! A impressão que toda a estrutura do repositório foi pensado com esse propósito.

A única limitação é que você deve ter um repositório por máquina. O borg guarda um cache dos blocos já copiados para agilizar novos backups. Esse cache é validado antes de fazer o backup. Se os metadados do repositórios estiverem mais novos, o cache é invalidado. Com duas máquinas usando o mesmo repositório, toda vez que a outra fizer o backup, o próximo backup não utilizará o cache e será bem mais lento pois terá que baixar todos os metadados do repositório. Mas isso não foi um limitador para meu uso.

No próximo artigo, vamos direto para a configuração do borg utilizando o roteador como destino e sincronizador de backups. Até a próxima!

Se pintar uma dúvida, tem sempre o fórum deste blog.

OpenWrt/LEDE: sane-backends 1.0.27 e hplip submetido ao repositório oficial

2017-05-31T03:55:00.000-03:00

Mais um artigo da série sobre o OpenWrt/LEDE.

Faz longos 2 anos desde a última atualização do sane-backends. Enfim, lançaram uma nova versão: 1.0.27. Se notar a falta da 1.0.26, ela não existiu mesmo.

Mudou algo? Sim, bugs, falhas de segurança, melhorias diversas. Nada de grande nota. Alguns dos patches do pacote também foram aceitos no projeto, reduzindo o meu trabalho de mantê-lo.

As instruções para instalação continuam as mesmas. Com a diferença que o repositório para o LEDE está em http://luizluca.github.io/lede/. Quem já está com o pacote instalado e quer somente atualizar, basta adicionar o repositório (veja no atalho anterior) e trocar o install por upgrade.

router# opkg list-upgradable | grep sane
router# opkg upgrade <os pacotes do sane listados anteriormente)

Por sinal, sempre é bom observar os pacotes atualizáveis pelo "opkg list-upgradable". Normalmente são só correções de bugs (em especial, de falhas de segurança). Para pacotes instalados depois da gravação da firmware, não deve dar problema. Para os que já estavam na firmware, tem que ver se terá espaço livre para instalá-los.

Para quem não está com pressa, a próxima versão do OpenWrt/LEDE já terá a versão atualizada sem a necessidade de adicionar o meu repositório.

Outra novidade importante é que submeti o hplip ao repositório oficial. O entrave até agora era a falta do cups, que ficou sem mantenedor desde a versão OpenWrt CC. Eu criei um pequeno pacote libcups apenas para gerar as bibliotecas necessárias para o SANE compilar. Se for aceito, vai simplificar bastante a instalação do hplip.

Se pintar um problema, tem sempre o fórum deste blog. Até a próxima.

OpenWRT/LEDE: Capturando pacotes de dentro do roteador

2017-05-21T01:54:00.001-03:00

Mais um artigo da série sobre o OpenWRT/LEDE.

Algumas vezes já me perguntaram o que deveria aprender para ser um bom administrador de redes. A resposta é sempre a mesma: "Várias coisas, mas principalmente o Wireshark".

O Wireshark é uma excelente ferramenta de diagnóstico e de estudo. Eu normalmente recomendo que qualquer bom administrador de redes deve entender todos os campos até a camada do TCP/UDP/ICMP e boa parte dos protocolos mais usados como DHCP (bootp), DNS, HTTP. Se entender para que cada campo serve, implicitamente vai conhecer quase tudo que precisa.

Além, claro, de capturar pacotes, o wireshark tem diversas ferramentas de análise excelentes para diagnósticos diversos (ver nota [1] no fim do artigo). Ele próprio também faz diversas validações de protocolos conhecidos. Perdi a conta da quantidade de problemas que o próprio wireshark informou. Bastou capturar pacotes, abrir no wireshark e ele já mostrava o pacote com uma cor diferente e uma bela mensagem informando o problema.

Qualquer coisa que eu falar além sobre os recursos do wireshark será superficial demais para ser útil. Então, vamos ao tema propriamente dito deste artigo. Os melhores (e alguns dos ruins também) permitem que você capture de alguma forma o tráfego que passa nas suas interfaces. E o OpenWRT/LEDE? Bem, ele não tem uma forma padrão de fazer isso pois não precisa.

Por ser simplesmente um Linux, existem diversas formas de fazer essa captura de forma simples. Se existir uma unidade de armazenamento no roteador, pode fazer a captura em arquivo e analisar depois. Mas se quiser fazer "ao vivo", pode usar o recurso de pipes. A que eu mais gosto é usando um SSH para rodar o tcpdump no roteador e, por pipe, fazer um wireshark local ler os pacotes enviados pela entrada padrão. Parece complexo mas é só uma linha:

$ ssh root@router tcpdump -U -w - -s0 -i eth0.2 | wireshark -i - -k

A eth0.2 é a interface que quero capturar. Poderia ser outra como a br-lan ou mesmo any para pegar pacotes de todas as redes. Só tome cuidado de excluir o próprio SSH da captura para não criar um processo retroalimentado: "um pacote qualquer capturado é enviado por SSH que é um pacote qualquer e novamente capturado...". Então, use os filtros pcap como argumento do tcpdump para excluir, no mínimo, o SSH da captura (se ele estiver utilizando uma interface capturada). Ex:

$ ssh root@router tcpdump -U -w - -s0 -i any not port 22 | wireshark -i - -k

Ou:

$ ssh root@router tcpdump -U -w - -s0 -i any not host oip.do.meu.pc | wireshark -i - -k

Ah, é preciso antes de tudo instalar o tcpdump no roteador. Recomendo o pacote tcpdump-mini, que deve atender as necessidades básicas para capturar pacotes para análise no wireshark.

Isso vale também para capturar pacotes de servidores remotos que não têm wireshark (e nem deveriam), mas normalmente têm o tcpdump. Só trocar no comando o "router" para o nome do servidor e pode reaproveitar a dica.

Tunelar pelo SSH pode não ser a forma mais eficiente de fazer essa captura mas é a mais simples. Casos especiais onde o excesso de tráfego e os restritos recursos do roteador não aguentarem o trabalho, pode-se pensar em enviar os pacotes por netcat e sem criptografia. Mais inseguro, complicado mas bem mais leve para o roteador. Mas casos especiais são especiais e fica para outra oportunidade.

Alguma dúvida? Criei um fórum para o blog e vou criar um tópico para cada novo artigo.

Até a próxima!

[1] : na verdade, eu nem gosto de capturar pacotes diretamente com o wireshark pois a captura de pacotes exige privilégios especiais, que normalmente são supridos rodando a captura como root. Entretanto, como qualquer software, o wireshark é passível de vulnerabilidades. Um atacante que conheça uma delas pode injetar pacotes que a exploram em qualquer interface que ele tenha acesso, mesmo em uma insegura como a entrada da internet. Se um administrador capturar esse pacotes com o wireshark, ele processará o pacote malicioso e o atacante tomará conta do wireshark. Se o wireshark estiver rodando como root, o atacante rodará o código malicioso com os acessos de root na máquina atual. Então, procurem não rodar o wireshark como root e, na dúvida, use-o com captura remota e rode-o dentro de uma máquina virtual descartável sem acessos especiais.

OpenWRT/LEDE: Debugando código dentro do roteador (e corrigindo bugs)

2017-03-16T01:59:00.000-03:00

Mais um artigo da série OpenWRT/LEDE.

Fazer o debug de um programa muda a forma de desenvolvimento de um código. É imensamente melhor do que usar printf ao longo do código. Você pode ver os valores de qualquer variável, adicionar paradas condicionais, ver onde ele engasgou, etc. Para tudo isto, basta compilar seu código com os símbolos de debug, acesso ao código fonte (ajuda) e um debugger.

Uma das coisas que eu acho fantástico no mundo Linux é, diante de um problema, instalar os símbolos, código fonte e disparar um debugger. Isto com o processo rodado! Apesar dos programas instalados não conterem os símbolos, normalmente a distribuição fornece estes símbolos em um pacote a parte. Eu parto de um processo problemático em execução para um passo a passo dentro do código em poucos minutos. Fantástico!

Agora voltamos ao tema do artigo: como posso "debugar" dentro do OpenWRT/LEDE? Temos os símbolos nos executáveis? Não, são removidos antes de serem empacotados pelo sstrip. Mesmo que não fossem, normalmente você não teria espaço no roteador para instalar um executável com os símbolos de debug e mais o código fonte (ao menos que tenha expandido o disco com uma unidade externa). O gdb seria até pequeno, mas é sem símbolos e o fonte ele não tem muita utilidade. Mesmo se tivesse tudo isso, ainda debugar pelo gdb remotamente não é a forma mais amigável para este trabalho. Para coisas maiores, uma interface gráfica pode deixar o trabalho mais agradável.

Felizmente o OpenWRT/LEDE já está preparado para esta interação. Vamos tomar como exemplo o sane-backends, pacote que mantenho no OpenWRT/LEDE. Ele estava com um comportamento engraçado. O scanner aparecia na listagem mas sempre falhava ao escanear. Rodando localmente um escaneamento, eu obtinha:

root@router.lan3:~# scanimage >/dev/null
Trace/breakpoint trap

Parei o xinetd (que estava aguardando pelos pedidos do saned) e rodei o saned em modo debug. Novamente, o famigerado erro:

root@router.lan3:~# saned -d 128

[saned] main: starting debug mode (level 2)

[saned] saned (AF-indep+IPv6) from sane-backends 1.0.25 starting up

[saned] do_bindings: [0] bind failed: Address in use

[saned] check_host: access by remote host: ::ffff:192.168.3.20

[saned] init: access granted to luizluca@::ffff:192.168.3.20

Trace/breakpoint trap

Não fui apresentado, mas pelo nome, parece algo explicitamente introduzido. Alguma verificação falhou e abortou o programa. Sem mais informações por meio de mensagens, resta o debug do código.

O primeiro passo é ter os fontes e os códigos compilados. Provavelmente tudo isso se aplica caso opte por usar o SDK, mas vou, a princípio considerar que você está usando a árvore completa do projeto. Você precisa dos fontes e configurar o ambiente para compilar, ao menos, o sane-backend. Esta preparação já foi feita em outro artigo sobre compilação a partir dos fontes.

No roteador, eu irei debugar o programa saned, que não contém informações de debug. No pacote, ele é bem reduzido (menos que 33 kbytes):

$ tar --to-stdout -xzf bin/packages/mips_24kc/packages/sane-daemon_1.0.25-2_mips_24kc.ipk ./data.tar.gz | tar tzv ./usr/sbin/saned

-rwxr-xr-x root/root 32900 2017-03-12 22:40 ./usr/sbin/saned

Porém, antes de ser limpo pelo sstrip, ele tinha:

$ stat -c "%A %U %G %y %s %n" staging_dir/target-mips_24kc_musl-1.1.16/root-ar71xx/usr/sbin/saned
-rwxr-xr-x luizluca deluca 2017-03-12 22:40:49.510354194 -0300 44200 staging_dir/target-mips_24kc_musl-1.1.16/root-ar71xx/usr/sbin/saned

Agora vamos recompilar o pacote com os símbolos. Você pode fazer isso adicionando a opção no menuconfig para incluir os símbolo de debug em toda a árvore. Eu prefiro adicionar pontualmente os símbolos em alguns pacotes. Para isto, basta incluir a configuração extra na chamada do make:

$ make -j5 package/sane-backends/{clean,compile} CONFIG_DEBUG=y

Adicione ainda um V=s se quiser ver muitas letrinhas passando (ou precisar resolver problemas de compilação). Se fizer, observe um -g3 a mais nos argumentos do gcc.

O resultado é um executável relativamente maior:

$ stat -c "%A %U %G %y %s %n" staging_dir/target-mips_24kc_musl-1.1.16/root-ar71xx/usr/sbin/saned -rwxr-xr-x luizluca deluca 2017-03-12 23:56:52.157169597 -0300 188296 staging_dir/target-mips_24kc_musl-1.1.16/root-ar71xx/usr/sbin/saned

Mas o ipkg continua exatamente igual, pois os símbolos ainda foram removidos antes do empacotamento.

No meu caso, uso o driver hplip. Então, incluí em todo o processo anterior este pacote. Além de adicionar no menuconfig, o make ficou assim:

$ make -j5 package/{sane-backends,hplip}/clean package/{sane-backends,hplip}/compile CONFIG_DEBUG=y

Tudo pronto, agora vamos ao roteador. Vou instalar o gdbserver. Como o nome já diz, é um servidor do gdb, permitindo que um gdb na minha máquina use um executável rodando em uma máquina remota.

root@router.lan3:~# opkg install gdbserver

E agora, repito o comando do saned mas pelo gdbserver:

root@router.lan3:~# gdbserver :9000 /usr/sbin/saned -d 128Process /usr/sbin/saned created; pid = 4391Listening on port 9000

A princípio, ele inicia o processo parado, aguardando a conexão do gdb e sua autorização para continuar. No lado do computador, o OpenWRT/LEDE já fornece um "facilitador" para configurar o gdb remoto:

$ ./scripts/remote-gdb router:9000 staging_dir/target-mips_24kc_musl-1.1.16/root-ar71xx/usr/sbin/saned

Pronto! Estou com o debugger na mão. Peço ao gdb para parar ao receber qualquer sinal ("catch signal all"). Depois, libero a execução ("cont") até chegar em algo interessante.

Thread 1 "saned" hit Catchpoint 1 (signal SIGTRAP), memcpy (__n=270, __os=0x77dc3a76 <ms+770086>, __od=0x77dc3a74 <ms+770084>) at /home/luizluca/prog-local/lede/17.01/staging_dir/toolchain-mips_24kc_gcc-5.4.0_musl-1.1.16/include/fortify/string.h:4848 __builtin_trap();

(gdb) bt#0 memcpy (__n=270, __os=0x77dc3a76 <ms+770086>, __od=0x77dc3a74 <ms+770084>) at /home/luizluca/prog-local/lede/17.01/staging_dir/toolchain-mips_24kc_gcc-5.4.0_musl-1.1.16/include/fortify/string.h:48#1 device_id (fd=1, buffer=0x77dc3a74 <ms+770084> "\001\020MFG:HP;MDL:Officejet J4660 series;CMD:MLC,PCL,PML,DW-PCL,DESKJET,DYN;1284.4DL:4d,4e,1;CLS:PRINTER;DES:CB786A;SN:BR145GF09J052W;S:038000C484001021002c1f0005cc2d8002b;J:", ' ' <repete 20 vezes>, ";Z:0102,050"..., size=1024) at io/hpmud/musb.c:773#2 0x77cbe5cd in musb_open (pd=<optimized out>) at io/hpmud/musb.c:1160#3 0x77cb8067 in hpmud_open_device (uri=<optimized out>, iomode=HPMUD_DOT4_MODE, dd=0x41b0a4) at io/hpmud/hpmud.c:539#4 0x77ebbc51 in sclpml_open (device=0x418a96 "/usb/Officejet_J4660_series?serial=BR145GF09J052W", pHandle=0x7ffffaf4) at scan/sane/sclpml.c:2016#5 0x77eb02f7 in sane_hpaio_open (devicename=0x418a96 "/usb/Officejet_J4660_series?serial=BR145GF09J052W", pHandle=0x7ffffaf4) at scan/sane/hpaio.c:267#6 0x77f3f673 in sane_dll_open (full_name=<optimized out>, meta_handle=0x0) at dll.c:1201#7 0x77f31e97 in sane_open (name=<optimized out>, h=<optimized out>) at dll-s.c:23#8 0x00403391 in process_request (w=0x418198 <wire>) at saned.c:1916#9 0x00403a99 in handle_connection (fd=<optimized out>) at saned.c:2283#10 0x00402031 in run_standalone (argv=<optimized out>, argc=3) at saned.c:3167#11 main (argc=<optimized out>, argv=<optimized out>) at saned.c:3345

Hum... fortify... O LEDE introduziu opções de compilação que restringem alguns comportamentos inseguros (_FORTITY_SOURCE), "fortificando" o programa contra ataques. Pela pilha, isso foi dentro do hplip. Acho que ele tem algum problema...

A chamada em questão foi em io/hpmud/musb.c, linha 773:

771 if (len > 2)

772 len -= 2;

773 memcpy(buffer, buffer+2, len); /* remove length */

774 buffer[len]=0;

775 DBG("read actual device_id successfully fd=%d len=%d\n", fd, len);

Opa! Copiando o buffer sobre ele mesmo para tirar os dois primeiros bytes? OK, mas não usando memcpy! Muito feio! Isto nunca era para dar certo... O memcpy simplesmente copia de um lado para outro, desconsiderando sobreposição. Isto quer dizer, pode copiar do começo ao fim (ou o inverso), em blocos de vários bytes, etc. Foi sorte ter funcionado até agora (e funcionou?). A alternativa correta é o memmove, que verifica possíveis sobreposições e decide se copia de trás para frente, ou do início ao fim. Caso não tenha sobreposições, simplesmente chama o memcpy. E claro que temos sobreposições aqui!

Vamos tentar a última versão 3.16.11 do hplip? Não, ainda está lá o memcpy. Vamos precisar fazer um patch.

A melhor forma de trabalhar com patches dos programas empacotados no OpenWRT/LEDE é pelo quilt. Ele gerencia os patches de forma menos dolorida, em especial para atualizar os endereços depois de uma mudança de versão, onde os "hunks" funcionaram. Como acabei de atualizar a versão do hplip, devem ocorrer mudanças nos fontes e os patches existentes precisam ser atualizados:

$ make package/hplip/{clean,prepare} QUILT=y
$ cd build_dir/target-mips_24kc_musl-1.1.16/hplip-3.16.11
$ quilt push
Aplicando caminho 010-libusb_fix.patch
patching file configure.in
Hunk #1 succeeded at 561 (offset 38 lines).
Agora no caminho 010-libusb_fix.patch

$ quilt refresh # atualizar o endereço do patch
Patch atualizado 010-libusb_fix.patch

Tudo certo até aqui. Patch atualizado sem esforço.

$ quilt push
Aplicando caminho 020-remove_cups_dep_on_scan.patch
patching file scan/sane/hpaio.c
Hunk #2 FAILED at 172.
Hunk #3 FAILED at 232.
Hunk #4 FAILED at 259.
3 out of 4 hunks FAILED -- rejects in file scan/sane/hpaio.c
patching file Makefile.am
Hunk #1 succeeded at 60 with fuzz 1 (offset 1 line).
Caminho 020-remove_cups_dep_on_scan.patch não aplica (force com -f)

Hum... conflito. Preciso intervir manualmente.

$ quilt push -fAplicando caminho 020-remove_cups_dep_on_scan.patchpatching file scan/sane/hpaio.cHunk #2 FAILED at 172.Hunk #3 FAILED at 232.Hunk #4 FAILED at 259.3 out of 4 hunks FAILED -- saving rejects to file scan/sane/hpaio.c.rejpatching file Makefile.amHunk #1 succeeded at 60 with fuzz 1 (offset 1 line).Caminho 020-remove_cups_dep_on_scan.patch aplicado (forçado; necessita ser atualizado)
$ quilt edit scan/sane/hpaio.c<faz a mágica para resolver o conflito...>$ quilt refresh

Agora vamos, enfim, fazer o novo patch:

$ quilt new 030-replace_unsafe_memcpy_with_memmove.patch$ quilt edit io/hpmud/musb.c<troca o memcpy por memmove>$ quilt refresh

De volta a raiz do projeto, pedimos que ele atualize os patches:

make package/hplip/update QUILT=y

E, por fim, limpar e recompilar:

make package/hplip/{clean,compile} CONFIG_DEBUG=y

Tudo compilado, só copiar, instalar e testar

$ scp bin/packages/mips_24kc/packages/hplip-* root@router:/tmp

root@router.lan3:~# opkg install /tmp/*hplip*

Upgrading hplip-common on root from 3.15.7-1 to 3.16.11-1...

Upgrading hplip-sane on root from 3.15.7-1 to 3.16.11-1...

Configuring hplip-common.

Configuring hplip-sane.
root@router.lan3:~#

E...

Infelizmente, o "funcionar" é não mostram uma mensagem de erro e não abortar o processo. Não faz muito sentido colar a saída.

Agora, para a cereja do bolo, bug submetido ao hplip.

Até a próxima. Happy Hacking!

OpenWRT/LEDE: Compilando a partir dos fontes

2017-03-12T23:41:00.000-03:00

Mais um artigo da série OpenWRT/LEDE.

Dificilmente alguém vai precisar compilar o seu sistema operacional. Isto se aplica também aos ambientes embarcados. O OpenWRT/LEDE fornece o acréscimo de programas por pacotes, a personalização dos pacotes de uma firmware, ou mesmo um ambiente de desenvolvimento para compilar pacotes individuais. Tudo isso evita em muito a necessidade de recompilar todo o ambiente. Todavia, às vezes é inevitável.

Sempre que a mudança não é em "um pacote", vai precisar recompilar a árvore. Mudança de um parâmetro do kernel? Parâmetro do gerenciador de boot? Alguma outra coisa? Pode se preparar para recompilar tudo. E tudo é bastante coisa. O ambiente não só recompila o que vai no roteador mas compiladores, ligadores, ferramentas de geração de firmware, sistema de arquivos, etc. Tudo para ser o mais independente possível do sistema operacional onde está sendo compilado.

Como eu começo? Primeiro precisa de algumas ferramentas básicas, como o git, o gcc (para compilar o gcc do OpenWRT/LEDE, o make e algumas bibliotecas de desenvolvimento para compilar o menuconfig. Já existem algumas linhas de comando prontas para instalar estes requisitos no site do LEDE. Vale a olhada. Depois, só baixar os fontes. Vou pegar o atual ramo estável do LEDE:

git clone --branch lede-17.01 https://github.com/lede-project/source.git

E depois configurar o ambiente:

make menuconfig

No menuconfig, você pode configurar todo seu ambiente. Normalmente você terá que configurar, ao menos, o alvo (target) e, preferencialmente, o modelo do roteador (por padrão, ele gera firmware para todos!). Este é o local para adicionar os pacotes. A simbologia é:

[*] significa que o pacote estará na firmware gerada ou uma opção foi selecionada;
[M] significa que o pacote será gerado (ipk) mas não estará na firmware;
[ ] significa que o pacote não será compilado ou opção não selecionada.

Saindo e salvando, basta compilar:

make

Ou, se tiver processadores sobrando, deixar o make usar diversos processadores:

make -j9

Não achei no menu um pacote! Busque apertando "/" no menuconfig. Ainda não o Luci! A maioria dos pacotes estão nos feeds adicionais, por padrão sem pacotes incluídos. Para incluir o "meu-pacote-querido":

./scripts/feeds update
./scripts/feeds install meu-pacote-querido

E ele aparecerá no menu (previamente ainda não selecionado).

Ao terminar o processo do make, sua firmware estará em:

bin/targets/<alvo configurado>/generic/

Os pacotes estarão em:

bin/targets/<alvo configurado>/generic/packages/ (para os específicos deste alvo)
bin/packages/<arquitetura>/luci (para pacotes da arquitetura que o <alvo configurado> pertence)

Você está pronto para se divertir. Só gravar a nova firmware ou copiar e instalar os novos pacotes.

Quer mudar algo depois? Mexer em um pacote? As receitas estarão em packages ou em feeds. Se mudar um pacote, como o sane-backends, pode recompilá-lo individualmente:

make package/meu-pacote-querido/compile

Ou rodar simplesmente o make geral e deixar ele encontrar o que falta fazer (vai demorar mais). Se tiver problemas, pode mostrar as informações da compilação:

make package/meu-pacote-querido/compile V=s

É isso pessoal. Espero que esta informação ajude nos primeiros passos de desenvolvimento do OpenWRT/LEDE. Quem sabe não ajude a revelar um novo desenvolvedor para o projeto?

Happy hacking!

OpenWRT/LEDE: atualizando para LEDE 17.01.0

2017-03-02T22:21:00.000-03:00

Mais um artigo da série sobre o OpenWRT/LEDE.

Como citei no post anterior, o sucessor do OpenWRT é o LEDE. E este acaba de lançar a sua primeira versão: 17.01.0.

Sim, este artigo repete diversos pontos do artigo de atualização anterior. Afinal, apesar da mudança no nome, ainda é a mesma base.

96,72% dos problemas com instalação/atualização com LEDE que ajudo é em relação a escolha incorreta da imagem da firmware. Como sempre, recomendo a versão squashfs, que possui modo de recuperação. Pegue o arquivo no download da última versão estável e nunca em um endereço qualquer, mesmo que seja na wiki do OpenWRT/LEDE. Normalmente a wiki referencia a versão em desenvolvimento, que não é a que você quer. As versões dentro de "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õe estáveis também referenciam a versão do LEDE no nome como em "lede-17.01.0-r3205-59508e3-ar71xx-generic-tl-wr2543-v1-squashfs-sysupgrade.bin", ao contrário da versão instável/em desenvolvimento "lede-ar71xx-generic-tl-wr2543-v1-squashfs-sysupgrade.bin".

A nomeclatura da versão é parecida com a adotada pelo OpenWRT: 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. Já o último número é apenas um sequencial de correção. Então, para quem usa uma versão 17.01.x, a próxima 17.01.x+1 conterá apenas bugs resolvidos (em especial, os de segurança) e deve ser considerada como recomendada. Prometeram lançar versões de correções periodicamente. Vamos acompanhar

Em downloads, navegue para releases, a versão desejada (17.01.0 até agora), "targets" e seguindo o caminho da "arquitetura alvo" em uso no seu roteador. Se você já é um usuário do OpenWRT, você pode vê-la olhando o arquivo /etc/openwrt_release:

root@router:~~# cat /etc/openwrt_release
DISTRIB_ID='OpenWrt'
DISTRIB_RELEASE='15.05'
DISTRIB_REVISION='r46767'
DISTRIB_CODENAME='chaos_calmer'
DISTRIB_TARGET='ar71xx/generic'
DISTRIB_DESCRIPTION='OpenWrt Chaos Calmer 15.05'
DISTRIB_TAINTS=''

A diferença no LEDE para o OpenWRT é a presença do "targets" e, no mesmo nível, "packages". Comentei esta diferença no post anterior, mas normalmente o "packages" não é para você e será usado quase que exclusivamente pelo opkg de forma transparente.

OK, chegamos a uma lista enorme de firmwares! Vamos entender o que significa cada parte do nome do arquivo. O formato mudou um pouco no LEDE. Tomemos por exemplo "lede-17.01.0-r3205-59508e3-ar71xx-generic-tl-wr2543-v1-squashfs-sysupgrade.bin":

lede é o sistema operacional que você está instalando ;-)
17.01.0 é a versão do lede. Em firmwares instáveis, este campo não existe!
r3205 é um sequencial do número de mudanças no fonte. Serve para saber se um arquivo é mais velho do que outro.

Caso apareça algo a mais como r3205+2, significa que alguém deve ter feito 2 mudanças não oficiais sobre a versão r3205.

59508e3 é a versão resumida do hash da última mudança no git. Você pode usar comandos git sobre ela nos fontes do LEDE como "git log 59508e3".
ar71xx é a família do SoC (chip) do seu dispositivo. Você descobre isso na wiki do projeto ou abrindo o seu roteador e lendo os CI.
generic é o formato do layout da flash. Normalmente será o "generic", exceto para casos especiais.
tl-wr2543-v1 este é o modelo do seu roteador! Observe em especial a versão do HW (v1) pois ela pode mudar completamente o dispositivo, inclusive de família do SoC.
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. Pode existir também o formato jffs2. Neste, não existe uma ROM e tudo pode ser realmente apagado. Alterou o arquivo errado? Vai ter que recuperar pela serial, JTAG ou arrancando a flash. Não recomendo!\
sysupgrade é a função da firmware. Esta é para atualizar de um OpenWRT/LEDE 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".

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 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).

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! Faça o upgrade pela interface web ou pelo terminal. Inclusive, você pode baixar o arquivo diretamente no roteador. Ex:

# cd /tmp

# wget http://downloads.lede-project.org/releases/17.01.0/targets/.../generic/lede-17.01.0-r3205-59508e3-....-squashfs-sysupgrade.bin

# sysupgrade lede-17.01.0-r3205-59508e3-....-squashfs-sysupgrade.bin

Só cuidado ao colar a URL. O downloads.lede-project.org usa HTTPS por padrão mas o wget do OpenWRT não tem suporte para HTTPS (por padrão). Contudo, o downloads.lede-project.org aceita http sem problemas, só tirar o "s" se tiver problemas.

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/LEDE. 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 ;-)

E depois do "Enter"/"Gravar", é a hora que você reza. Sempre dá um frio na barriga.

Se optar por preservar as configurações, tudo que seria guardado em um backup do sistema (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 requeridos. No final do processo, é bom refazer a listagem do que está instalado e comparar com o que você tinha na versão anterior.

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 oriundas 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.

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.

Espero que apreciem a nova versão. De agora em diante, vou apenas focar em configurações específicas para LEDE 17.01.0, que ainda podem funcionar nas versões OpenWRT 15.05, 14.07, 12.09 e 10.03.1.

Se pintar um problema, tem sempre o fórum deste blog. Até a próxima.

LEDE é o novo OpenWRT: lançado primeira versão estável!

2017-02-27T23:48:00.002-03:00

O "grande tema" deste blog tem sido o OpenWRT. Entretanto, talvez isto tenha que mudar. Agora, o LEDE (Linux Embedded Development Environment) deve ocupar o seu lugar (rimou?). Evitei comentar o assunto LEDE até este momento pois ainda não estava sacramentado o destino dos projetos. Para quem não acompanhou todos os capítulos da novela, vou tentar resumir.

O OpenWRT já não era mais uma mocinha. Depois de vários anos de projeto, a estrutura continuava a mesma: um pequeno grupo superpoderoso "dono do nome, servidores, acesso de administração, poder de conceder escrita ao repositório, etc" e um grupo de desenvolvedores posteriores que formavam o grupo de desenvolvimento (core developers). Já há algum tempo, quem realmente fazia o OpenWRT eram os desenvolvedores que chegaram depois. Apesar desses novos desenvolvedores estarem no grupo core (terem acesso de escrita concedido pelos principais desenvolvedores), seu poder era limitado. Os desenvolvedores "originais" tinham o poder de veto sobre mudanças, direção do projeto, ferramenta de controle de versão, tudo sem regras claras, apenas baseado na sua convicção. Este autoritarismo pode funcionar bem em alguns projetos, como o Wine ou mesmo o Linux (o kernel), mas se mostrou desastroso para o OpenWRT.

Uma das brigas foi a adoção do git. Sim, existem outros sistemas de controle de versões e o XYZ é melhor... mas o git é uma mãe para desenvolvimento distribuído. Todos queriam, menos os "donos da bola", que mantinham o SVN. O acesso aos servidores também foi um problema sério. Diversos casos de indisponibilidade (inclusive até hoje em dia eles ocorrem) levavam um significativo tempo para serem sanados. Isto é péssimo para um projeto que também não aceitava espelhos parceiros. Boa parte das brigas não eram divulgadas pois ocorriam em uma lista fechada a apenas os desenvolvedores core. Não foi um evento específico mas o clima estava ficando péssimo. Apesar dos desenvolvedores "donos da bola" não fazerem mais uma contribuição quantitativamente significativa para o OpenWRT, eles ainda se apresentavam como a "cara" do projeto. E quem fazia o trabalho duro não gostava muito disso.

Agora entra a beleza do Software Livre! Nome (marca), servidores, domínios DNS tem dono. Código não. Os principais desenvolvedores (fora os "donos da bola") se juntaram e fizeram um "fork" em um outro projeto: LEDE Project. Em suma, é o código do OpenWRT com os desenvolvedores responsáveis, na época, por mais de 90% das contribuições do OpenWRT. A estrutura é muito mais aberta, comunicação bem mais transparente (primam por mídias abertas), o poder é distribuído e infraestrutura simplificada. O código sofreu rapidamente melhorias significativas, que antes eram vetadas. O git foi adotado, as formas de contribuição flexibilizadas (aceitam PR no Github ;-), que aumentou o envolvimento de novos desenvolvedores. Teve diversas mudanças mas o resultado é que deu uma revigorada no projeto.

E o OpenWRT? Se uma das críticas dos "rebeldes" era justamente a dificuldade de conceder acesso para novos desenvolvedores, como um projeto que perde mais de 90% do seu desenvolvimento atual poderia sobreviver? A lista openwrt-devel, antes vivida, parecia a lista da turma da faculdade de 15 anos atrás: rola uma mensagem por semana mas nada de útil. O desenvolvimento mingou ao insignificante, em ritmo de manutenção mínima. Os "donos da bola" ficaram com a bola mas sem time para jogar. Simplesmente não teriam como manter o projeto sozinhos (mas demoraram para entender).

Alguns meses depois da separação difícil, os dois grupos sentaram para conversar. Concordaram que seria benéfico unificar os projetos. O primeiro passo foi conceder acesso aos antigos desenvolvedores do OpenWRT ao código do LEDE (por votação, como ocorre com qualquer outro novo desenvolvedor). Como o LEDE estava muito mais avançado, seria usado como o fonte. Resta ainda hoje decidir alguns pontos como: qual seria o nome? Usar a wiki e fórum de quem? Redirecionar? Sincronizar? Essas coisas. O LEDE não está muito preocupado com isso pois o que o OpenWRT tem a oferecer a mais é o nome. Esse até mesmo perdeu seu sentido quando o OpenWRT passou a rodar em diversos dispositivos não rotadores wireless (Wireless RouTer), ao mesmo tempo que perdeu suporte no Linksys WRT56G. E qualquer mesclagem/alteração de nome é um esforço que poderia ser utilizado melhorando o produto.

De qualquer forma, o LEDE acaba de lançar a sua primeira versão estável: 2017.01.0! Acho que isto sacramenta o fim do projeto OpenWRT. Posso estar errado mas acho que logo a página do OpenWRT será apenas conteúdo histórico com um redirecionamento para o LEDE. Vamos ver...

Agora a parte importante: o que temos de bom? Em primeiro lugar, separaram os pacotes das imagens. Ainda existem pacotes específicos para um tipo de equipamento, em especial o kernel, mas não fazia sentido recompilar o mesmo pacotes quando as instruções de processador eram as mesmas. Então, ao baixar uma firmware nova em Downloads, vá em "targets" e não em "packages" (o resto é igual). Esta mudança não afeta o uso do opkg do ponto de vista do usuário.

Várias versões foram atualizadas, melhorado desempenho, latência, e outras mudanças evolutivas. Ah, e o Telnet que é muito usado no modo de emergência? Morreu: use SSH sempre, mesmo antes de definir a senha de root. Isto significa que teremos também o scp funcionando ;-)

O repositório de pacotes extra (https://github.com/openwrt/packages) continua ativado por padrão e, apesar do nome OpenWRT, o foco agora é LEDE.

Vou atualizar e relançar o post sobre atualização de versão do ~~OpenWRT~~LEDE. Até este momento, todos os upgrades funcionaram sem problemas de tal forma que um observador desatento nem notaria a mudança. Sim, pode fazer o upgrade a partir do OpenWRT como se fosse uma atualização de versão do próprio OpenWRT.

Ah, um dos problemas com a versão nova são os roteadores mais humildes. O opkg pode ter problemas com roteadores com 32 MBytes de RAM ao instalar pacotes e aqueles com 4MB de armazenamento já vão chegar quase cheios. Então, talvez você não consiga instalar mais coisas no seu TL-WR740N. Eu tive que baixar os pacotes manualmente e desligar o Luci. Estão trabalhando para melhorar isso...

Até a próxima!

NetVirtua e problemas com IPv6 (perda de rota padrão)

2016-05-22T03:42:00.001-03:00

Sim, IPv6 é necessário, é o futuro e já devíamos estar todos usando. Se você se julga com algum conhecimento de redes e não conhece IPv6, já passou da hora de estudar. Mas não é sobre isto este artigo.

Sou um entusiasta do IPv6 faz alguns anos. Sempre sonhei poder conectar da internet em qualquer equipamento da minha rede interna sem todos os "artifícios técnicos" para contornar o NAT (encaminhamento de porta, túnel sobre SSH, etc). Bastaria o firewall não bloquear. Por este motivo, em 2010 eu já utilizava túneis para obter conectividade IPv6. Era lento, deixava minha navegação pior, mas funcionava perfeitamente.

Em 2015, finalmente chegou o tão sonhado IPv6 pelo provedor! Logo reconfigurei meus equipamentos para utilizar a nova pilha IPv6. E então apareceram os problemas. Este é o tema deste artigo.

Administro duas redes ligadas a Net. Testei a configuração em uma... funcionou! Perfeito. Copiei para a segunda... funcionou novamente! Porém, depois de alguns minutos, notei que as máquinas da primeira rede não mais conversavam IPv6 com o mundo. No roteador da rede, ele estava sem rota padrão para o IPv6. Desliguei alguma coisa? E a segunda rede continuava a funcionar. Recarreguei a interface WAN e tudo voltou a funcionar. Mais alguns minutos... novamente sem IPv6 na primeira rede! (e a segunda rede continuava a funcionar...). Como as duas redes usavam o mesmo equipamento, mesma configuração, seria problema do equipamento do provedor? Vamos a investigação.

A NET distribui IPv6 por DHCPv6. O comportamento é similar ao IPv4: você ganha um endereço WAN para falar com a internet. A diferença é que, como não temos mais NAT, não iremos esconder os computadores da rede interna nem usar endereços falsos (192.168.x.x). Nesta mesma requisição do DHCPv6, a NET também informa uma rede com endereços IPv6 reais para suas máquinas internas (LAN), chamado de prefixo delegado. O roteador usa este endereço para que sejam definidos os endereços IPv6 (reais) da LAN. Tudo está funcionando perfeitamente quando, então, a tabela de roteamento IPv6 que era:

root@router:~# ip -6 r

default from 2804:14d:????:1000:204c:36a0:daed:f2d7 via fe80::217:10ff:fe87:5c9c dev eth0.2 proto static metric 512

default from 2804:14d:????:8417::/64 via fe80::217:10ff:fe87:5c9c dev eth0.2 proto static metric 512

2804:14d:????:1000::/64 dev eth0.2 proto static metric 256

2804:14d:????:1010::/64 dev eth0.2 proto static metric 256

2804:14d:????:8417::/64 dev br-lan proto static metric 1024

Vira:

root@router:~# ip -6 r

2804:14d:????:1000::/64 dev eth0.2 proto static metric 256

2804:14d:????:1010::/64 dev eth0.2 proto static metric 256

2804:14d:????:8417::/64 dev br-lan proto static metric 1024

Se você está enfrentando isto e quer apenas "resolver", para usuários do OpenWRT, basta subir novamente a interface wan6 a cada 20 minutos. A cron é excelente para isto:

root@router:~# crontab -l

*/20 * * * * /sbin/ifup wan6

Isto não era suficiente. Eu queria mais: mas porquê? E eu tinha um trunfo: acesso a duas redes com comportamentos diferentes. O primeiro passo é sempre dar uma "cheirada" na rede. O roteador das duas redes são OpenWRT. Desta forma, posso instalar o tcpdump(-mini) e capturar os pacotes durante a negociação do endereço. Podemos fazer isto de forma assíncrona:

root@router:~# tcpdump -i eth0.2 -U -s 0 -w /tmp/dump-ipv6.pcap ip6

E analisar o arquivo dump-ipv6.pcap, ou mesmo já jogar a captura para dentro do wireshark local.

luiz@minhamaquina:~$ ssh root@router tcpdump -i eth0.2 -U -s 0 -w - ip6 | wireshark -k -i -

Observando as duas capturas, já é possível notar que estamos em equipamentos diferentes da NET. Na que para de funcionar, o roteador que responde é o 2804:14d:baa6:1000::1 (vou chamar de baa6). Na segunda, que continua a funcionar, 2804:14d:baa5:1000::1 (vou chamar de baa5).

Na rede que para de funcionar depois de um tempo, a requisição de roteador (router solicitation - RS) que ocorre antes do DHCPv6 é respondida, enquanto na outra, não. Aparentemente o baa6 está configurado para enviar RA (route advertisement) e o baa5 não. Mas responder (ou não) com um RA não deveria ser um problema, desde que ele continue a respondê-lo e enviá-lo periodicamente. De resto, os dois tráfegos são equivalentes, exceto que a rede que funciona (conectada no baa6) tenta novamente após 10s uma nova solicitação de roteador (também sem resposta).

Olhando com carinho, o tempo de vida do RA (router lifetime) é de 1800s (30 min), muito próximo ao tempo até a queda da rota padrão. Interessante. Pode ser por aí o problema. O RA é enviado voluntariamente pelo roteador em um período aleatório mas dentro de um intervalo máximo e mínimo. Pelo que eu entendi da RFC 4861, o cliente não deve enviar um novo RS em situações normais, apenas aguardar o próximo RA que deveria chegar antes de estourar o tempo de vida da rota (router lifetime). Então, onde está meu RA não solicitado? Será que o roteador não está enviando? Ou será que ele está sendo bloqueado? Eu monitorei o tráfego e não achei qualquer outro RA chegando na minha interface WAN.

Bem, vamos simular uma situação onde o baa6 não responderia o RS. Isto pode ser feito bloqueando qualquer RA que chega no roteador pela WAN.

root@router:~# ip6tables -A INPUT -i eth0.2 -p ipv6-icmp -m icmp6 --icmpv6-type 134 -m comment --comment "bloqueia RA da NET" -j DROP

Ou para usuário do OpenWRT:

~~config rule~~

~~option name 'bloqueia RA da NET'~~

~~option src 'wan'~~

~~option proto 'icmp'~~

~~option family 'ipv6'~~

~~list icmp_type 'router-advertisement'~~

~~option target 'DROP'~~

Atualizando: a recarga das regras do firewall ocorria justamente quando o RA estava chegando. Por isto, o RA poderia ser aceito neste tempo. Melhor usar uma regra em um chain que o fw3 não limpa ao recarregar (somente ao reiniciar). Coloque isto em /etc/firewall.user:

if ! ip6tables -L INPUT | grep -q "bloqueia RA da NET"; then
echo "Primeira vez que esta rodando... adicionando filtro do RA e recarregando WAN"
ip6tables -t filter -I INPUT -i $(uci get network.wan.ifname) -p icmpv6 -m icmp6 --icmpv6-type 134 -m comment --comment "bloqueia RA da NET" -j DROP
ifup wan6
fi

Você saberá que funcionou quando o comando abaixo mostrar no primeiro número (número de pacotes casados) um valor diferente de zero (normalmente 4):

root@router:~# ip6tables -L -nv | grep 'bloqueia RA da NET'

4 544 DROP icmpv6 eth0.2 * ::/0 ::/0 ipv6-icmptype 134 /* bloqueia RA da NET */

Depois de 30 minutos nossas rotas devem ainda estar vivas. Estamos no caminho certo. Sem RA, a rota padrão vem apenas do DHCPv6 e sem validade de 30 minutos. Falta apenas descobrir o porquê de não receber o RA. Se o equipamento for um Cisco, eu chutaria que ele usou "ipv6 nd ra suppress" quando deveria ter usado "ipv6 nd ra suppress all". Mas vamos a mais alguns testes novamente com o sniffer ligado.

Pelo DHCPv6, recebo o endereço WAN e uma rede para a LAN. Esta rede para LAN vai gerar todos os endereços de equipamentos da minha rede local, inclusive para a interface LAN do roteador. No meu caso, ela é <prefixo recebido>::1/64. Quando eu realizava um teste com o ping6 para endereços na internet, eles respondiam sem problemas. Porém, eu notei que o roteador estava usando o endereço da LAN e não da WAN. E se eu escolher o endereço que o ping deve usar? Ex:

root@router:~# ping -6 -I <endereço IPv6 WAN e não o nome da interface!> ipv6.br

Bingo! Na rede que sempre funcionou o IPv6 (ligada ao baa5), consigo usar tanto o endereço LAN como o WAN e ambos funcionam. Na rede que não funciona (ligada ao baa6), não tenho resposta. Agora a dúvida: eu não consigo enviar ou receber? Novamente vamos usar o trunfo de ter administração em duas redes. Ligando o sniffer na rede sem problemas, podemos ver a chegada e a saída de pacotes:

02:50:15.246987 IP6 [IP:LAN:baa6] > [IP:WAN:baa5] ICMP6, echo request, seq 0, length 64
02:50:15.247433 IP6 [IP:WAN:baa5] > [IP:LAN:baa6] ICMP6, echo reply, seq 0, length 64
02:50:40.377930 IP6 [IP:WAN:baa6] > [IP:WAN:baa5] ICMP6, echo request, seq 0, length 64
02:50:40.378262 IP6 [IP:WAN:baa5] > [IP:WAN:baa6] ICMP6, echo reply, seq 0, length 64

Opa! O "echo request" chegou nos dois casos e foram respondidos prontamente. Agora olhando no lado da origem:

02:50:15.246987 IP6 [IP:LAN:baa6] > [IP:WAN:baa5] ICMP6, echo request, seq 0, length 64
02:50:15.247433 IP6 [IP:WAN:baa5] > [IP:LAN:baa6] ICMP6, echo reply, seq 0, length 64
02:50:40.377930 IP6 [IP:WAN:baa6] > [IP:WAN:baa5] ICMP6, echo request, seq 0, length 64

Faltou chegar o pacote da resposta. Tentando o ping vindo da outra rede, nada chegou. Tentei também ping vindos de fora das duas redes e o comportamento foi o mesmo. Na rede que sempre funcionou, recebi os pacotes sem problemas. Na outra, nenhum pacote chegou.

Para confirmar esta suspeita, liguei o cabo do NetVirtua diretamente em um computador. Assim, ele assumiria o endereço WAN para uso normal (sem usar o prefixo delegado). O resultado: ganhei o endereço IPv6 mas, fora isto, nada relacionado a IPv6 funcionou pois nunca recebi pacotes vindos da internet do IPv6. Para que serve uma conexão com a internet se só posso enviar pacotes e não receber?

Em suma: a NET está com um roteador que não permite enviar dados para o endereço IPv6 WAN. Por mera coincidência, ele também responde o RS com um RA, o que exigiria o envio de um novo RA antes de estourar a validade da rota (30 min). Como não recebo qualquer pacote, o novo RA nunca chega e perco a rota padrão. Se o RA estivesse desligado, isto dificilmente seria notado pois é raro que os roteadores recebam pacotes (exceto se usar OpenWRT).

Enviei tudo isto para a Net e esta foi a sua grande resposta:

Protocolo de Atendimento:08815.12620.98631
Prezado cliente,

Informo que nesse momento não há viabilidade técnica para instalação dos produtos IPV6 e infelizmente não há previsão de adequação da rede e liberação da mesma para comercialização dos produtos.
Agradecemos o seu contato.

Atenciosamente,
MARCKSON FERNANDO DE DEUS

Depois dessa como vou argumentar?! Meu endereço IPv6 e o roteamento com a internet deve ter brotado por abiogênese!

Atualizando: entrei em contato novamente para a NET. A nova resposta:

Protocolo de Atendimento: 08816.14500.66951

Prezado cliente,
Recebemos o seu e-mail e conforme verificado em sistema informamos que o seu EMTA 2.0 não é compatível com protocolo IPV6. É necessário a troca do equipamento para obter o IPV6, ressaltamos que a visita será cobrada o valor de R$ 90,00, caso tenha interesse será necessário realizar uma nova solicitação através de nossos canais de atendimento, que agendaremos uma visita técnica em sua residência.
Agradecemos o seu contato.

Atenciosamente,
LARISSA RIBEIRO SANTOS

Legal! Querem agora me cobrar por uma falha deles! Ao menos não disseram que não tenho esse tal de IPv6. Agora vamos a argumentação: EMTA 2.0 deve ser DOCSIS 2.0, que realmente não teria suporte ao IPv6. Porém, No local onde funcionava (ligado ao baa5), o modem era realmente diferente (Cisco DPC2203) do meu (Thomson DHG534B). Porém, ambos com suporte somente a DOCSIS 2.0. Também consegui testar em um terceiro ponto com o modem IGUAL ao meu. Surpresa?! Funcionou perfeitamente! Mas este ponto está ligado a um terceiro roteador na Net (baa1). Então, de três pontos diferentes da Net, 2 funcionam e 1 não. Os roteadores tem o mesmo sistema operacional (OpenWRT) e configuração IPv6 (default). Todos os modems são DOCSIS 2.0 e com o mesmo modelo de modem, de um lugar funciona e outro não. Dá para afirmar com uma certa segurança que o problema é a configuração do baa6. Como se argumenta com a NET desta forma? Vou ligar para eles e tentar falar com alguém que entende...

Alguém aí trabalha na Net ou conhece alguém da área técnica? Compartilha este link ;-) Não queria ter que começar mais uma batalha com a ANATEL.

Para os afetados, sugiro adicionar a regra do firewall e configurar qualquer serviço divulgado na rede (ex: torrent) confirma se ele está usando o endereço IPv6 da LAN e não da WAN.

Dúvidas? Use o fórum deste blog!

Até a próxima.

OpenWRT: nova versão do sane-backends e hplip para OpenWRT

2015-10-29T01:12:00.000-02:00

Mais um artigo da série sobre o OpenWRT.

Uma das mudanças da nova versão do OpenWRT é que a política de gerenciamento dos pacotes foi renovada. Agora todos tem um mantenedor. Os pacotes que não ganharam um pai não foram compilados na nova versão. Então, não estranhe se ao atualizar o seu roteador e tentar reinstalar um pacote, um ou outro pacote estiver faltando.

E o que fazer se você queria aquele pacote? Que tal adotá-lo você mesmo? Fui o que fiz para o sane-backends. Este artigo é sobre as melhorias feitas neste pacote que fornece a infraestrutura para acesso a scanners. A configuração para transformar um scanner normal em um scanner de rede já foi tema anterior deste blog.

Um dos grandes problemas que o pacote anterior tinha era a exigência de espaço para instalá-lo. Além de conter todos os drivers, ele dependia do CUPS, que não é lá muito pequeno. O ideal para quem for portar algo para o OpenWRT é tentar isolar os recursos em pequenos pacotes para que o usuário possa instalar somente o que ele vai usar. Não era a situação anterior deste pacote.

O sane-backends era dividido em:

sane-backends: continha todos os executáveis (incluindo o daemon) e configurações;
sane-libs: tudo que era uma biblioteca, includindo os drivers e a biblioteca base;
sane-frontends: clientes simples do sane;

O problema desta estrutura é que ela separa tipo de arquivo (configuração e executáveis, bibliotecas) e não funcionalidades. O sane-libs não vivia sem o sane-backends e todos os backends (drivers) estavam juntos. Para quem fosse usar o hplip (para scanners HP), nenhum backend era usado. Fora este desperdício, ainda temos a dependência ao CUPS (que é relacionado a impressoras e não diretamente a scanners). Então, para usar o scanner no OpenWRT, era quase requisito aumentar o disco com uma unidade externa. Simplesmente não cabia em uma flash de 8MB.

O primeiro passo foi juntar o sane-libs e o sane-backends e dividí-los por funcionalidade. No caso, temos a biblioteca básica (libsane), que todos os clientes e backends usam, o daemon usado para acesso de clientes remotos e os diversos backends, que são compostos de um módulo (implementado como uma biblioteca - extensão .so) e um arquivo de configuração.

Na nova modelagem, o pacote ficou dividido em:

libsane: apenas a biblioteca básica do sane, usada por todos os drivers (inclusive o hplip);
sane-daemon: inclui apenas o daemon do sane e suas configurações, depende da libsane;
sane-<xxx>: onde <xxx> é um backend. Possui dependência particular de cada pacote;
sane-backends-all: metapacote que instala todos os backends;
sane-frontends: clientes simples do sane (igual a versão anterior).

Foram feitos alguns patches de melhorias para retirar a dependência do CUPS (era usado somente para localizar um tipo de scanner), reduzir a dependência entre bibliotecas e mais um bom tanto de ajustes relacionados a compilação em arquiteturas diferentes usando uma libc diferente (uclibc e musl). Algumas das correções foram enviadas ao projeto do SANE e já integram atualmente a versão estável do sane!

Resultado? O básico do sane pode ser instalado com algo em torno de 70 Kbytes (fora a dependência da libusb). Esta nova versão proposta estará na nova versão do OpenWRT (DD) ainda em desenvolvimento neste momento. Se quiser usá-la imediatamente em versões anteriores, tenho um repositório próprio com uma seleta de pacotes para algumas arquiteturas em http://luizluca.github.io/openwrt/.

E se eu tenho uma multifuncional HP, como faço com a hplip? Também temos uma nova versão proposta da hplip no repositório que mencionei acima. Este, além de atualizar a versão, o que antes era apenas um pacote foi dividido em:

hplip-common: bibliotecas usadas por ambos os próximos pacotes;
hplip-sane: backend sane. Se for usar apenas a impressora e não o CUPS no roteador, só vai precisar deste. A impressora ainda pode ser usada sem o driver pelo p910nd;
hplip-cups: o driver para o cups. Somente este pacote depende do CUPS.

Mesmo o hplip-sane precisava do CUPS para localizar scanners de rede. Assim como no sane-backends, esta funcionalidade foi removida por um patch para não deixar a dependência. Isto retira uma funcionalidade de buscar scanners em impressoras na rede. Porém, não fazia muito sentido o roteador buscar um scanner que já está na rede para, novamente, disponibilizá-lo na rede. Neste caso, o cliente deve conversar diretamente com a impressora e não utilizar o roteador. O foco do uso do OpenWRT é justamente transformar uma impressora/scanner local em um equipamento de rede.

Todavia, existe ainda uma questão a ser resolvida para as versões CC e DD: ninguém adotou o CUPS. Desta forma, ele não está disponível. Ainda vou ver o que eu posso fazer quanto a isto, se tento eliminar o hplip-cups, adotar o pacote do cups ou esperar que alguém o adote. Provavelmente vou disponibilizar os pacotes do hplip-sane para as novas versões no meu repositório.

Se pintar um problema, tem sempre o fórum deste blog. Até a próxima.

OpenWRT: Configurando o QoS - Utilizando o SQM

2015-10-03T02:29:00.000-03:00

Este é mais um artigo da série sobre o OpenWRT.

O problema de QoS foi tratado em dois posts anteriores. No primeiro, mostrando o problema e no segundo configurando uma solução com o qos-scripts. Este artigo é uma alternativa ao uso do qos-scripts, utilizando o sqm-scripts.

O SQM surgiu do projeto CeroWRT (fork do OpenWRT), que tem como principal objetivo atacar o excesso de buffer nos equipamentos de rede (o bufferbloat), que geram grandes latências quando o enlace está sobre carga. As melhorias deste projeto retornaram para o OpenWRT (versão BB ou posterior) e para o Linux em geral.

Vamos rever alguns conceitos: podemos avaliar um enlace por três parâmetros:

A taxa de transmissão (vulgarmente conhecido como "velocidade");
A latência (duração da viagem de um pacote até seu destino);
E o jitter (variação na latência).

Contratamos internet sempre pelo primeiro parâmetro (taxa de transmissão) mas dificilmente olhamos os demais. Os "speedtests" focam no primeiro, que é quantos dados você pode receber/enviar em um determinado tempo. Este é o fator determinante de quanto tempo o download de um arquivo vai levar ou se sua conexão vai aguentar assistir aquele filme do Netflix sem engasgar.

Os outros dois parâmetros (latência e jitter) são mais importantes para aplicações "em tempo real", como videoconferência, voz (VoIP), sessão remota (VNC, RDP, etc) e jogos online com interação imediata (FPS, MMORPG, RTS, etc, mas não o poker). A latência determina em quanto tempo o inimigo do Battefield que entrou na sua frente vai aparecer no seu computador e também quanto tempo o seu tiro vai levar para chegar ao servidor. Se a latência for muito grande, até seu tiro chegar ao servidor, seu inimigo mirou na sua cabeça, pensou duas vezes e atirou umas três vez. No "mundo virtual", você estava morto antes de tê-lo visto. Mesmo na navegação Web, a latência importa pois se ela estiver em algo como 1s, um clique em uma página vai levar uns 6 segundos para começar a carregar. É o clássico "a internet está lenta hoje", mas ao baixar um arquivo, a taxa de transmissão não está tão ruim. Já o jitter é a variação deste atraso. Se for significativo, os pacotes começarão a chegar fora de ordem e não serão úteis para aplicações em tempo real. Para minimizar isto, foram criadas filas (buffers) que reorderam os pacotes enquanto aguardam serem enviados. O problema é que atualmente se exagera no tamanho nesta fila, gerando o problema do bufferbloat.

Quando o enlace estiver sobrando, não existem filas e não existe problema. Agora, quando você tem alguém enchendo a fila dos roteadores no seu caminho (que ocorre quando você baixa ou sobe qualquer coisa na velocidade do seu enlace), o excesso de buffer gera uma fila longa e aumenta da latência). Para testar isto, faça um ping a um equipamento fora da sua rede (ex: 8.8.8.8 do google) e inicie um download ou upload (ou ambos) grande para um local que consiga usar toda a sua conexão. A latência do ping irá fatalmente aumentar. Esta diferença no tempo antes e depois do download/upload é um indicativo do tempo que um pacote leva para passar na fila dos seus roteadores. Você também pode fazer isto por alguns provedores de "testes de velocidade", como o http://www.dslreports.com/speedtest (não foque na velocidade ou na latência, que pode ser pequena/grande pela distância, mas no bufferbloat). O ideal seria que a latência mesmo quando o enlace estiver com carga (download ou upload) deveria ser apenas um pouco maior do que a situação quando o enlace está ocioso. Outra forma de testar é pelo script betterspeedtest do projeto CeroWrt. Funciona em qualquer Linux ou de dentro do OpenWRT (basta instalar o netperf).

E como resolver o bufferbloat? Deixe as filas menores para que, quando cheias, novos pacotes sejam descartados, informando ao emissor que ele precisa "pegar leve". Em conjunto, você pode dividir seu tráfego em filas para casos distintos (similar aos caixas-rápidos do supermercado que limitam o atendimento a clientes com até 20 produtos).

No OpenWRT, existem duas propostas para solucionar este problema: o qos-scripts (mais antigo) e o sqm-scripts (mais novo), que trabalham em conjunto com o escalonador de pacotes padrão fq_codel (também focado no problema do bufferbloat). O primeiro faz algumas classificações automáticas (pelo volume de tráfego e alguns sabidamente urgentes) mas deixa a parte pesada da classificação na mão do operador. Já o segundo utiliza inteligência para classificar o tráfego automaticamente, sem parametrização (SQM significa "Smart Queue Management". A inteligência está parte "Smart"). Neste artigo vou tratar de como configurar a segunda proposta.

Tanto para o qos-scripts como para o sqm-scripts, o parâmetro determinante para o seu funcionamento é a taxa de transmissão do enlace. Para controlar a fila, o roteador tem que fazer a fila da conexão fica nele, seja para subir ou descer pacotes. E para a fila ocorrer no roteador, este tem que limitar o tráfego a um valor menor do que a sua conexão com a internet pode aguentar. Assim, não serão feitas filas significativas nos equipamentos da sua provedora de internet, apenas no seu roteador. Por isto, o valor de download/upload configurado deve ser menor do que o contratado. Falam de algo entre 85% a 95% da taxa de transmissão real. Se este parâmetro for maior do que a taxa de transmissão real (real, não a contratada), os controles não atuarão e o QoS não será efetivo.

O sqm-scripts e o qos-scripts são mutualmente exclusivos. Se estava usando o qos-scripts e quer usar o sqm-scripts, remova-o antes de iniciar o processo.

A instalação do sqm-scripts é bem simples e parecida com o qos-scripts:

# opkg update

# opkg install sqm-scripts

Se quiser a interface Luci (web):

# opkg install luci-app-sqm

O arquivo de configuração fica em /etc/config/sqm, que pode ser alterado sem problemas pelo Luci em "Rede/SQM Qos". A configuração mínima se limita a:

Habilitar a configuração;
Definir a interface WAN, normalmente eth1 ou eth0.2. Esta pode ser identificada na página de interfaces ou mesmo em "Estado/Visão Geral";
Configurar os valores de download e upload para algo entre 85% a 95% da taxa de transmissão real.

Depois é só habilitar e disparar o serviço sqm pela interface Luci ou pelo SSH:

/etc/init.d/sqm enable

/etc/init.d/sqm start

Feito! Só testar a sua conexão. Para efeitos de testes, eu usei o script betterspeedtest que mencionei acima diretamente no roteador.

Inicialmente, sem o SQM:

root@router.lan3:~# sh betterspeedtest.sh

2015-09-30 01:27:05 Testing against netperf.bufferbloat.net (ipv4) with 5 simultaneous sessions while pinging gstatic.com (60 seconds in each direction)

..............................................................

Download: 5.14 Mbps

Latency: (in msec, 62 pings, 0.00% packet loss)

Min: 16.616

10pct: 485.537

Median: 762.117

Avg: 751.026

90pct: 963.462

Max: 970.820

.................................................................

Upload: 0.63 Mbps

Latency: (in msec, 62 pings, 0.00% packet loss)

Min: 10.778

10pct: 840.844

Median: 1006.490

Avg: 971.260

90pct: 1115.123

Max: 1151.302

A taxa de transmissão corresponde a contratada (até mais) mas a latência do download/upload, respectivamente, sobe de 16/10 milissegundos em "repouso" para, em média, 762/1006 milissegundos quando em carga. Isto significa que, sobre carga, tudo que dependa de resposta rápida vai "engasgar" em torno de um segundo antes de chegar ao seu destino. E isto é multiplicado para protocolos que exigem negociação/confirmação, como o TCP. Se você já sentiu sua internet lenta quando está anexando um documento grande em um email vai saber do que eu falo.

Agora ativando o SQM:

root@router.lan3:~# sh betterspeedtest.sh

2015-09-30 01:40:12 Testing against netperf.bufferbloat.net (ipv4) with 5 simultaneous sessions while pinging gstatic.com (60 seconds in each direction)

.............................................................

Download: 4.61 Mbps

Latency: (in msec, 61 pings, 0.00% packet loss)

Min: 10.860

10pct: 12.388

Median: 18.495

Avg: 20.443

90pct: 27.702

Max: 57.228

..............................................................

Upload: 0.5 Mbps

Latency: (in msec, 60 pings, 0.00% packet loss)

Min: 11.078

10pct: 12.813

Median: 25.371

Avg: 26.920

90pct: 42.409

Max: 54.265

Agora o aumento na latência foi bem menor! A média subiu apenas para 18/25, respectivamente. Em contrapartida, a taxa de transmissão foi menor pois estou podando ela antes de atingir o limite que a operadora me oferta.

Mas o valor ainda subiu muito! Olhe o valor máximo! O SQM tem um certo volume de carência em função da taxa de transmissão configurada. No início da conexão, ele permite que a fila aumente pois ainda não conhece o comportamento desta conexão. No speedtest pelo navegador que mencionei anteriormente, é possível observar este comportamento. Quando esta apresentar um volume maior, ela vai ser reclassificada. Outro motivo é para aproveitar melhor as rajadas de tráfego (seu provedor, por exemplo, pode liberar uma maior taxa de transmissão para os primeiros kbytes para tornar a resposta de coisas leves como navegação em páginas mais fluída). Se podar ainda mais sua conexão, ou fazer um teste mais longo, a média tende a ser menor.

Brinque, teste variações na configuração na velocidade de upload e download. Avalie quando o QoS se tornou efetivo. Compare com o qos-scripts. Avalie a usabilidade da internet. Compartilhe sua experiência com o sqm-scripts no fórum deste blog.

Até a próxima.