OpenWRT: Atualizando para versão 14.07

Com o lançamento da nova versão do OpenWRT 14.07 (comentários), é chegada a hora de mais um upgrade. Prepare suas duas horas de janela de mudança, avise seus clientes da indisponibilidade do serviço internet e mão na massa.

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 do Barrier Breaker 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 é o que você quer. No diretório de download, navegue seguindo o caminho da "arquitetura alvo" em uso no seu roteador. Você pode vê-la olhando o arquivo /etc/openwrt_release:

root@router:~# cat /etc/openwrt_release
DISTRIB_ID="OpenWrt"
DISTRIB_RELEASE="12.09"
DISTRIB_REVISION="r36088"
DISTRIB_CODENAME="attitude_adjustment"
DISTRIB_TARGET="ar71xx/generic"
DISTRIB_DESCRIPTION="OpenWrt Attitude Adjustment 12.09"

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 disco raiz em unidade externa, a encrenca é ainda maior. Quem usa WDS para conectar dois segmentos de rede via wireless também pode ter que fazer um pequeno ajuste nos clientes, já que o BB não muda o SSID com múltiplos SID.

Mas eu nunca instalei um programa! OK, use a interface web e provavelmente todas as configurações serão migradas sem problemas. Mas faça o backup antes! Caso contrário, continue lendo.

Em primeiro lugar, precisamos do plano de retorno caso a nova versão não se comporte como o esperado. Faça um backup geral do seu sistema. Sugiro três coisas diferentes: backup gerado pelo openwrt, lista de pacotes instalados e todos os arquivos do overlay.

A primeira e mais simples é o backup que pode ser gerado pela interface WEB do OpenWRT. Este é obtido na mesma página de atualização de firmware do seu roteador. Ele contém uma seleção prévia de várias configurações, inclusive tudo que está em /etc/config. Contudo, o backup não irá manter outros arquivos modificados em /etc ou em outro lugar. Por exemplo, se você fez alguma modificação no /etc/dnsmasq.conf, ele não será preservado pois este arquivo não está selecionado para ser copiado. Se criou um script em /bin ou para os botões em /etc/hotplug.d/button, ele não será preservado. Para incluir estes e outros casos, informe o caminho destes arquivos extras em /etc/sysupgrade.conf. Na interface WEB também tem a edição deste arquivo, no mesmo local da atualização da firmware, na parte de configuração. Gere um arquivo de backup novo e verifique se tudo que você quer está lá dentro. Somente estes arquivos serão preservados em um upgrade.

Dica: olhe todo o conteúdo em /overlay. Ele terá tudo o que foi modificado. Cuide principalmente dos arquivos em /etc.

Porém, o backup do openwrt não é feito para guardar os programas instalados. Ele se limita a scripts, dados e arquivos de configuração pré-configurados e os listados em /etc/sysupgrade.conf. Programas instalados por pacotes devem ser reinstalados manualmente. Por isto a próxima sugestão.

A segunda sugestão é gerar uma listagem de todos os pacotes instalados. Ela será usada de referência para reinstalar todos os seus programas. Como os programas não serão preservados (somente suas configurações e se estiverem no backup) você terá que reinstalá-los. Em geral, é uma meia dúzia de programas. A lista dos pacotes instalados pode ser obtido pela interface web ou pelo comando "opkg list-installed". Contudo, eu prefiro observar o diretório /overlay/usr/lib/opkg/info. Como cada pacote instalado cria um arquivo de controle neste diretório e o /overlay terá somente os arquivos modificados, você terá ao menos um arquivo por novo pacote instalado. O comando abaixo lista todos estes pacotes instalados após a gravação da firmware:

find /overlay/usr/lib/opkg/info/ -name '*.control' -exec basename {} \; | sed -e 's/\.control$//' | sort

Em geral, se não souber para que serve, ignore as bibliotecas (lib*). Elas serão instaladas automaticamente quando os pacotes que dependem delas forem instalados.

A terceira sugestão é fazer um backup completo de todo o /overlay. Afinal de contas, falamos de poucos megabytes mas que são fruto de algumas horas de trabalho. A cópia pode ser feita com um tar. É provável que você não tenha espaço para criar este tar diretamente no roteador. Você terá que fazê-lo jogando em um disco externo conectado pela USB ou, a forma que eu geralmente uso, diretamente pela rede. Pela rede seria assim:

meucomputador$ ssh root@roteador tar -czv /overlay | cat > overlay.tar.gz

A vantagem deste backup é que, se esquecer de colocar algo em /etc/sysupgrade.conf, você poderá recuperá-lo do arquivo tar.gz. Também, se precisar retornar ao firmware antigo, você já teria uma partição overlay pronta. Bastaria instalar a firmware antiga e jogar o conteúdo da overlay por cima (preferencialmente em modo de recuperação!).

Agora, finalmente, você está pronto para enviar a nova firmware. Se você usa um espaço externo para expandir o disco, leia até o final deste post. 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/barrier_breaker/14.07/..../openwrt...xxx...img
sysupgrade openwrt...xxx....img 

