Niestety ten router ma za mało RAMu by zapewnić komfortową pracę pod LEDE. Zalecane jest albo przelutowanie kości RAM albo wymiana routera na model z min. 64MB RAM i 8MB Flash (16MB Flash jest bardziej przyszłościowe).

SWAP może pomóc, jednak tylko na krótką metę. Zainstaluj OpenWRT Chaos Calmer dostępne na dl.eko.one.pl i sprawdź jak tam będzie się prezentowała sytuacja.

@Cezary

A OpenWRT w szczególności CC już umarło całkowicie?

MvincM

CC umarło. Samo openwrt umarło w sumie.

Z nowej biblioteki musl (zamiast uclibc). Po prostu wszystko skompilowane z nią wykazuje zwiększone zapotrzebowanie na ram.

Hmmm!!!!

Taka obserwacja... Może to nie wina LEDE... W sensie zapewne jest mocniej zasobożerną odmianą systemu (zgodnie z tym co piszecie) jednak nie wiem czy przyczyną nie jest program/demon "smstool3".

Po pierwsze ciężko wyśledzić bo reboot się robi i po logach... muszę logi przepiąć na pendrive to zobaczę więcej. Nie mniej jednak smsd loguje swoją prace do katalogu /tmp. Przy okazji te logi są duże w rozumieniu, że na bogato loguje. Ten plik z logami leży sobie w /tmp i go zapycha do zera wolnego. I teraz zapewne to, że LEDE wywala się przy logowaniu (udanym!) przez ssh jest powiązane z faktem, że ssh chce coś pisać do /tmp a tam zero miejsca i pewnie tak to się już dalej dzieje.

Odtwarzam sytuację na CC i sprawdzę ale już po jednym dniu log smsd zapchał mi /tmp a wykryłem to faktem, że nie utworzył się plik "/tmp/resolv.conf.auto" przy restarcie wan (z racji braku miejsca w tmp)  i przestał działać nazwijmy to "dns" tj. dnsmasq nie podawał adresów na zapytania klientów.

Resume:
- czy powyżej opisana sytuacja może prowadzić do reboot? Do czasu przepięcia logów na pendrive trochę zgaduje...
- czy ktoś miał przejścia z smsd i potwierdza niezbyt racjonalne zarządzanie logami?
- czy ma ktoś doświadczenie z logrotate dla openwrt/lede?

Dzięki i pozdrawiam,
MvincM