GPRS - opóźnienia

W dniu 20.05.2011 23:29, sundayman pisze:

Cześć

od 200 ms do pojedynczych sekund, a przy okazji ramki się stracić mogą....nawet w TCP/IP

Pozdrawiam Arek

sundayman takie ma pytanie do praktyków chyba:

Wysyłam co minutę *z* modułów *do* serwera w Internecie po kilkaset bajtów TCP. Z powodzeniem, od kilku lat.

Tak *przeciętnie*, to chyba ze 100-150 ms. Ale bywa, że kilkaset. W drugą stronę, to nie takie proste, bo moduł GSM podłączony do publicznego AP nie ma publicznego IP. Ale gdyby moduł miał (mógł) pobierać coś z serwera, to będzie tak samo. Można próbować zrobić tunel SSH i mieć możliwość inicjowania transmisji z obu stron, ale na GPRS to marnie działa.

Próbowałem z prywatnym AP od operatora, gdzie kilka modułów było w jednej sieci z prywatnymi IP, ale działało to tragicznie. Bywało, że pakiet leciał kilka sekund.

W dniu 20.05.2011 23:44, Jarosław Sokołowski pisze:

A to nie lepiej zrobić RESTowe zapytania z długo timeoutującą odpowiedzią? Urządzenie żąda dokumentu http i po kilku minutach dostaje odpowiedź (albo timeout).

Pan Michoo napisał:

Jasne, że lepiej. Opisałem sytuację zbyt skrótowo, pewne rzeczy umknęły. Jeśli terminal co jakiś czas inicjuje połączenie, to rzecz jasna można wymienić dane w obu kierunkach. I tak to w praktyce należy robić. Natomiast nie ma możliwości dobicia się do nieaktywnego terminala (bo jest za NAT). Tunel SSH też nie jest pewnym rozwiązaniem, o czym chciałem uprzedzić.

SSH ma te sama wade co zwykle TCP - to urzadzenie GSM musi zainicjowac polaczenie (TCP zreszta) a potem utrzymywac otwarte, zeby sie przez firewalla/proxy operatora przebic.

Ponoc niektorzy operatorzy pozwalaja na publiczne IP.

J.

Coś mieszasz. Mogę zrobić tunel ssh pomiędzy np, moim komputerem w domu a modułem gprs. Oczywiście demon ssh na komputerze a klient na gprs. Jeżeli chcę się połączyć w dowolnej chwili przez ten tunel z domu lub z innego miejsca na świecie (przez komputer w domu), to to połączenie musi być aktywne cały czas. Dlaczego niepewnym? Bezpieczeństwo przy ssh zależy właściwie tylko od siły hasła. Oczywiście połączenie może paść z tysiąca przyczyn - powinno być tak skonfigurowane, że nawiąże się ponownie jak tylko jest taka możliwość.

Mirek.

Pan J.F napisał:

Ale tunel SSH raz wykopany może (teoretycznie) trwać w nieskończoność. A jak się strop osunie, to od razu wiadomo, że trzeba drążyć na nowo. Wewnątrz tunelu można już normalnie prowadzić obustronną komunikację. Od tego tunelu całkiem niezależną. Ale to wszystko w teorii, bo w praktyce z GPRS działa marnie.

Wiem tylko, że prywatny APN może mieć również publiczne IP od operatora. A wtedy można przez różne sztuczki przeNATować porty połączenia PPP terminala z portami tego APN.

Mirek <i snipped-for-privacy@zaspamowany.adres napisał(a):

Wyłącz uwierzytelnianie hasłami i użyj kluczy.

Pan Mirek napisał:

Też mi się wydawało, że mogę.

Chrzanić bezpieczeństwo. Po prostu działa to niepewnie. Nie wiem dlaczego. Zdycha, a wtedy nie można się połączyć. Jak zdechnie, to oczywiście ma się na nowo samo odbudować (np. przez respawn w inittab). Ale najczęściej zdycha w ten sposób, że niby jest, ale nie działa. Taka śmierć kliniczna. Jak dobiję siekierą sshd, to terminal w końcu załapuje, że ma jeszcze raz zrobić tunel. Ale na nekrolg czasem musi czekać kilka minut albo dłużej. Nawet skróciłem klucze SSH do granic możliwości, żeby było mniej do transmisji. Praktyka jest mniej więcej taka, że prawdopodobieństwo zalogowania się w ciągu kwadransa jest bliskie stu procent. I to w zasadzie wystarcza. To oczywiście sprawa GPRS, bo jeśli połączenie realizowane jest inną drogą, to wszystko działa jak powinno (czyli jak nam obu się wydaje).

W dniu 21.05.2011 14:07, Jarosław Sokołowski pisze:

Można logować się po kluczu.

Ja m.i. wysyłam i czytam newsy po tunelu SSH i działa to całkiem nieźle ;)

A co długiego zdychania - czasami połączenie "sponiewierane" przez rozłączenie z siecią (wifi) wraca do życia po kilku minutach, ale jeżeli nie jest w stanie wrócić to zdycha przez kilkadziesiąt do kilku godzin.

Jeżeli jest konieczny deterministyczny czas odpowiedzi to bez heartbeat-a się nie da.

