aviso para dispositivo 4/32

Dispositivos com apenas 4 MBytes de memória Flash ou apenas 32 MBytes de RAM provavelmente não funcionarão com as versões modernas do OpenWrt (19.07, 20.0x e mais recentes). Aqui está o porquê:

Todo sistema operacional requer

1. Flash suficiente para acomodar a imagem do firmware
2. RAM suficiente para operação estável

RAM insuficiente para operação estável

• 32 MB mal podem funcionar para funções mínimas de roteador/AP, mas podem “travar” repetidamente, dependendo do seu hardware e caso de uso
• 64 MB ainda pode ter problemas de estabilidade, dependendo do seu hardware e casos de uso
• 128 MB ou mais é recomendado se o software além da funcionalidade básica do roteador/AP for usado

Flash insuficiente para acomodar a imagem do firmware OpenWrt

• 4 MB é o mínimo absoluto (mas você não conseguirá instalar a interface da web do LuCI)/8 MB mal é suficiente (vai caber no LuCI e em alguns outros aplicativos)/16 MB oferece mais flexibilidade
• Dispositivos de 4 MB não cabem em nada digno de nota, a menos que você use o Image Generator (Image Builder) (que requer um sistema Linux e alguma experiência moderada) ou use Extroot. Usuários experientes que criam construções customizadas podem ser capazes de Economizar espaço de firmware, mas muitos pacotes não caberão, não importa o que você faça.
• Se você quiser ter certeza de que pode instalar pelo menos alguns pacotes de software adicionais, 8 MB (ou mais) de flash e 64 MB (ou mais) de RAM são a única escolha.

Muito provavelmente, você não conseguirá instalar os seguintes pacotes populares (e outros) em um dispositivo com flash de apenas 4 MB:

• VPNs e qualquer outro pacote que requer criptografia
• Samba (pastas partilhadas)
• Suporte dongle 3G/4G
• drivers/ferramentas do sistema de arquivos para formatar e verificar um sistema de arquivos para Extroot

Como o master atual (e a próxima versão 20.x) usa kernel 5.4 que é aproximadamente 0,5 MB maior do que o kernel 4.14 usado nas versões 19.07.x antigas, o espaço livre disponível em sistemas flash de 8 MB será bem pequeno nas próximas Versões OpenWrt.

Com o tempo, está ficando mais difícil, ou mesmo impossível, oferecer suporte a dispositivos com baixo Flash + RAM.

A limitação de 32 MB de RAM é mais difícil do que o tamanho do flash. O Linux 5.4 atual mal funciona com um sistema de 32 MB de RAM e picos no consumo de memória podem facilmente travar o roteador com erros OOM (Out-of-Memory).

O suporte OpenWrt para esses dispositivos terminará com a versão 19.07, e o. 19.07 será o último lançamento com suporte para dispositivos de 4/32 MB. Não haverá lançamentos futuros e nenhuma imagem pronta para download após 19.07.

Os usuários que não são usuários especialistas do OpenWrt (aqueles que podem construir suas próprias imagens) devem considerar

16/64 como um mínimo absoluto para qualquer dispositivo, com pelo menos 128 MB de RAM sendo preferido.

Os usuários devem esperar que os dispositivos com menos de 16 MB de flash e/ou 64 MB de RAM possam ficar instáveis ​​na operação básica nas versões atuais do OpenWrt (17.X, 18.X). Eles também devem esperar que o suporte para o dispositivo possa ser interrompido a qualquer momento e que patches/atualizações de segurança para o kernel, drivers e/ou software de aplicativo não estejam disponíveis. Embora não haja garantia de suporte contínuo para qualquer dispositivo sob OpenWrt, aqueles com recursos insuficientes correm grande risco de “fim do suporte”.

Versões anteriores do OpenWrt (como versões anteriores de 17.01.x, 15.05.x “Chaos Calmer” e anteriores) contêm vulnerabilidades de segurança agora conhecidas no kernel, implementação sem fio e/ou código do aplicativo. A comunidade OpenWrt não pode suportar a execução de código vulnerável conhecido em qualquer situação. “É apenas meu roteador” não é uma justificativa, pois o comprometimento do roteador pode causar impacto em outros como um ponto de salto, comando e controle ou outro participante de um ataque. Em muitos casos, essas vulnerabilidades conhecidas estão sendo ativamente direcionadas, potencialmente incluindo por Advanced, provável ator patrocinado ou afiliado ao estado ou atores.