Agora é a hora que você reza.

Se optar por preservar as configurações, tudo que seria guardado em um backup do sistema, inclusive o que está listado em /etc/sysupgrade.conf, será automaticamente levado ao novo sistema. Depois de o sistema iniciar na próxima versão e estiver funcionando, é hora de retornar os programas antigos. Se você guardou a lista dos programas instalados após a gravação da firmware que sugeri anteriormente, já terá a lista do que instalar.

A mudança nas versões dos pacotes é esperada e pode ser desconsiderada. Para facilitar, tente instalar primeiro os pacotes que dependem de outros, como os pacotes luci-app-*, antes de instalar os demais. É provável que, pela cadeia de dependências, grande parte será automaticamente instalada. Repita a geração dos programas instalados, a comparação e a instalação até estar satisfeito.

Não é comum no OpenWRT mas pode existir alguma atualização de segurança importante, como ocorreu com o Heartbleed. Na versão 14.07 apareceu uma vulnerabilidade do hostapd, que faz autenticação dos usuários. Se sua rede possui clientes não confiáveis (principalmente se você é um alvo em potencial), é bom atualizar. Os arquivos com a vulnerabilidade estão na imagem original e não foram atualizados. Para corrigir, você precisa instalar após a gravação da firmware. Esta atualização ocupará espaço a mais do seu disco (overlay) pois apagar ou substituir arquivos existentes na firmware original não recupera o espaço em disco usado.

Se quiser atualizar e estiver com espaço livre na overlay, a atualização é simples:

opkg update
opkg list-upgradable

E faça um "opkg install xxx" para os pacotes "xxx" listados. Ex:

opkg install wpad-mini hostapd-common

No futuro, novos pacotes com problemas de segurança podem ser atualizados e aparecerão no list-upgradable.

Por fim, faça um novo backup geral. É sempre bom preservar o seu trabalho.

Hum, e eu que uso um disco externo para expandir o espaço interno? É um pouco mais complicado... Ao atualizar o sistema, você terá um kernel novo que é incompatível com os módulos de kernel existentes no disco externo ou mesmo com as bibliotecas deste 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 o disco externo. Se você seguiu minha sugestão, você ainda terá um ambiente básico funcional. Com isto, ele vai usar somente a flash interna (com a configuração que você tinha antes de usar o disco externo). Faça todos os backups novamente, preservando os anteriores.

Agora à instalação.

Ainda com o disco externo desconectado, instale a nova firmware. Faça uma configuração básica, que será o que você terá caso o roteador seja ligado sem a unidade externa. Caso tenha optado por não preservar as configurações na gravação, você pode aproveitar o backup gerado ainda na versão anterior mas com o disco desconectado.

Agora precisamos nos livrar de todos os arquivos da versão anterior do OpenWRT presentes no disco externo. No disco externo, na partição usada como overlay, remova todo o conteúdo ou mova tudo para um subdiretório (ou para outro disco 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 do disco externo (que no mínimo será reinstalar os pacotes necessários). Reinicie o sistema. Você deve estar com mais espaço em disco agora.

Neste ponto, você ainda terá as mesmas configurações que tinha quando usou o sistema sem o disco externo. Envie o primeiro backup da versão anterior feito ainda com o disco externo e siga os passos de reinstalação dos pacotes, assim como é feito para ambientes sem o disco expandido. 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 14.07, que ainda podem funcionar nas versões 12.09 e 10.03.1.

Até mais.

OpenWRT: Barrier Breaker (14.07)

Salve pessoal! Mais um artigo da série do OpenWRT.

Quem está acompanhando as notícias do mundo de TI deve ter notado que foi lançada uma nova versão do OpenWRT, a Barrier Breaker (a.k.a BB, 14.07). Como fazem dois anos desde a última versão estável, é uma significativa mudança. Então quer dizer que eu vou atualizar e minha vida vai mudar?! Não é bem assim. Dependendo do caso, você nem vai notar. Afinal, o que a BB trouxe de novo? Vamos aos destaques:

• Kernel atualizado para 3.10

Isto traz diversas correções, atualizações de drivers e outras funcionalidades desde o kernel 3.3. Se você nunca precisou olhar qual a versão do kernel no seu OpenWRT, provavelmente não sentirá diferença. Existe diversas correções para problemas com placas atheros, mas parece que nem todos os problemas antigos foram sanados. Atualização: mas resolveu todos os que eu tinha ;-)

• Suporte nativo IPv6

Para sortudos que já tem acesso à redes IPv6 nativa, a nova versão do OpenWRT deve ser uma das mais adaptadas ao mundo de pilha dupla. Para os demais, continuamos a depender de gambi... estratégias de contorno técnicas como túneis, que já comentei anteriormente. Você vai observar também o surgimento de uma nova interface wan6, dedicada ao suporte IPv6. Ela muda a forma de configurar IPv6, a exemplo do uso de túneis. Devo atualizar o artigo de IPv6 em breve.

