Nie pomaga kombinacja CTRL + C ?

Dodam, że w sytuacji gdy mnie już wpuści i dam (np) komendę wyświetlenia logów, to dostaje kilkanaście/kilkadziesiąt linijek tekstu i znów router "przykuca". Po jakimś czasie następna partia, itd. Jeśli nie dotykam terminala (nie wykonuję konkretnych poleceń) to jest ok. Widzę, że router odpowiada bo mogę wciskać ENTER. Jeśli w trakcie oczekiwania na wynik dam jeden enter więcej to dostaję timeout z terminala PuTTY i sesja zostaje zerwana.

Nie, nie mam nic sensownego w top'ach. Pamięć wolna, procesor też.

W tej chwili zdalnie (OpenVPN).
Reboot nie pomaga. Wyłączyłem część usług i nic. Jedyna zmiana od kiedy router działał dobrze to OWFS'a. Pod spodem jest przejściówka USB->RS232 (na PL2303). Po uruchomieniu 1-Wire i OWFS'a chodzi kilka dni i siada. Zaznaczam, że może być to zbieg okoliczności.

Co odpalasz co 5 min?

Czy jest coś co może pisać na internal'a przy uruchomionym external'u? Mam wrażenie, że FS internal się zapchał. Część komend mogę wykonać, a ls'a na /etc już nie.

W sytuacji odłączenia, reboot (wersja soft) by zapewne wystarczył. Dojadę do domu to sprawdzę. Na razie będę starał się unikać hard-resetu. Wydaje mi się, że gdy zrobiłem go w analogicznej sytuacji tydzień temu, router już nie wstał.
Cezary, po konfiguracji exroot'a, przy konfiguracji innych aplikacji, przy podawaniu ścieżek, ma znaczenie jaką ścieżkę podam: 1. /etc; 2./overlay/etc? Jeżeli tak to jaka jest różnica?

# df -m
Filesystem           1M-blocks      Used Available Use% Mounted on
/dev/root                    4         4         0 100% /rom
tmpfs                       62         2        60   3% /tmp
tmpfs                        1         0         1   0% /dev
/dev/sdc1                 1637       200      1353  13% /overlay
mini_fo:/overlay             4         4         0 100% /

Czyli bezpośrednio w"/" tylko i wyłącznie?

PS Nie działa mi "ls /etc/rc.d/". Działa "ls /overlay/etc/rc.d/".

Sprawa wyjaśniona. Opiszę pokrótce o co chodziło.

Opis problemu:
Problem występował przy łączeniu terminalem ssh do router'a. Efekt był taki, że wykonywanie niektórych komend (np "cat" pliku) powodowało zawieszenie komunikacji na około 5-6 minut (czas ten w innych przypadkach może być oczywiście inny). Inne komendy działały natomiast bez problemu (np. "opkg update"). Różnica miedzy nimi w gruncie rzeczy polega na ilości zwracanych przez daną komendę danych (znaków). Gdy owa ilość jest za duża, terminal zawiesza się oczekując na dane, które po prostu wolo do niego docierają. Ponaglanie terminala (zależnie od aplikacji klienckiej ssh) zazwyczaj kończy się całkowitym zerwaniem sesji.
Wbrew temu co wcześniej mówiłem, problem występował tylko w sytuacji gdy komunikowałem się z router'em przez tunel VPN (OpenVPN). Przy bezpośrednich połączeniach w sieci LAN problem nie występował.

Fachowcem w tej dziedzinie nie jestem, więc wybaczcie ew. błędy.
Przyczyną takiego stanu rzeczy jest wielkość MTU (Maximum Transmission Unit), który próbuje przesłać serwer do klienta (i vice versa). Wielkość MTU dla danego tunelu zależy od "jakości" owego połączenia. Stabilną wielkość MTU można podobno dla danego tunelu "wybadać" (opcja mtu-test). Tu jest opis jak można zaradzić problemowi.

Mój przypadek był jednak nieco inny. Na moim nadajniku ciągle coś kombinują (jest powiedzmy... "świeży"). Z jakościa połączenia jest różnie. Często jest to połączenie słabej jakości. Na przykład, mimo tego, że wczoraj miałem 70% zasięgu, występowały w/w problemy. Zastanowiło mnie jednak to 70%, bo normalnie mam 100%. Przeczyściłem i poprawiłem wtyk anteny i jak ręka odjął wróciło 100% zasięgu i tym samym poprawne działanie tunelu.

Dobiło mnie to trochę bo siedziałem nad problem pół dnia rozgrzebując co sią da. Lepsze jednak dla mnie takie zakończenie niż scenariusz problemów ze sprzętem czy jego oprogramowaniem prowadzący do potrzeby przeniesienia konfiguracji mojego RSPRO na inną maszynę i system.

CP