Dzięki serdeczne za informacje. No to nie jest tak źle jak się spodziewałem. Znaczy, poniżej 1 sek to już jest super, a minimalnie więcej też pewnie do przeżycia. Bałem się, że... no wysyłam, a jak będzie to przyjdzie :)

Generalnie to było pytanie testowe, bo dopiero kombinuję nad czymś tam, no ale jak zwykle koledzy nie zawiedli :)

Tak, że jeszcze raz dzięki.

Pan Michoo napisał:

Z serwera NNTP podłączonego przez GPRS?!

No to tu jest tak samo, tylko jeszcze bardziej. GPRS potrafi sponiewierać tunel co kilka minut.

sundayman napisał:

Najlepiej oczywiście wysłać list polecony za potwierdzeniem odbioru. Wtedy można wszystko samemu monitorować, mierzyć czasy i robić własne statystyki. To wszystko może być mocno uzależnione od lokalnej infrastruktury operatora.

Napisałem serwer w perlu, i szczerze mówiąc, już chyba nie pamiętam jak działa. Ale działa.

W dniu 21.05.2011 15:30, Jarosław Sokołowski pisze:

Nie, serwer NNTP to onet. Ja łączę się z laptopa po ssh do mojego serwera robiąc przy okazji tunel. A laptop do sieci podpięty po WIFI, ale *bywa* podpięty po GPRS przez bluetooth i generalnie daje się to używać.

To dość słabo - przez 2 godziny w pociągu (po GPRS właśnie) połączenie zerwane było może 4 razy.

Pan Michoo napisał:

Przez rok miałem GPRS jako jedyne łącze w domu. To było prawie dziesięć lat temu. Dało się żyć. Ale połaczenia *z* GPRS, to zdecydowanie co innego niż połączenie *do* komputera z GPRS przez tunel SSH.

A po co tunel w pociągu? Chyba że to ekspres Warszawa-Kraków. Nie będziemy się tu przechwalać, komu dłużej stoi, ale sesje PPP to ja w terminalach miewam po kilkadziesiąt dni. I nie ma w nich ani minuty przerwy, wszystko działa jak trzeba. Ale jak się loguję zdalnie na tych terminalach, to sytuacja wyglada zgoła inaczej.

W dniu 21.05.2011 21:58, Jarosław Sokołowski pisze:

Mój GPRS nie pozwala się połączyć "do" - jest NAT. Połączenie jest ustanawiane "z" po czym kopane są tunele - po SSH i VTUN (opcjonalnie też w SSH).

Zaczęło się od tego, że bezpieczniki zablokowały NNTP a niektóre strumienie sieciowe ich stanowy firewall tak gwałcił, że się nie dawało słuchać, VTUN, którego używam standardowo, był wycięty, więc zacząłem słuchać muzykę i czytać grupy po tunelu SSH. I tak już zostało.

W sumie ciekawa sprawa - czemu?

Pan Michoo napisał:

Każdy GPRS jest NAT. O innym nie słyszałem, chyba że z prywatnym APN. Ale ja się chcę łączyć "do", więc muszę robić tunel. I się łączę.

Chyba czegoś nie rozumiem, bo...

...bo co ma tunel do bezpieczników? Gdybym miał tylko taki problem, że z numerami dawanymi przez NAT opreatora miałbym gdzieś zablokowany dostęp, to bym starał się wystrugać jakieś proxy, a nie tunel.

Znowu nie rozumiem. Ja często czytam grupy (i piszę na nie) po SSH. Teraz na przykład. Ale nie przez tunel.

Generalnie, to pewenie z powodu opóźnień, które potrafią zrobić niezły bajzel w pakietach. A tak szczegółowo, to mi się nie chciało tego badać. Najbardziej nie chciało mi się gadać o tym ze "specjalistami" od operatora.

W dniu 22.05.2011 02:09, Jarosław Sokołowski pisze:

Afaik któryś z operatorów (idea?) pozwalał na takie skonfigurowanie połączenia, żeby mieć publiczne ip. (A domyślny nat był po to aby "chronić userów przed niechcianym ruchem".)

Tunel (port forwarding w terminologii ssh) robi właśnie "jakieś proxy" z mojego serwera.

Tunel najprościej było zestawić, bo i tak się łączę do serwera - wystarczyło dodać -L 9999:news.onet.pl:119

Jest to o tyle dziwne, że zdarza mi się uśpić laptopa, zrobić sobie herbatę, wybudzić i po kilkunastu - kilkudziesięciu sekundach mieć sprawne połączenie. Ale może chodzi o ilość ruchu.

Pan Michoo napisał:

A, to już z grubsza rozumiem idee. Ale to co innego. Mnie chodziło na przykład o "ssh -N -R9999:*:22 mój.serwer.pl" na terminalu, po to, bym na tym serwerze mógł napisać "ssh localhost 9999" i zalogować się na terminalu za NAT.

Że tak jest, to ja wiem. Ale z tunelami bywa inaczej. Czasem się sztucznie tworzy niewielki ruch, by utrzymać drożność dziury. Jednak w przypadku GPRS nawet to nie pomaga.