• Novo init: procd

O procd seria o equivalente ao systemd no OpenWRT. Com a alteração, os scripts de iniciação dos serviços precisam de ajustes. Caso tenha feito algum, deve ser necessário atualizá-lo. Como ele substituiu o hotplug2, pode ter algum efeito colateral nos scripts em /etc/hotplug.d/, como as funções acionadas por botão. Entretanto, parece que ao menos nesta versão, ele tem comportamento compatível com scripts antigos.

• Suporte a snapshot e rollback

Ainda não tive a oportunidade de mexer neste recurso mas ele permite que você crie fotos de seu ambiente (no caso, as mudanças da overlay) e permite que você retorne a um estado anterior em caso de falha. Contudo, isto mexe um pouco a forma de trabalho, exigindo que você explicitamente save o estado atual do disco antes de reiniciar o roteador. Vou deixar isto para um artigo futuro.

• Pacotes atualizados!

Entre os diversos pacotes disponíveis no OpenWRT, muitos sofreram atualização. Isto pode trazer aquele recurso que você sentia falta e nem sabia. Ou não.

• Novo tema no Luci

Esta sim é uma mudança perceptível! A parte de "melhoria visual" é pessoal mas achei o novo tema mais limpo.

Se nenhum dos itens acima te motivou, resta o argumento do suporte. A versão anterior cairá em desuso. Neste blog, por exemplo, todos os novos trabalhos serão em relação ao BB. Deixarei as referências ao AA e posso citar como deveria funcionar na versão anterior mas as configurações não serão testadas. O mesmo vale para fóruns, wiki e outros meios.

E algum motivo sério para não atualizar? Sim, se você tem uma conexão com a internet de mais de 180MBit/s. Houve relatos de redução na capacidade de roteamento via NAT, antes em algo como 240Mbit/s, com a atualização. Provavelmente é um problema do kernel ou mesmo do compilador (ou uma interação entre eles). De qualquer forma, vai ser difícil a solução. Melhorias já ocorreram na versão em desenvolvimento mas são marginais. Simplesmente falta capacidade de processamento da CPU (lembre-se, ela normalmente roda em algo como 400Mhz!).

Se você está neste limite e precisa de algo mais rápido, provavelmente o firmware original seja o mais indicado. Ele possui o recurso de aceleração de NAT por hardware, que libera o uso da CPU. Com ele, você vai poder realizar NAT a quase a velocidade do fio (uns 900MBit/s). Como não existe um driver aberto para este recurso, dificilmente ele estará no curto prazo no OpenWRT. Acredito que quem está com uma conexão internet via fibra de mais de 150Mbit/s já deve ter trocado o roteador de R$100 por algo melhor ;-)

Logo vou atualizar o artigo de atualização do OpenWRT para incluir o BB.

E a próxima versão? CC? Sim, Chaos Calmer. Prometeram para o final deste ano mas acho difícil. Não acredito no prazo não tanto pela base do OpenWRT mas sim pelos pacotes extras, os feeds. Muitos pacotes estavam abandonados e desatualizados. Um dos prováveis motivos era a necessidade de enviar as atualizações via lista e esperar a boa vontade de alguém com permissão de commit para aplicá-lo. Isto pode funcionar para o núcleo do OpenWRT mas não é muito prático para as várias centenas de pacotes extra. Desta forma, os pacotes anteriores foram congelados em oldpackages e uma nova fonte foi construída no github. Se seu pacote favorito já não estiver no novo repositório do github e você não quiser que seu pacote desapareça do OpenWRT CC, você pode adotá-lo. Eu já fiz a minha parte adotando o ruby.

Até a próxima.

OpenWRT: Configurando o QoS - Configuração

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

Dando continuidade ao artigo anterior sobre QoS, vou apresentar uma configuração simples de priorização de pacotes.

O antigo anterior foi sobre tráfego de dados em rede e o problema do congestionamento. Aproveitei para esclarecer que o QoS não vai deixar sua internet baixando mais rápido. Vai sim dar agilidade para as aplicações que necessitam de resposta rápida e minimizar as consequências do congestionamento no seu link.

Congestionamento no link ocorre quando está chegando mais pacotes do que a conexão consegue enviar. Com isto, começa a formar uma fila no roteador que, quando cheia, irá descartar novos pacotes até que a fila tenha espaço. Isto é esperado pois é uma forma implícita de avisar o emissor da informação que, em algum ponto até o destino, um segmento de rede não está suportando tanto dados e ele deve reduzir a velocidade. Grande parte das transmissões de dados buscam enviar progressivamente a maior taxa de transferência possível. Consequentemente, irá ocorrer sempre o congestionamento no segmento mais lento. O congestionamento é, portanto, um comportamento normal e, inclusive, esperado. O problema é que a fila formada pode ser muito longa.

