Discuta este tópico no fórum

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

segunda-feira, 27 de fevereiro de 2017

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

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

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

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

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

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

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

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

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

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

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

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

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

Até a próxima!

20 comentários:

  1. Olá Luiz instalei o LEDE, tentei instalar manualmente, baixei no diretorio /tmp e usei o opkg install, mas não deu nada. Teria uma sugestão?

    ResponderExcluir
    Respostas
    1. Olá Elias.

      O problema foi o comando. opkg é para pacotes. Você precisa do sysupgrade.

      Tenho um novo artigo saindo do forno sobre a atualização. Quando você ver isso já deve estar publicado.

      Excluir
    2. Muito obrigado Luiz, aguardarei.

      Excluir
  2. Não sabia dessa História até hoje Luiz, obrigado pela dica, pois no site do Openwrt esta dando moscas.

    ResponderExcluir
  3. Parabéns pelo blog... Eu estou entrando nessa onda de openwrt agora... Aliás LEDE.. RS
    Amigo, uma questão. Será que se eu instalar o LEDE firmware e solicitar que se mantenha a mesma conf, será que vai funcionar?

    ResponderExcluir
    Respostas
    1. Sim Denis, será o mesmo comportamento que ocorria na atualização de um OpenWRT.
      Por sinal, o OpenWRT vai voltar. Nos acordos de junção dos projetos, o código
      do LEDE vai "tomar" o nome OpenWRT.

      Excluir
    2. Tem alguma forma, usando opkg, de instalar todos os pacotes disponíveis? Quero dizer, hoje tenho que usar opkg install , teria alguma forma de fazer opkg install "tudo_que_estiver_disponível"?

      Parabéns pelo blog.

      Excluir
    3. Não pronto. Mas nada que um script não resolva.

      root@router.lan3:~# opkg list | awk '{ print $1 }' | xargs opkg install

      É um pouco exagerado. E você vai ter que tratar várias coisas. Tem pacotes que substituem versões simplificada de comandos, que exigirão parâmetros extra para permitir o conflito. Também tem pacotes que são alternativas como versao -full e -mini. Não faz sentido instalar ambos.

      Excluir
    4. Entendi.
      Obrigado pela dica.

      Uma outra dúvida, eu preciso mandar um comando AT pro modem e pegar a resposta, porém preciso fazer isso de forma automática, sem utilizar um terminal (minicom, picocom...). Algo do tipo echo "at...", mas como faço para pegar a resposta do comando (resposta do modem)

      Excluir
    5. Parece ser o caso de usar scripts pppd. Procura no google por exemplos.

      O expect não é específico para serial mas quebra um bom ganho:
      https://gist.github.com/tmbdev/5772607
      https://gist.github.com/ubinix-warun/9722490

      Acho que até algo como:

      stty -F /dev/minhaserial ....
      echo "ATxxx" > /dev/minhaserial
      read RESP < /dev/minhaserial

      Deve funcionar.

      Excluir
    6. Não funcionou. Não tem suporte para ramips.
      Pesquisei sobre o assunto e não achei nada aplicável a ramips.

      O máximo que consegui até agora foi pegar o que eu mesmo mandei para ttyUSB2, que foi o comando "IMSI" pra pegar o código do modem. Mas a resposta do comando, nada ainda.

      Teria alguma coisa sugestão ou exemplo?

      Teria como acessar remotamente para avaliar o cenário?

      Excluir
    7. Gabriel,

      É raro achar algo para ramips. Normalmente, se for código para compilar, você terá que fazer você mesmo.
      Eu iria por soluções que usam programas já disponíveis, como o expect, screen,...

      Quase tudo que você achar nesta lista poderia ser aplicado:
      https://www.google.com.br/search?q=script+serial+linux&oq=script+serial+linux&aqs=chrome..69i57j0l5.4192j0j1&sourceid=chrome&ie=UTF-8

      Lembre-se que é só um linux.

      Excluir
    8. Olá Luiz.

      Consegui resolver este assunto com gcom e processando resultado com awk, obrigado pelas dicas.

      Tenho outra dúvida no momento, como posso fazer para controlar o volume de dados trafegados por usuário da rede, como se fosse uma franquia, por exemplo 100MB por IP ou MAC, no openWrt.

      Grato pela atenção.

      Excluir
    9. Gabriel,

      Nunca vi soluções prontas que cortam o acesso depois de um certo volume.

      O que eu conheço (dos tempos do discado) é usar um RADIUS accounting ou coisa do gênero.
      Acho que o hostapd (que cuida da autenticação da wifi) tem suporte para isso.
      Agora, para o cabeado, é mais complicado. Teria que fazer um servidor pppoe ou
      coisa do gênero, também autenticando no RADIUS. Os clientes teriam que se autenticar,
      mesmo no cabeado.

      Veja, controlar volume implica na possibilidade de "roubo" de franquia. Para controlar direito, quase
      sempre você verá a solução associada a autenticação.

      Excluir
    10. Caro Luiz,

      Neste caso não haverá conexão cabeada, somente wlan.

      Poderia me dar um exemplo prático de uso com radius?

      Vou usar no openwrt, com 3g, por isso tenho que limitar.

      Grato pela atenção

      Excluir
    11. Não é algo simples. Além de mudar o hostapd para usar autenticação por 802.1X, você precisa configurar um servidor radius, que até poderia ser no roteador mas normalmente faz sentido ser centralizado. Precisa também de algum serviço de contabilidade de acumula os dados do radius por usuário e bloqueia o usuário quando ele passar do limite. Com usuário bloqueado, ele não autentica mais e será desconectado, no máximo na próxima autenticação de rotina.

      Não tenho nada parecido com receita de bolo, nem mesmo fiz algum dia uma prova de conceito. Com um radius externo, a parte do roteador fica em uma meia dúzia de linhas (sem exagerar). A parte da autenticação via radius é mais comum e até o Windows tem servidor nativo. Agora, a parte de accounting e, em especial, billing, é coisa mais para empresa. De quais forma, provavelmente essa parte ficará fora do roteador.


      Comece por aqui: http://lmgtfy.com/?q=Radius+billing

      Excluir
    12. Antônio, eu tenho internet 3g na roça onde possuo uma pousada, faço controle de cota através do RADIUS como o Luiz sugeriu, para gerencia do RADIUS uso o DaloRadius, ele faz o billing. No meu caso não uso 802.1X e sim chillispot (uso como sistema de hotspot com autenticação via browser).
      Como uso vários rádios, consigo roaming sem muita dificuldade.
      Boa sorte!

      Excluir
    13. Nada como alguém que já teve a necessidade antes! Obrigado Tiago. Realmente o chillispot é uma ótima alternativa, já que 802.1X é uma desgraça para clientes Windows não corporativos.

      Excluir
  4. Posso usar o arquivo sysupdade do lede para atualizar o meu que já esta com openwrt versão 15.05

    ResponderExcluir