Como exemplo, o tamanho da imagem de lançamento do sysupgrade para WNDR3700v1, um dispositivo ar71xx/ath79 que é compatível com o Openwrt há dez anos:

master/20.x: 4736.1 KB
19.07.3:       4096.3 KB
18.06.8:       3712.0 KB
17.01.7:       3584.0 KB
15.05.1:       3584.0 KB
14.07:         3328.0 KB
12.09:         2816.0 KB

O principal motivo é o crescimento do próprio kernel do Linux, mas todos os pacotes básicos incluídos (wi-fi, LuCI, etc.) também tendem a crescer conforme seus recursos são expandidos.

Conforme escrito em esta postagem do fórum pelo usuário do fórum slh.

Em primeiro lugar, não pretendo falar pela equipe LEDE, no entanto, olhar para os números simples apresenta uma situação bastante óbvia.

Pegando “Por que nenhuma imagem foi gerada para o DIR D-Link padrão -600A1? “Como um exemplo (sim, alguns outros dispositivos flash de 4 MB são um pouco melhores do que este espécime em particular, a tendência continua a ser a mesma).

D-Link DIR-600A1:
Backfire 10.03.......................: 2293764 bytes
Backfire 10.03.1.....................: 2949124 bytes
Attitude Adjustment 12.09............: 2883588 bytes
Barrier Breaker 14.07................: 3276804 bytes
Chaos Calmer 15.05...................: 3342340 bytes
Chaos Calmer 15.05.1.................: 3407876 bytes
LEDE 17.01 release branch............: 3473412 bytes
tamanho absoluto do firmware.........: 3735576 bytes
tamanho máximo de firmware utilizável: 3538944 bytes

(todas essas figuras são para imagens de lançamento, incluindo luci e um conjunto de recursos mais ou menos idêntico).

O tamanho do bloco de apagamento para este (e muitos outros) dispositivos é de 64 KB, então agora você acaba com 256 KB (== 4 blocos de apagamento) de espaço livre, em comparação com 320 KB (== 5 blocos de apagamento antes). Embora possa parecer confortável à primeira vista, você deve considerar que o espaço livre só pode ser atribuído em blocos de tamanho (completo), então, uma vez que você toque na partição de sobreposição, você já terá um bloco de apagamento em uso (64 KB ) Portanto, as ferramentas de criação de firmware usadas pelo LEDE impõem reserva de pelo menos 3 blocos de apagamento para o sistema de arquivos de sobreposição (é daí que vem o tamanho máximo de firmware utilizável, em comparação com o tamanho total da partição de firmware). Em outras palavras, com o 17.01 você terá apenas 1 bloco de apagamento (64 KB) antes do limite rígido, enquanto o 15.05.1 ainda oferece 2 blocos de apagamento sobressalentes (128 KB) para seu próprio uso. Além disso, há a sobrecarga do sistema de arquivos necessária para a formatação para jffs2 também (jffs2 faz alguma compressão leve, mas seu cabeçalho fs e log (mais ou menos entradas de diretório) precisam de algum espaço, então há o requisito difícil de manter alguns espaço livre (no bloco de apagamento == blocos de 64 KB) para a coleta de lixo funcionar) em todos os momentos, reduzindo ainda mais o espaço livre utilizável. Cerca de 25 KB são usados ​​pela sobreposição de configuração imediatamente após o firstboot, antes de você realmente ter a chance de configurar qualquer coisa.

Supondo estatísticas puras, qual será a situação em 12 ou 24 meses [1]?

Ninguém ainda levantou a sugestão de realmente remover o suporte de hardware para dispositivos afetados do repositório de origem do LEDE. Se você olhar mais a fundo, ainda pode encontrar suporte completo para Linksys WRT-54GL (4 MB flash, 16 MB RAM) no repo, embora o suporte para dispositivos com apenas 16 MB de RAM já tenha sido descontinuado com o Ajuste de Atitude 12.09 e apesar do fato de que construir um firmware atualizado e funcional para este dispositivo hoje é bastante desafiador [2].