Normalmente, nossa conexão com a internet é o segmento mais lento de nossos usos da internet. Desta forma, a fila do tráfego que sai do seu computador para a internet (upload) se formará no seu roteador e o que vem da internet para sua rede no roteador da provedora de internet. Quanto ao tráfego que forma fila no nosso roteador, temos controle total e o QoS irá operar sem problemas. E o download? Já em relação ao download, os controles são limitados. A fila do tráfego se forma no roteador da operadora (que fica lá dentro da infraestrutura dela e o roteador que ela deixou na sua casa). Neste, não temos como criar filas com priorização para reordenar os pacotes. O comportamento simplificado é este:

1. Você pede para baixar um arquivo de 700MB no servidor;
2. O servidor envia progressivamente o arquivo com uma taxa de transferência cada fez mais alta;
3. A taxa de transferência de envio supera a taxa de download do seu link com a internet. Começa a formar fila no roteador da operadora;
4. O servidor ainda não sabe disto e continua a aumentar a taxa de transferência;
5. A fila no roteador da operadora enche. Pacotes são descartados
6. O servidor nota a perda de pacotes e pega mais leve. Reduz a taxa de transferência (e volta ao passo 2. até terminar o arquivo)

Então vou poder atuar somente no upload? Não, o QoS será mais efetivo no upload mas atuará no download. Apesar de não poder criar filas com priorização diferenciada no roteador da operadora, com muita sorte, elas fizeram o dever de casa e implementaram um QoS "legal" lá (¯\(ツ)/¯), mas não (e o marco civil da internet não proíbe que seu provedor configure o QoS por critérios técnicos, a exemplo do que iremos implementar aqui). O controle possível do lado do cliente é simular que a velocidade mais lenta está na sua rede interna. Quando o seu roteador notar que a taxa de transferência está atingindo o pico da sua conexão, ele supõe que esteja começando a formar fila no roteador da operadora. Nesta situação, antes de encher a fila no lado de lá e descartar pacotes, o seu roteador simulará um comportamento de congestionamento da rede interna. Como? Ele descartará pacotes. Quê?! Isto é bom? Sim! Lembre-se que o problema são as filas. Fica assim o comportamento (com destaque na mudança):

1. Você pede para baixar um arquivo de 700MB no servidor;
2. O servidor envia progressivamente o arquivo com uma taxa de transferência cada fez mais alta;
3. A taxa de transferência de envio supera a taxa de download do seu link com a internet. Começa a formar fila no roteador da operadora;
4. Seu roteador nota que a conexão está congestionada (ou quase) e supõe a formação de fila no roteador da operadora. Descarta pacotes antes da fila encher.
5. A fila no roteador da operadora permanece pequena.
6. O servidor ainda não sabe disto e continua a aumentar a taxa de transferência;
7. O servidor nota a perda de pacotes e pega mais leve. Reduz a taxa de transferência (e volta ao passo 2. até terminar o arquivo)

Mas o download não pode deixar o download mais lento? Pode. Ligeiramente mais lento e provavelmente você nunca irá perceber. O que você irá perceber é que os demais pacotes (como a negociação de três passos do TCP, uma conversa VOIP, etc) irão chegar antes. Conexões UDP que exijam mais do que sua conexão, entretanto, não terão o mesmo efeito. Contudo, elas normalmente não são usadas para volume de dados e se beneficiarão da ausência de fila dos pacotes TCP.

Outro porém é se a sua rede local for mais lenta que a sua conexão internet. Para redes locais sem fio, principalmente quando esta estiver com baixa qualidade e a internet for bem rápida (algo acima de 20Mbits/s), pode ser possível que a fila de upload se forme no seu computador e a de download no seu roteador. Isto está incentivando padrões mais rápidos de wireless, como a 802.11ac.

Chega de papo, vamos a configuração.

O QoS é implementado pelo próprio kernel do Linux. A interface usada para configurá-lo é via o comando tc em conjunto com regras do iptables. Lidar diretamente com o tc é um pouco complicado, principalmente para quem não tem nem intimidade com o terminal. Para facilitar a vida, foram criados alguns pacotes para simplificar a configuração do QoS e evitar que você veja o tc. Um dos mais populares é o qos-scripts. Ele é limitado mas deve atender 97,23% dos casos.

Uma vantagem é a existência da configuração web para este pacote. Para instalar ambos, instale o "luci-app-qos". Se for configurar "na mão", basta o "qos-scripts".

Pela interface web Luci, acesse "Rede/QoS". As opções gerais são simples. Você vai habilitar a configuração e configurar a "Velocidade de recebimento" (download) e a "Velocidade de envio" (upload). Você pode usar valores um pouco abaixo do observado para garantir a atuação. A opção "Calcular overhead" já faz um pouco desta redução. O "half-duplex" indica se seu download e upload influenciam um no outro. Normalmente não é o caso pois temos taxa de download e upload fixas definidas pelo plano.

Dúvidas:

P: Se eu configurar o download acima do que eu tenho?

