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

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

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

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:

1. Habilitar a configuração;
2. 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";
3. 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.

OpenWRT: Atualizando para versão 15.05

Mais um artigo da série sobre o OpenWRT.

Já temos a Caos Calmer (CC) 15.05. Agora vamos atualizar nossos sistemas!

Sim, este artigo repete diversos pontos do artigo de atualização anterior.

96,72% dos problemas com instalação/atualização com OpenWRT 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 Caos Calmer e nunca em um endereço qualquer, mesmo que seja na wiki do OpenWRT. Normalmente a wiki referencia a versão em desenvolvimento, que não é a que você quer. No diretório de download, navegue 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 entre a primeira instalação e a atualização é que não será usada a imagem "factory" e sim a "sysupgrade". Escolha o arquivo correspondente ao seu roteador (inclusive versão de hardware!). E muito importante, leia 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 openwrt, 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.

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.openwrt.org/chaos_calmer/15.05/.../openwrt-15.05-...-squashfs-sysupgrade.bin

# sysupgrade openwrt...xxx....img 

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). Contudo, o downloads.openwrt.org aceita http sem problemas, só tirar o "s".

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

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

Não é comum no OpenWRT mas pode existir alguma atualização de segurança importante, como ocorreu com o Heartbleed. De qualquer forma, é bom listar os pacotes atualizáveis:

# opkg update
# opkg list-upgradable

O maior problema é que estas atualizações de segurança também ocupararão espaço a mais do seu roteador (overlay) pois apagar ou substituir arquivos existentes na firmware inicial não recupera o espaço usado no sistema de arquivos.

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.

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 existentes na unidade externa ou mesmo com as bibliotecas 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 do 15.05, que ainda podem funcionar nas versões 14.07, 12.09 e 10.03.1.

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

OpenWRT: Fazendo Backups

Mais um artigo da série sobre o OpenWRT.

Antes de comentar como atualizar para a próxima versão do OpenWRT, achei interessante comentar sobre um assunto relacionado, mas tão importante que merece um artigo próprio: backups.

Tem gente que ainda confia em tecnologia. Brinco dizendo que não adianta rezar, só backup salva. Depois de fotos, vídeos, documentos, os roteadores são a última coisa que as pessoas se preocupam em fazer backup. Afinal de contas, para os mais simples, ele só contém o nome da rede e a senha. Porém, com o OpenWRT, seu roteador pode ser muito mais do que isto. O meu, em especial, é a central de comunicação, entreterimento e armazenamento da casa. Na prática, um servidor na rede com múltiplas funções. Como configurá-lo exige uma significativa quantidade de trabalho, sempre é bom evitar que você tenha que refazê-lo caso algo aconteça com ele.

Saindo do ambiente residencial, o tempo de restauração normalmente é crítico para ambientes empresariais. Neste caso, um backup "na mão" facilita em muito restaurar rapidamente um equipamento com defeito. Fora isto, backup podem ser utilizados para replicação "em massa", evitando o retrabalho de configurar o roteador "do zero" (para este fim, tem que recriar a entrada da ULA do IPv6).

Neste artigo, vou considerar que você conhece um básico do OpenWRT, como a estrutura que usa o squashfs com a overlay.

O OpenWRT tem backup? Sim, mas não de tudo. O backup do OpenWRT guarda somente configurações e dados selecionados do /etc. A lista do que ele copia pode ser vista com o comando "sysupgrade -l":

root@router:~~# sysupgrade -l

/etc/config/dhcp

...

/etc/sysctl.conf

/etc/sysupgrade.conf

São alguns arquivos pré-definidos, listados em /lib/upgrade/keep.d/ (pelos pacotes) ou em /etc/sysupgrade.conf, pelo usuário. Programas instalados não serão salvos, mas somente suas configurações (se estiverem em /etc/config ou forem explicitadas pelo mantenedor do pacote). É isto que é preservado quando você faz uma atualização do OpenWRT e pede para salvar as configurações. Compare isto com o conteúdo da overlay. Tudo que estiver lá foi modificado no seu sistema desde a instalação. O que estiver lá e não na listagem do sysupgrade, será perdido utilizando esta forma de backup. 

E quanto aos programas? Se você usa a firmware no formato squashfs, existem duas opções. A primeira é guardar a lista dos pacotes instalados e reinstalá-los. Para facilitar, você pode ver na /overlay:

root@router:~# ls /overlay/usr/lib/opkg/info/*control | sed -e 's%.*/%%;s/\.control//' | xargs

aiccu bind-dig bind-host bind-libs binutils block-mount coreutils-du coreutils ddns-scripts diffutils e2fsprogs...

Com a lista de pacotes salva, basta instalá-los após a restauração da configuração.

A segunda opção é guardar toda a overlay. Para salvar tudo mesmo que você fez desde a instalação do OpenWRT, é bom copiar a partição overlay. Um tar simples pode fazer o serviço. De um computador com Linux, execute:

$ ssh root@router tar -czv /overlay | dd of=backup-roteador.20150925.tgz

Isto compacta a /overlay em um tar e envia para o arquivo local backup-roteador.20150925.tgz sem criar o arquivo no roteador, que nem sempre tem espaço para isto. O WinSCP poderia copiar a overlay mas provavelmente você teria problemas com a permissão (perdida) dos arquivos. Se a overlay for pequena, você pode fazer o tar no /tmp (memória RAM) e copiar com o WinSCP:

root@router:~# tar -czvf /tmp/backup-roteador.20150925.tgz /overlay

Caso use Linux, fiz um pequeno script que faz a cópia do backup do OpenWRT, da lista de pacotes e da overlay em um único passo. Se seu roteador está em 192.168.1.1, só chamar:

$ ./fullbackup 192.168.1.1

E se eu não uso a firmware em squashfs? Primeiro você é corajoso pois se fizer algo de errado, não terá como usar a recuperação do OpenWRT. Contudo, isto não é um problema se o OpenWRT foi instalado em um PC ou VM. Para estes casos, faça o tar de todo o conteúdo. Só precisa tomar o cuidado de excluir os diretórios de dados voláteis (/proc, /sys, /tmp, /var/tmp, ...) ou simplesmente use a opção "--one-file-system" do tar para não sair da partição raíz.

E para restaurar tudo isto? Se for o backup do OpenWRT, pode ser feito pela interface web ou pelo comando sysupgrade. Se for pela overlay, recomendo entrar no modo de recuperação, zerar o roteador, montar a overlay e descompactar o conteúdo diretamente sobre a partição. Escrever na overlay enquanto ela estiver usada resulta em comportamentos incertos.

E, reforçando, não adianta rezar: só backup salva!

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