search

simetnicbr / simetbox-openwrt-feed

SIMETBox package feed for OpenWRT (comece aqui/start here!)
http://simet.nic.br/simetbox
GNU General Public License v2.0
74 stars 13 forks source link

Instabilidade do OpenWRT em roteadores com menos que 48MiB RAM #4

Closed hmh closed 6 years ago

hmh commented 6 years ago

O OpenWRT oficialmente não mais recomenda equipamentos com apenas 32MiB de RAM há algum tempo (recomendação originou-se no projeto LEDE). Os seguintes problemas foram reportados:

  1. Falha no sysupgrade por falta de memória (RAM) para a tmpfs
  2. Falhas de runtime por OOM (out-of-memory).

Observamos problemas de estabilidade em laboratório ao utilizar OpenWRT 2018 (OpenWRT snapshot) sem nenhuma alteração (ou seja, sem LuCI e sem o SIMETBOX) em roteador TP-Link TL-WR842NDv2 (32 MiB RAM, 8MiB FLASH).

Existem reports do próprio driver ath9k (802.11n/an) no kernel 4.9 causar problemas com 32MiB RAM devido a maior utilização de memória para buffers, etc.

A recomendação de possuir mais que 32MiB RAM já exista no LEDE 17.01. O TP-Link TL-WR842NDv2 funciona de forma satisfatória em carga leve, mas observamos problemas nesta plataforma durante tentativa de atualização de firmware, que são agravados quando a interface web é utilizada para atualização.

Provavelmente, o SIMETBOX só suportará roteadores com 32MiB cujo suporte de hardware exista no LEDE 17.01. Hardware novo, que dependa do OpenWRT 2018, terá que possuir mais memória (na prática, isso significa modelos com 64MiB RAM).

farribeiro commented 6 years ago

Ainda não tem um roadmap nem para suportar o novo WRT quanto a nova versão da distribuição, seja ela Debian ou Ubuntu?

hmh commented 6 years ago

O mais próximo de "Roadmaps" públicos que temos ficam em: https://github.com/orgs/simetnicbr/projects/1

OpenWRT LEDE-17.01 e 2018 (trunk) são suportados pelo código fonte do SIMETBOX aqui disponível. Utilizamos no momento Debian 9 e Ubuntu 17.10 para compilar código baseado em OpenWRT LEDE 17.01 e OpenWRT 2018 (trunk).

farribeiro commented 6 years ago

Farei um teste usando ao menos o atual Ubuntu em produção e LTS

hmh commented 6 years ago

Só para garantir, porque esta dúvida já apareceu antes: minha resposta refere-se ao ambiente de compilação do OpenWRT (com ou sem os feeds do SIMETBOX). Build nativo (ou seja, fora do OpenWRT) não vai funcionar sem alterações.

farribeiro commented 6 years ago

Realizado três build diferentes, a saber, usando o branches master de todos os projetos, com algumas variações do meu código master. Todas as instruções para criação dos containers se encontra nos links:

https://hub.docker.com/r/farribeiro/simetbox-openwrt/builds/bvrqeu3oyzsc7usqpvsnbq5/

https://hub.docker.com/r/farribeiro/simetbox-openwrt/builds/bjt2wgylk8cxtcsofpcwtfx/

https://hub.docker.com/r/farribeiro/simetbox-openwrt/builds/bzfln8bqyb4cqzfrfiqcu48/

Não conferi a documentação atual, creio que esteja de acordo!

hmh commented 6 years ago

Vamos mover essa parte dos builds para alguma outra issue onde seja on-topic?

farribeiro commented 6 years ago

Acredito que já tem...

Issue https://github.com/simetnicbr/simetbox-openwrt-base/issues/12 Issue https://github.com/simetnicbr/simetbox-openwrt-base/issues/2 PR https://github.com/simetnicbr/simetbox-openwrt-base/pull/7

Pode escolher aonde queria continuar o debate

hmh commented 6 years ago

(comentários off-topic sobre build env escondidos, para manter essa issue limpa sem ter que fechar e abrir uma nova) - administradores podem fazer isso no menu do comentário.

hmh commented 6 years ago

Detectamos em laboratório instabilidade durante sysupgrade (atualização do firmware) em equipamentos com LEDE-17.01 e 32MiB de RAM.

Via TFTP do bootloader, a atualização sempre funciona sem problemas (mas toda a configuração é perdida, etc).

A situação fica muito, mas muito pior se a atualização for feita via LuCI (interface web). Felizmente, o modo de falha aqui costuma ser a interface web "cair".

O momento crítico é a janela entre o upload do firmware para /tmp, e a aplicação do mesmo. O equipamento vai estar trabalhando com 8MiB de RAM a menos (ocupado pela imagem de firmware em /tmp) e com todos os processos ainda executando.

Quando o sysypgrade falha por problema de RAM, muitas vezes resulta em missflash (defeito do OpenWRT), e soft-brick. Para recuperar o equipamento, é necessário seguir o procedimento de flash via TFTP do bootloader.

O misflash indica defeito grave no sysupgrade do openwrt lede-17.01: ele mata todos os processos antes de começar o update, mas mesmo assim pode passar por situação de falta de memória durante o processo.

hmh commented 6 years ago