R: O QoS não irá atuar.

P: Se eu configurar abaixo?

R: Ele vai limitar sua conexão a esta velocidade. Meu provedor aumentou minha conexão de 1Mbit/s para 5Mbit/s e só fiquei sabendo quando ele enviou o aviso do "presente" pelo correio.

P: E se meu provedor fornece velocidades variáveis?
R: Se ele não fizer o QoS do lado dele, senta e chora. Lembre-se que você compra 1Mbit/s mas ele não precisa entregar exatamente isto todo tempo... Como a variação será para baixo, vai cair no caso da primeira pergunta.

Falta apenas as regras de classificação. Existem 4 classes por padrão na interface web:

• prioritário: para pacotes pequenos como DNS e o ACK do TCP
• expressa: para pacotes maiores com urgência, como VOIP e jogos Online
• baixa: para transferência sem urgência e volumosas (torrent, dropbox, backup)
• normal: para demais casos

A configuração pode ser feita por endereço de origem, de destino, serviço (identificado pelo layer7), protocolo de transporte, porta de destino ou volume de dados trafegado.

Por padrão, pela interface vemos as seguintes regras:

• DNS e SSH são prioritários;
• FTP, HTTP, SMTP, POP, IMAP, SMB são normais;
• AIM/ICQ (nostálgico) são expressos.

Ainda existe algumas regras ocultas, só visíveis no arquivo de configuração:

• UDP com pacote menor que 500 bytes é expresso;
• ICMP é prioritário;
• Portas 1024-65535 são baixa;
• TCP com pacote menor que 128 bytes de pedido de conexão (SYN) ou confirmação (ACK) são prioritários

Sugiro sempre usar a interface web para, ao menos, criar uma configuração inicial. Se quiser se aventurar no arquivo de configuração, ele é bem legível e fica em /etc/config/qos.

Por fim, habilite e dispare o serviço QoS em Sistema/Inicialização.

Ah, se for testar outra alternativa de QoS (como o wshape dsl-qos-queue ou o wshaper), desative o qos-scripts. Nunca use mais de uma estratégia de QoS ao mesmo tempo! Você também pode montar na mão regras usando o iptables e o tc. Será um belo aprendizado.

Até a próxima.

OpenWRT: Configurando o QoS - tráfego de dados em redes de computadores

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

Já tive mais de um pedido para escrever como configurar o QoS (Quality of Service) no OpenWRT. Mas por que configurar o QoS? Para que serve isto? O QoS são regras de priorização dos pacotes. Quando sua conexão com a internet está com folga, o QoS pouco ou nada vai te ajudar. Ele vai fazer diferença quando você estiver usando toda a velocidade disponível (com sorte, a que você contratou ;-) ).

Antes de começar, algumas perguntas e respostas (curtas) frequentes:

P: Usando QoS vou fazer downloads mais rápidos (terminar antes)?

P: Posso melhorar minha velocidade de recebimento (download)?

P: Posso melhorar minha velocidade de envio (upload)?
P: Posso aumentar meu upload reduzindo o download?

R: Não

P: Estou falando no Skype e está picotando a voz. Com QoS vai melhorar a qualidade?

R: Depende se você está usando a internet também para outras coisas.

P: Se estiver somente usando a internet para o Skype?

R: Não

P: Se estiver baixando um filme ao mesmo tempo que falo no Skype?

R: Sim!

O "falando no skype" pode ser substituído por outros serviços em tempo real como "jogos online (FPS, MMORPG)" ou mesmo a resposta do navegador quando você clica em um link.

Ao final deste post, estas perguntas são revisitadas com mais detalhes.

Para entender o QoS, precisa entender um básico de redes. Este artigo será uma breve explicação do tráfego de dados em redes de computadores.

---

Uma analogia usada frequentemente na comparação com tráfego em uma conexão é o transporte rodoviário. A ligação de rede de internet é uma estrada onde não são permitidas ultrapassagens e todos os veículos trafegam com velocidade constante. Os dados transportados são como a carga levada nos veículos. Os veículos, por sua vez, são os pacotes de rede.

A "velocidade contratada da internet" é a quantidade de carga que você pode transportar por tempo, não a "velocidade dos veículos". Para os mais puristas, usa-se o termo taxa de transferência ou rendimento da rede. Largura de banda tem relação com os sinais e não diretamente com a taxa de transferência. Entretanto, todos estes termos são frequentemente usados como sinônimos. Se um Kbit fosse um quilo, a velocidade de 10Mbits/s seria, nesta analogia, transportar 10 toneladas por segundo, não importando a quantidade de veículos ou a sua velocidade. Em geral, nossas conexões residenciais são assimétricas (o "A" do ADSL), onde a taxa de transferência de ida (upload) é menor que a de volta (download).

