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

Mais um artigo da série sobre o OpenWrt.

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

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

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

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

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

Mais um artigo da série sobre o OpenWrt.

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

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

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

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

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

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

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

E esses são só os problemas mais sérios do gerenciamento da firmware original. Temos vários outros:

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

(Deve ter mais, mas não investi tempo nisso. Esses foram os que eu tropecei e ainda lembro.)

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

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

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

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

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

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

Até a próxima.