Pojawił się kolejny problem: wygląda na to, że dropbear dosyć długo trzyma urwane połaczenie - o ile w przypadku zwykłego ssh nie stanowi to problemu bo po prostu łączymy się kolejny raz na nowym połaczeniu, ale w przypadku tunelowania nie da rady drugi raz otworzyć tego samego portu i próba zestawienia tunelu jest odrzucana. Wydaje mi się, że mogła by pomóc opcja  -I <idle_timeout>  z czasem np. 2 - 3 minuty, ale nie wiem jak wpisać to do skryptu startowego... no i nie wiem czy to mają być minuty czy sekundy.
Jeśli się nie mylę, to będzie gdzieś /etc/init.d/dropbear linia 53 - args="......  ewentualnie dopisać to elegancko żeby można było wprowadzać w /etc/config/dropbear

No i niestety - cegła. Było już wszystko OK to podkusiło mnie wgrać 1.5.6. Teraz ruter nie odpowiada w żaden sposób - udało mi się dwa razy na ~100 prób wbić do bootloadera i zobaczyłem napis executing boot script... ale ctrl c nie zadziałało. Chyba jedyna szansa to podlutować się pod RS.

Nie znam tematu, ale w takim razie po co zrzucają z HSPA na UMTS skoro wszystko jedno?
Prawdopodobnie HSPA zajmuje większe pasmo (radiowe) niż UMTS. W ten sposób zwalniając jeden kanał HSPA robi sie miejsce dla kilku (kilkunastu?) UMTS.

Jeżeli pingowanie pomaga, to można zrobić listę hostów i pingować po kolei albo losowo, żeby nikomu nie przyszło do głowy zablokować gdzieś pingowanie.
Można też pingować z większym pakietem, ale rzadziej.
Obawiam się jednak, że takie są uroki sieci komórkowej - jak tak wszyscy zaczną pingowac i siedzieć na HSPA+ to w końcu zacznie wywalać kogoś losowo. To zależy oczywiście od obciążenia sieci, ale zawsze znajdzie się moment przeciążenia (najazd turystów, promocja w markecie itp.) a z drugiej strony sieć nieobciążona to marnowanie zasobów
Warto by się skupić na tym, żeby wracało samo do połaczenia HSPA+ jak tylko może, i jest nam to rzeczywiście potrzebne.

Nie mam żadnego firewalla. Jeśli przetuneluje np VNC na ruter to nic mi z niego - bo nie mam ekranu ale np próbując telnetem mam:
telnet localhost 5900
RFB 003.008
czyli vnc się zgłasza. Natomiast na kompie:
telnet <adres_rutera> 5900
mam:
telnet: Unable to connect to remote host: Connection refused
czyli nic z tego.
Ale sprawdziłem też tunelując serwer apache z innego komputera na mój i na moim widzę stronę na localhost:8989, natomiast na innym w mojej sieci: <adres mojego komputera>:8989 już nie.
Wydaje mi się, że tak to ma działać niestety... ale jak bym chciał się połączyć do mojego ruterka już bezpośrednio klientem vnc... to trzeba znowu pokombinować.

Edit: już wiem, nic nie trzeba kombinować, tylko wpisać 0.0.0.0 - wtedy akceptuje połączenia z dowolnego adresu.

Akurat na tego co chcę to openssh już mi nie wejdzie.

Zrobiłem jeszcze jeden eksperyment: Bitvise łaczy się przez tunel do kompa na Ubuntu, ruterkiem zrobiłem tunel do Ubuntu, natomiast na swoim kompie zrobiłem jeszcze jeden tunel do ruterka... i działa - czyli nie przeszkadza mu protokół VNC.

Uniwersalna komenda: screen -d -R
Jak masz uruchomionego screena to się do niego wbijasz, jak nie, to odpalasz nowego.

Jak ktoś lubi paranoidalne zabezpieczenia to jest coś takiego jak port knocking.

A widzisz - tematu gphoto nie znałem - a to prawdopodobnie dlatego, że może i obsługuje większość aparatów, ale jak widzę 0% z tych co mam/miałem
Teraz pozostaje poszukać taniego aparaciku (powiedzmy do 300zł), który to w pełni wspiera i zacząć zabawę.

Bootloader też można wyłączyć ale nie tędy droga. Przede wszystkim trzeba podglądnąć co się dzieje na tym RS - (za pomocą trzeciego urządzenia ?) - co blokuje i w którym momencie. Jeśli masz jakiś wpływ na to urządzenie co wysyła dane, to oczywiście zmiana protokołu tak, żeby nie kolidował z bootloaderem (najlepiej dwustronna komunikacja z potwierdzeniem). Ostatecznie można kombinować z opóźnieniem ale jeśli już miałbym dawać przekaźnik, to sterowany z gpio routera i niech to on go przełączy jak będzie gotowy - przy czym nie musi to być wcale przekaźnik - zależnie od rozwiązania układowego routera i peryferiów wystarczy tranzystor lub nawet zwarcie linii gpio z wejściem rx.