O tempo de viagem do veículo é a latência da rede. É fundamental para usos multimídia (VOIP, Skype, videoconferência, jogos online). Para estes usos, é muito melhor ter uma taxa de transferência e uma latência menor do que uma taxa de transferência enorme mas com alta latência. Na analogia, não adianta ter a capacidade de transportar 10 toneladas mas por um caminho mais longo se sua encomenda é um pacote pequeno que precisa chegar o quanto antes (latência baixa).

As conexões podem ser divididas quanto a sua abrangência. Redes locais (Local Area Network - LAN)  tem alcance curto, mas normalmente taxa de transferência alta e latência baixa. Já redes "longas" , (Wide Area Network - WAN), no caso a sua conexão com a internet, tem normalmente características inversas: taxa de transferência baixa e latência alta. Seguindo na analogia, as LAN são as ruas da cidade, onde a viagem é curta e o tempo é (ao menos deveria ser) menor. Elas também são capazes de um grande volume de tráfego. Já uma rodovia, pela distância, tem um tempo de viagem maior ("latência alta") e pode transportar menos carga (taxa de transferência baixa).

Para possibilitar a transição das ruas da cidade (rede local) com a rodovia (conexão com a internet), é necessário um ponto de ligação. Em geral, é onde eles colocam a praça de pedágio. Na sua rede local, é onde se localiza o seu roteador.

Como ocorre no transporte rodoviário, quando as ruas enviam mais carros do que a rodovia pode absorver, ocorrem filas. O mesmo ocorre quando um servidor na internet envia dados para você a uma taxa maior do que sua conexão está preparada para receber (ou vice-versa). No roteador, estas filas tem tamanho fixo. Caso fique cheia, os "carros a mais" são catapultados para fora da pista (os pacotes são descartados) sem aviso ao emissor ou receptor.

Vamos imaginar que estamos enfrentando um congestionamento. Nesta caso, existe uma longa fila antes de chegar na rodovia (conexão com a internet). O veículo pode ser simplesmente descartado (se a fila estiver cheia) ou ter que aguardar a sua vez chegar para poder entrar na rodovia. Isto aumenta o tempo da viagem (a latência da sua conexão). Dependendo das configurações, o atraso nesta fila pode ser na ordem de  alguns segundos.

Outra característica importante é como ocorre a negociação da transferência. O TCP, usado na grande maioria das vezes que você faz algo na internet, opera simplificadamente desta forma:

1. E: Manda um pacote para o endereço R, dizendo que eu quero enviar uma carga;
2. R: OK, recebi, responda a E que ele pode enviar;
3. E: OK, avise o R que eu recebi o seu OK e vou mandar a carga;
4. E: Mande 1 pacote com carga;
5. R: OK, recebi, 1 pacote;
6. E: Receberam todos. Vamos mandar mais! Mande 2 pacote com carga;
7. R: OK, recebi, 2 pacote;
8. E: Receberam todos. Vamos mandar mais! Mande 4 pacote com carga;
9. R: OK, recebi, 4 pacote;
10. E: Receberam pacote. Vamos mandar mais! Mande 8 pacote com carga;
11. R: OK, recebi, 7 pacote;
12. E: Ops, perdemos um pacote! Acho que a fila está cheia. Vou mandar menos. Mande 6 desta vez.

Vamos por partes, a começar pelo início. Note que são necessários 3 pacotes para apenas pedir ou enviar dados. Imagine que a fila entre a sua rede local e a conexão com a internet esteja com tal tamanho que um novo pacote leve 3 segundos para passar por ela. Só para chegar o primeiro pacote com dados daquela página que você queria acessar, demoraria mais de 9 segundos (3s no passo 1; 3s no passo 3; 3s para pedir a página no passo 4).

Outro detalhe é que o protocolo busca sempre encher a fila! Só recua quando algum pacote é recusado pois a fila já está cheia. Então, se você estiver anexando uma foto no e-mail, sua fila de envio estará cheia. O resultado será o atraso no skype, na navegação, etc. Este atraso pode, inclusive, iludir o emissor que o destino não recebeu os pacotes pois a confirmação ainda está na fila e o tempo de espera se esgotou. Isto faria com que ele reenviasse os pacotes já recebidos.

E os pacotes perdidos, não são um problema? Não! Em situações normais, são perdas mínimas (menos de 1%). Esta perda de pacotes é usada como sinal de congestionamento. O problema mesmo é a formação de filas. Elas podem ser muito grandes (grande problema hoje da internet conhecido como BufferBloat). Esta fila única também não é adequada para diferentes serviços. Alguns aproveitariam bem uma fila maior (transferência de grande volume de dados) enquanto outros se comportariam melhor com filas menores (Skype). Contudo, perda de pacote acima de 1%, normalmente provocada por falha física ou extremo congestionamento, torna a navegação uma tarefa impossível.

Solução? Faça filas de tamanhos diferentes para cada tipo de aplicação. Voltando a analogia do trânsito, seria uma praça de pedágio com diversos guichês. Como a rodovia é uma pista simples, somente um carro sai por vez. Nas filas com maior prioridade, as filas teriam tamanho máximo menor. Entretanto, seriam mais "selecionadas" para liberar carros mais rapidamente. As filas usadas para maior volume teriam seus veículos mais retidos. Isto é QoS.

