GSM prepaid

W dniu 2011-11-22 01:08, Elektrolot pisze:

To inicjuj komunikację z wewnątrz. Postaw sobie serwer VPN ze stałym IP (lub z dyndns) i wbijaj się na ten serwer klientem VPN siedzącym po stronie modemu. Wymaga to niestety aby te urządzenie GSM miało na pokładzie coś inteligentnego (np z linuksem), co potrafi być klientem VPN. Może to być nawet jakiś router za niewiele ponad 100pln lub oczekiwana od dawna Raspberry Pi :)

Elektrolot snipped-for-privacy@NOSPAMwp.pl napisał(a):

Tak, jak pisze Mario, to Twoje urządzenie może inicjować połączenie. I nie musi być to koniecznie VPN (chyba, że masz takie założenie, że ma być VPN). Można sobie np. założyć konto na serwerze Jabbera i przesyłać dowolne dane po XMPP między wieloma klientami.

Użytkownik "Elektrolot" napisał w wiadomości grup dyskusyjnych:4ecae804$0$2179$ snipped-for-privacy@news.neostrada.pl...

Nie VPN tylko APN chyba. Inna umowa, inne pieniadze.

Z VPN tez mozna, tylko twoje urzadzenie bedzie musialo byc odpowiednio oprogramowane i inicjowac kanal.

J.

W dniu 22.11.2011 11:26, J.F pisze:

OIDP to w orangutanie APN dla łączy z publicznym IP zaczyna się od VPN ;) (vpn.centertel.pl - głowy nie dam, bo miałem to jakieś 4 lata temu)

Inna opcja do wyjścia zza NATa to tunel ssh.

W dniu 2011-11-22 01:47, Mario pisze:

Dziękuję za sugestię. To mój pierwszy projekt z transmisją GSM wiec proszę o wyrozumiałość ;) Od strony urządzenia wyobrażam to sobie tak: SBC z Linuxem (uruchomiony klient VPN) + moduł UART/GSM. Czy w takiej konfiguracji będę się mógł komunikować ze swoim układem przez port szeregowy SBC?

Elektrolot napisał:

Dobrych kilka lat temu zrobiłem system w oparciu o podobne założenia. Działa do dzisiaj bez zmian (a ja wciąż "mam roota" na najwyżej położonym komputerze w Polsce). Wnioski mam takie:

1. Prywatny APN od operatora miałem, nawet niedrogo, ale działał kaprawo. Może coś się od tego czasu w komórkowym biznesie zmieniło, ale chyba nie warto się na to nastawiać -- korzyści wielkich nie widzę, a prepaidy przy takich założeniach a góry odpadają.
2. VPN nie używałem, ale tunel SSH działa. Lepiej lub gorzej, ale działa. Do zdalnego zalogowania się, grzebania w systemie i robienia rzeczy wcześniej nie przewidzianych się nadaje. Roboczą transmisję lepiej robić inaczej.
3. Samo połączenie ppp via GPRS może trwać bardzo długo (tygodniami), ale może również niespodziewanie przestać działać. Najwyraźniej z przyczyn leżących po stronie sieci. Nie że zostaje zerwane, tylko po prostu przestaje transmitować. Operatorzy się tym nie przejmują, bo wychodzą z założenia (słusznego), że po to to wszystko jest, by ludzie mieli internet w telefonie. Jak się coś zwiesi, to sami sobie poradzą. A tu trzeba połączenie nadzorować, robić próbne transmisje, jak coś nie działa, to resetować pppd.

W jakim sensie "się komunikować"? Że będzie przezroczyste połączenie przez port szeregowy? Ja bym takich założeń nie robił. Zawsze trzeba się liczyć z tym, że nie wiadomo kiedy wystąpi krótsza lub dłuższa przerwa w transmisji. Poza tym po coś ten linux tam jest, między innymi po to, by nie trzeba było liczyć na prymitywną szeregową transmisję. Przekazywanie danych z zewnątrz do urządzenia najlepiej (najprościej i najpewniej) zrobić w ten sposób, że urządzenie cyklicznie odpytuje serwer w internecie, czy ma coś dla niego. Jak ma, to bierze. Czyli

*w praktyce* jest tak, że komunikację inicjuje się z zewnątrz -- przez umieszczenie porcji danych na serwerze. To wszystko da się zrobić niezbyt długimi skryptami w Perlu (czy co tam kto lubi).

W dniu 2011-11-22 12:36, Elektrolot pisze:

Zrozumiałem że na porcie szeregowym SBC masz podpięty modem GSM. W tym sensie możesz się komunikować ze swoim urządzeniem (SBC) przez port szeregowy. Ale ten port szeregowy służy w tym momencie do obsługi netu poprzez ppp. Jak dobije się do sieci GSM to możesz się połączyć z serwerem i od razu wysłać dane. Ale twoje urządzenie nie ma stałego IP. Jeśli potrzebujesz wbijać się do swojego urządzenia z zewnątrz po stałym IP to najlepszy jest VPN bo klient na SBC autoryzuje się kluczem na serwerze (mającym stały IP internetowy lub dyndns) i serwer nadaje mu się w sieci "lokalnej" stały numer. W ten sposób łatwiej wykorzystać SBC jako serwer z danymi pomiarowymi np przez HTTP. Ale może być tak, że SBC jest klientem podsyłającym dane i wtedy nie potrzebujesz w nim stałego IP. Wspomniane przez kogoś tunelowanie ssh też nie jest konieczne bo możesz wysyłać jawnym tekstem. Wszystko zależy od poziomu bezpieczeństwa jaki potrzebujesz. Przesyłanie danych przez SSH jest strasznie powolne. Jeśli to pójdzie przez UART to przy większych plikach będzie to odczuwalne. Lepiej dać modem USB jeśli SBC ma hosta USB. Aby wszystko poprawnie działało musisz dołożyć skrypty sprawdzające połączenie i resetujące modem jeśli się zawiesi.

W dniu 22.11.2011 13:46, Jarosław Sokołowski pisze:

Zdradzisz co to za szczyt? Kasprowy? SMOK?

Pozdrawiam, Michał

Pan Michał Smolnik napisał:

Kasprowy, ale nie SMOK. Smoki leżą ze dwa metry niżej.

W dniu 22.11.2011 23:36, Jarosław Sokołowski pisze:

No to moje urządzenie leży dwa metry niej od twojego ;-)

Również sprzęt z IMGW?

Pozdrawiam, Michał

Pan Michał Smolnik napisał:

Nie "z", tylko dla.

W dniu 23.11.2011 11:50, Jarosław Sokołowski pisze:

Wcześniej "dla", po podpisaniu protokołu odbioru już "z"...

Przypuszczałem że IMGW, bo tam niewiele więcej jest.

Ja dla SMOKA projektowałem kontroler komunikacji a potem zjeździłem pół Polski uruchamiając infrastrukturę komunikacyjną. W tym roku wszedłem sobie z synem na Luboń od Tenczyna (tak jak kilka lat temu z plecakiem narzędzi) - antena mojego systemu jeszcze wisi. Masz kontakty z IMGW? Działa jeszcze ta sieć radiowa, czy pozostali tylko przy GSM?

Pozdrawiam, Michał

Pan Michał Smolnik napisał:

To wszystko może być dużo bardziej skomplikowane (reszta poszła mailem).