Alternativas sendo consideradas:

  1. Travar no LuCI (e apenas no LuCI), em equipamentos com 32MiB RAM (e apenas nestes) o sysupgrade, com mensagem indicando que a atualização deve ser realizada via SSH.

  2. Adicionar algumas medidas paliativas no sysupgrade:

    1. Derrubar todas as interfaces de rede, e remover todos os módulos do kernel que forem possíveis (relacionados a interfaces de rede);
      1. Remover tudo que for possível de dentro do /tmp (mas na simetbox normalmente não tem quase nada deste tipo em /tmp);
      2. Forçar drop de todos os caches e buffers. Infelizmente não libera quase nada, particularmente porque a squashfs precisa de buffers para funcionar, e vai alocá-los novamente quase que imediatamente.
      3. Garantir que vai ser feito reboot mesmo em caso de early-fail (antes de gravar firmware) devido às medidas acima.
      4. Adicionar suporte a SWAP em ZRAM e habilitar isso antes de sysupgrade (falta testar se isso é eficaz).

  3. Abortar sysupgrade sem ter feito nada, se memfree não for suficiente já com a imagem de firmware em /tmp. Aparentemente, precisamos de tamanho-da-flash+x, onde x deve ser cerca de 2MiB (ainda testando). Ou seja, 10 MiB "livres" (18MiB se contar a imagem de firmware que vai em /tmp), onde "livres" significa que o kernel vai conseguir liberar. Não podemos contar com o que estiver marcado como "cached" como "liberável", porque o conteúdo de tmpfs (como /tmp) fica em "cached" e é >90% deste.

  4. Tentar rastrear via console serial em equipamento de laboratório, o instante em que o sysupgrade decide fazer besteira mesmo com memória supostamente "limpa o suficiente" e causa missflash -- e se encontrar, enviar patch para openwrt upstream.

hmh commented 6 years ago

(problema do sysupgrade, lede-17.01. Acontece depois dele matar quase tudo, e desmontar as filesystems - busybox não estava mais disponível pro shell): [ 375.089714] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000a [ 375.103557] Rebooting in 3 seconds..

Kernel OK, mas squashfs danificada, mtd com besteira: [ 0.817204] m25p80 spi0.0: found s25fl064k, expected m25p80 [ 0.835212] m25p80 spi0.0: s25fl064k (8192 Kbytes) [ 0.840515] 5 tp-link partitions found on MTD device spi0.0 [ 0.846324] Creating 5 MTD partitions on "spi0.0": [ 0.851286] 0x000000000000-0x000000020000 : "u-boot" [ 0.858163] 0x000000020000-0x00000015fe50 : "kernel" [ 0.865321] 0x00000015fe50-0x0000007f0000 : "rootfs" [ 0.872396] mtd: device 2 (rootfs) set to be root filesystem [ 0.878292] 1 squashfs-split partitions found on MTD device rootfs [ 0.884715] 0x000000670000-0x0000007f0000 : "rootfs_data" [ 0.892327] 0x0000007f0000-0x000000800000 : "art" [ 0.899086] 0x000000020000-0x0000007f0000 : "firmware" ... [ 2.301687] squashfs: SQUASHFS error: unable to read id index table [ 2.308531] List of all partitions: [ 2.312196] 1f00 128 mtdblock0 [ 2.316334] (driver?) [ 2.318776] 1f01 1279 mtdblock1 [ 2.322925] (driver?) [ 2.325370] 1f02 6720 mtdblock2 [ 2.329502] (driver?) [ 2.331947] 1f03 1536 mtdblock3 [ 2.336095] (driver?) [ 2.338542] 1f04 64 mtdblock4 [ 2.342690] (driver?) [ 2.345137] 1f05 8000 mtdblock5 [ 2.349269] (driver?) [ 2.351706] No filesystem could mount root, tried: [ 2.356569] squashfs

-> misflash. Motivo: falha durante sysupgrade (17.01) após tudo morto...

hmh commented 6 years ago

Linha de ação:

(Lista de módulos que vale a pena considerar a remoção): 91696 ath9k 0 115728 usbcore 5 ledtrig_usbport,ohci_platform,ohci_hcd,ehci_platform,ehci_hcd 223808 cfg80211 4 ath9k,ath9k_common,ath,mac80211 332416 ath9k_hw 2 ath9k,ath9k_common 395072 mac80211 1 ath9k

hmh commented 6 years ago

Fora isso, kill_all de sysupgrade está permitindo que muitos processos escapem ilesos:

# Skip essential services
*procd*|*ash*|*init*|*watchdog*|*ssh*|*dropbear*|*telnet*|*login*|*hostapd*|*wpa_supplicant*|*nas*|*relayd*)

Isso deixa para trás uma quantidade considerável de processos por motivos dúbios, inclusive alguns do simet (o túnel reverso nas caixas do nic.br)

hmh commented 6 years ago

Está "bom o suficiente", mais que isso só alterando a fundo o sysupgrade para ele ser devidamente paranóico com tudo o que rodar...

Infelizmente, ainda observamos problemas no lab mesmo com este patch. O único sysupgrade seguro que nunca causou misflash por aqui foi o "sysupgrade -n", e aí neste caso só se persistirmos as configurações da simetbox na "núvem", o que é meio que impossível para a versão aberta da mesma.