Voltando as perguntas frequentes, agora com respostas longas:

P: Usando QoS vou fazer downloads mais rápidos (terminar antes)?

P: Posso melhorar minha velocidade de recebimento (download)?

P: Posso melhorar minha velocidade de envio (upload)?

R: Não. A taxa de transferência é característica da conexão e é pouco afetada por variações na latência. Os valores de download e upload são definidos pelo plano contratado.

P: Estou falando no Skype e está picotando a voz. Com QoS vai melhorar a qualidade?

R: Depende se você está usando a internet também para outras coisas.

P: Se estiver somente usando a internet para o Skype?

R: Não. Como você somente está usando o Skype, a fila é ocupada apenas pelos dados do Skype.
Ele normalmente tem um bom algoritmo para reduzir a necessidade taxa de transferência e evitar filas no roteador. Se estiver picotando, é o outro lado ou a sua conexão não aguenta nem mesmo o mínimo necessário. Sugestão? Desligue o vídeo ou aumente seu plano da internet (ou da pessoa do outro lado).

P: Se estiver baixando um filme ao mesmo tempo que falo no Skype?

R: Sim! Podem ser criada filas para cada característica de uso dos protocolos. Para os casos com maior volume de transferência (torrent), uma fila maior e com menor prioridade. Para Voip, uma fila menor com alta prioridade. Acesso HTTP é mais complicado pois pode ser tanto uma atividade que exige resposta rápida (navegação) como alto volume de dados (download). Porém, pode ser indiretamente beneficiado ao colocar protocolos conhecidos que usam alto volume de dados com menor prioridade.

Para avaliar sua conexão de internet, fica a sugestão de dois testadores:

• http://simet.nic.br/medidor/
• http://netalyzr.icsi.berkeley.edu/

Estes testes informam, além da taxa de transferência e da latência, uma medição do jitter, que é a variação na latência entre diversos testes. Quanto menor, mais estável é a sua latência (mesmo ela sendo alta ou baixa).

O próximo post será sobre a configuração do QoS no OpenWRT. Até a próxima.

OpenWRT: Compartilhando um Scanner na rede

No último artigo, mostrei como configurar uma impressora de rede no OpenWRT. É grande a comodidade de uma impressora na rede. Fazê-lo com uma impressora simples e sem custos (considerando que o roteador você já tem) é melhor ainda.

OK, impressora já está configurada e imprimindo pela rede. Mas o scanner?

Atualmente são raras as impressoras puras. Em geral elas agregam outras funções, principalmente um scanner. Neste post vamos configurar o SANE para permitir que máquinas remotas possam digitalizar documentos pela multifuncional na rede.

Instalação

Vou considerar que partimos do ponto onde já existe uma impressora USB configurada no roteador. Se não for o caso, talvez algum passo da impressora fique pendente (talvez a parte do USB). Se alguém estiver nesta situação (quer somente o scanner pela rede e não a impressão) e tiver problemas, comente ai que tentaremos diagnosticar o que falta. O mesmo vale para conectar um scanner (não impressora). Se ele funciona em um Linux (pelo SANE), deve funcionar.

Antes de começar, você vai precisar de alguns mega de espaço em disco. Se não estiver usando uma unidade USB para estender o disco, esta é a sua oportunidade.

Você vai precisar instalar os seguintes pacotes do OpenWRT:

• sane-backends
• sane-frontends

Ele vai baixar mais alguns por dependência. Se tudo der certo, o comando "scanimage -L" deverá mostrar sua impressora. Se for uma HP, você vai precisar do pacote hplip. Infelizmente ele traz consigo dependências não desejadas, como o cups (eu avisei que precisaria de espaço...). Após a instalação, o scanimage vai funcionar para scanners HP:

root@router:~# scanimage -L