Este tópico serve apenas como um lembrete para 'usuários normais', que esperam fazer o download e piscar o LEDE na expectativa de usá-lo como um substituto completo para o firmware do fornecedor (incluindo uma interface web, luci). Também tenha em mente que o luci está habilitado para compilações de lançamento, o que significa que ele se encaixa na imagem do firmware (com a margem de segurança obrigatória de pelo menos 3 blocos de apagamento) ou nenhuma imagem de liberação pode ser criada para os dispositivos afetados [3], [4]. Na minha opinião pessoal, isso precisa ser documentado de forma bastante óbvia, evitando criar falsas esperanças e expectativas para os usuários (especialmente os novos).
Os usuários avançados obviamente serão capazes de atrasar o inevitável por alguma margem - dependendo de seus casos de uso e habilidades para reduzir a pegada do LEDE abaixo dos requisitos normais do sistema.

Apesar do título, o tamanho da RAM é na verdade um limite muito mais difícil, afetando muito mais do que apenas dispositivos flash de 4 MB. Se você olhar através do log de commit, você notará alguns esforços para fazer o opkg usar menos RAM, mas ainda é um problema com apenas 32 MB de RAM (mesmo para operações normais, antes de tocar no opkg). Da mesma forma, você já está com problemas com o sysupgrade e tentando atualizar um firmware (maior) de 6-8 MB em um dispositivo com apenas 32 MB de RAM, a menos que você realmente limpe os serviços e carregue os módulos do kernel manualmente de antemão, há um alto risco de você Serei durante a atualização do sistema e bloqueará seu dispositivo para sempre (exigindo assistência do bootloader/tftp para recuperar no melhor dos casos).

[1] mudar de arquivos mach para árvore de dispositivos (pós 17.01) oferece um potencial para liberar um pouco de espaço no kernel, mas isso não é muito e provavelmente será consumido mais ou menos completamente com a atualização para o kernel 4.9+ (também tenha em mente que o arquivo FDT precisa ser anexado à imagem do kernel, que pode ou não compactar tão bem quanto os arquivos mach anteriores), portanto, não espere um efeito positivo significativo desta mudança.

[2] sem webinterface, melhor sem pppd, algumas configurações personalizadas para obter os requisitos de memória de tempo de execução do kernel tão pequenos quanto possível, desabilitando tudo o que for humanamente possível (definitivamente sem IPv6, melhor sem wireless também).

[3] com o novo recurso do LEDE de imagens rootfs específicas do dispositivo, seria tecnicamente possível decidir entre instalar o luci ou omiti-lo por dispositivo, por exemplo, com base em tamanhos de flash, mas o suporte para algo como isso ainda não foi implementado e exigiria alguma atenção (tanto em patches de origem quanto na marcação de classes de dispositivo) das partes interessadas. Conforme implementado agora, a decisão é binária - ou a configuração padrão (versão) (incluindo luci) se ajusta ao XOR ao construir uma imagem de firmware para o dispositivo afetado falha e nenhum firmware estará disponível.

[4] Eu esperaria que já existissem alguns dispositivos flash de 4 MB na lista de alvos para os quais nenhum firmware de lançamento pode ser construído para 17.01, por causa de esquemas de particionamento de flash menos ideais escolhidos pelo fornecedor (deixando o espaço livre abaixo de 3 apagar blocos). Esses são provavelmente uma minoria, mas dados os números aproximados, eu ficaria muito surpreso se não houvesse nenhum afetado.

Mais explicações sobre este assunto pelo usuário do fórum slh.

Como originalmente escrito nesta postagem do fórum por jow.

Apenas fornecendo minha opinião bastante pragmática sobre o assunto aqui:
Não acredito em descartar arbitrariamente o suporte do dispositivo
Normalmente oferecemos suporte para dispositivos, desde que seja viável
Um dispositivo deve ser considerado compatível, desde que

• é possível construir imagens inicializáveis
• imagens pequenas o suficiente podem ser produzidas para ainda permitir a persistência da configuração
• não são necessários patches ou outras modificações no código-fonte e no buildroot

Eventualmente, podemos precisar pensar sobre níveis de suporte como:

• Full ⇒ permite a execução de gui, tem opkg funcionando e muito espaço para permitir pacotes
• Medium ⇒ permite a execução do gui, tem opkg funcionando e pelo menos espaço suficiente para configurar o extroot
• Small ⇒ imagens inicializáveis ​​podem ser construídas ao sacrificar gui ou opkg enquanto ainda tem persistência de configuração
• Micro ⇒ a única escolha são imagens personalizadas pesadamente ajustadas que requerem medidas especiais, como configuração pré-enviada, montagens NFS, extroot pré-configurado etc.