device `hpaio:/usb/Officejet_J4660_series?serial=BR145GXXXXXXXX' is a Hewlett-Packard Officejet_J4660_series all-in-one

Agora basta colocar o SANE para escutar na rede. Você precisa colocar os endereços (cliente ou de rede) autorizados a usar seu scanner em /etc/sane.d/saned.conf. Se quiser liberar acesso para qualquer cliente da rede, basta adicionar um +:

root@router:~# echo + >>  /etc/sane.d/saned.conf

Podemos testar já neste ponto se os clientes podem alcançar o serviço. Rode o saned manualmente:

root@router:~# /usr/sbin/saned -d

Ele vai funcionar para um único comando, mas é suficiente para testar. Possivelmente ocorrerá um erro:

check_host: getaddrinfo for local hostname failed: Name or service not known

Isto ocorre porque o saned não conseguiu achar o endereço IP pelo nome do roteador. Você precisará adicionar este nome manualmente no /etc/hosts. O nome adicionado deve ser o mesmo que aparece no prompt do shell (após o "@" e antes do ":"):

root@router:~#

No meu caso, basta colocar "router" depois de localhost em /etc/hosts. Ficou assim:

127.0.0.1 localhost router

Pule para a configuração de um cliente e, se funcionar, volte para este ponto e complete a configuração do servidor.

Configuração do servidor

O sane depende de um superserver, um processo que espera por conexões e as repassa aos respectivos servidores. Isto simplifica o desenvolvimento do servidor e pode economizar memória (por poder disparar o serviço apenas quando alguém irá usá-lo).

Neste caso, a sugestão é instalar o xinetd. Instale o pacote xinetd do OpenWRT.

Atualização: para impressoras multifuncionais, o uso do SANE faz com que o módulo usblp remova a entrada /dev/usb/lp0, que é usada para impressão. Desta forma, a impressão não funciona mais após o uso do scanner (até que a impressora ou o roteador sejam reiniciados ou o cabo reconectado). Para contornar o problema, sugiro a criação deste script /usr/sbin/saned.reload_usblp:

#!/bin/sh
#
# When a SANE scanning occurs, /dev/usb/lp0 is lost.
# Reload usblp after the scanjob is finished in order to
# recreate /dev/usb/lp0 
#
/usr/sbin/saned "$@"
rmmod usblp
insmod /lib/modules/$(uname -r)/usblp.ko

Ele precisa ter permissão de execução.
Atualização 3: a nova versão do OpenWRT (14.07) não apresenta este problema. 

Você precisa criar o arquivo de configuração do SANE para o xinetd em /etc/xinetd.d/sane com este conteúdo:

service sane-port
{        
  socket_type = stream
  server = /usr/sbin/saned
  protocol = tcp
  user = root
  group = root
  wait = no  
  disable = no
}      

Basta disparar o xinetd e habilitá-lo para ligar com o roteador:

/etc/init.d/xinetd enable

/etc/init.d/xinetd start

Seu scanner deve estar funcionando!

Clientes

Vou mostrar a configuração de um cliente em Linux. Quando estiver rodando em Windows, eu completo a parte do Windows e atualizo este artigo.

Linux

Em geral, as distribuições Linux já pré-instalam o SANE. Se for seu caso, basta editar /etc/sane.d/net.conf para configurar o SANE a buscar um scanner na rede. Só colocar uma linha que aponte para seu roteador. No meu caso, eu consigo alcançá-lo por router.lan. Pode ser também o IPv4 ou IPv6 dele. Para os mais acomodados, rode como root:

echo router.lan >> /etc/sane.d/net.conf

Lembre-se de ajustar o router.lan apropriadamente. Na sequência, o scanimage vai listar o scanner da rede.

cliente-linux $ scanimage -L

device `net:router.lan:hpaio:/usb/Officejet_J4660_series?serial=BR145GXXXXXXXX' is a Hewlett-Packard Officejet_J4660_series all-in-one

Note que diferentemente do scanimage no roteador, neste existe referência de que ele está na rede e no servidor router.lan. Se isto não funcionar, existe algum problema com seu saned. Para diagnosticar o problema, se estiver rodando manualmente o "saned -d", observe as mensagens na tela. Caso já esteja rodando ele no xinetd, olhe os logs do roteador (logread).

Se estiver rodando manualmente o "saned -d", depois do scanimage, ele irá encerrar. Para utilizar o scanner, você deve completar a configuração do servidor.

Windows

No Windows temos duas alternativas. A que recomendo é o wiasane. Ele cria um scanner virtual que acessa (via SANE) o scanner remoto. As versões atuais funcionam sem problemas em todos os meus testes.

Outra é o SaneTwain. Pode ser o zip ou o instalador windows. Ele é composto de um driver Twain e um aplicativo independente. Infelizmente, o driver só está preparado para ambientes 32-bit. Contudo, o aplicativo funciona perfeitamente. Depois de instalado ou descompactado, você terá acesso ao programa ScanImage.exe. Ele pode ser usado diretamente como um cliente do scanner. Na primeira execução ele irá permitir a confiuguração do servidor SANE (seu roteador). Ele deve ser suficiente para quem quer digitalizar para um arquivo de imagem. Porém, não consegui fazer o driver TWAIN funcionar possivelmente por estar em um sistema 64-bit (li comentários que funcionou mesmo o desenvolvedor avisando que não iria).

---

É isso pessoal. Mais um ótimo uso para seu OpenWRT. Até a próxima.

PS: Ainda está na fila a divulgação automática da impressora na rede por ZeroConf.

Atualização: adicionado workaround para problema de impressão após o uso do scanner. Obrigado Felipe por ter avisado da existência do problema.

Atualização 2: driver wiasane está funcioando na versão wiasane-v0.0.0.5-16-gfab7d78-dbg. Logo deve sair uma versão oficial com o problema resolvido. Versões atuais do driver não devem apresentar o problema.

Atualização 3: versão nova do OpenWRT funciona sem o workaround!