NTG ale może...

Jeśli dobrze pamiętam, to w Ramnode mam podgląd na konsolę serwera (VPS) tak samo, jak w VirtualBoxie :) Nigdy z tego nie korzystałem ale jest.

Dokładnie.

jp

Proxy potrafi aktywne FTP zmienic. Klient GSM sle do serwera tekst "wyslij mi plik xxx na adres

10.0.0.100", a serwer dostaje "wyslij mi plik xxx na adres 200.100.50.25"

I tu sie moze przydac SMS jako lacznosc ostatniej szansy i wymuszenie polaczenia na zadanie.

Swoja droga - sa taryfy z bezplatnymi SMS, ale operator sie pewnie obrazi jak ich bedzie za duzo :-)

J.

W dniu poniedziałek, 12 czerwca 2017 14:40:56 UTC+2 użytkownik J.F. napisał:

mi kiedys zablokowali numer. Musialem zadzwonic i powiedziec ze: tak, ja zazwyczaj z tego numeru dzwonie na jeden numer i sobie długie pogawędki ucinam :)

Odblokowali i do dzis dziala ok :)

W plusie jest usługa "publiczne IP" kosztuje 5 zl (ip się zmienia) zamiast 20 zł za stały ip.

Tak właśnie - modem utrzymuje połączenie stale. Nic mi nie wiadomo o jakichkolwiek zastrzeżeniach PLAY co do tego (w regulaminie ztcw nic nie ma o tym, a i ich doradcy nic nie wspominają).

A ilość max. w moim przypadku to raczej setki - a i to na przestrzeni lat jakichś...

Ztcw to chyba najbardziej standardowe jest - jeżeli nie korzysta się z tej "chmury", bo wtedy to on coś tam sobie po swojemu robi. A "adres" serwera można podać albo w wersji cyferkowej albo jako nazwę.

Aplikacja moja. Wymiana danych jest w określonej "ramce" kilkudziesięciu bajtów. Oczywiście - dokładnie tak by to można zrobić jak napisałeś, gdybym chciał pozostać przy wersji "aplikacja na PC" - ten wirtualny COM na PC to dopiero pierwsze podejście - było najprostsze do zrobienia.

Jednak jeszcze bardziej by mi się podobała opcja z platformą tylu thingsboard - nie ma wtedy konieczności instalacji na PC, co jest kłopotliwe.

Nawet nie to, bo w pakiecie telemetrycznym jest chyba z 500 SMS. A użycie to jest max. kilka dziennie. Ale niestety działa to jak chce - a jak nie chce, to SMS przychodzą albo nie przychodzą, a jak już przychodzą to niekoniecznie wtedy kiedy są wysłane. Zostawiłem więc SMS tylko do powiadamiania o awariach - na telefon użyszkodnika.

Urządzeń jest 5 :) A rocznie będzie przyrastać może kilkadziesiąt. To nie jest produkt powszechnego użytku, tylko nadzór instalacji coś a'la przemysłowej. Więc żądania odczytania danych przez użytkownika są sporadyczne - nawet nie codziennie. Raz na jakiś czas - jak tam się użyszkodnikowi spodoba.

To jest do kontroli okresowej - a nie do stałego monitoringu.

Tyle, że ponieważ urządzenie ma zasadniczo być "responsywne" na zapytanie użyszkodnika, to to połączenie musi być w miarę stałe. To jest to samo co w przypadku np. kamer IP - też połączenie jest stałe, żeby user mógł podejrzeć wtedy kiedy chce.

ale tu mowa o SIM telemetrycznych - one mają też ileś tam SMS w abonamencie (powiedzmy 500). I dopóki się mieścisz nie ma problemu. No a jak by ktoś chciał 5000, to kosztuje to ileś tam dodatkowo.

PLAY bardziej interesuje (z rozmów z doradcami) czy te SMS to nie będą do "rozsyłania po ludziach" jakichś reklam itp. A jeżeli to jest M2M w ramach zamkniętej grupy, to nie robili żadnego problemu.

Nie czytacie... :) Pisałem już - tak, modem ma pełną obsługę i to w różnych "wersjach". Może być TCP/UDP albo HTTPD, są nawet komendy do wysyłania POST/GET itp.

Modem daje radę wszystko sam obsłużyć. To nie jest prosty modem GSM, w którym trzeba samemu wszystko zrobić.

No tak - jest taka możliwość w tym modemie. Czyli - jeżeli masz np. urządzenie połączone z PC via RS232, to podłączasz do niego modem, na PC instalujesz sterownik z wirtualnym PC

- i możesz to urządzenie wyrzucić za okno. A połączenie masz. Teraz tak to u mnie działa.

No ale po pierwsze to wymaga aplikacji na PC, po drugie - trzeba instalować ten wirtualny PC (to jest aplikacja producenta modemu). Całość trzeba odpowiednio skonfigurować itp. Nie jest to skomplikowane, ale zauważyłem, że jednak problematyczne dla informatyków w niektórych, zwłaszcza dużych firmach :)

Gdybym chciał "podrobić" ten ich serwer dla ich protokołu, to byłby kłopot (nie ma danych jak i co tam leci).

No ale - po co, skoro można normalnie - to jest tylko kwestia ustawienia modemu do TCP.

Tak - to tzw. conntrack. Ale w Playu widocznie tego nie bylo, poza tym i tak nie zadziala po TLS-ie...

Pytanie jaka role spelnia takie urzadzenie i jak krytyczna jest lacznosc z nim. U nas, jak padnie, to klient i tak nie moze korzystac i po prostu technik jedzie i wymienia :)

Bardzo dziękuję, na razie spróbuję jeszcze sam walczyć :) Jakby co będę pamiętać.

Te modemy też są tylko 2G. I właściwie, to już bywa problemem. Przy przesyłaniu bieżących ustawień to OK - daje radę.

Ale urządzenie ma "pamięć zdarzeń" na około 4000 wpisów. Całość to jest jakieś 32KB bodajże. No i kiedy użyszkodnik pobiera sobie te dane, to niestety przy prędkości

115Kbit to trwa dłuższą chwilę. Z tego powodu nawet ograniczyłem możliwość pobrania do 1000 zdarzeń, bo i tak to trwa kilkadziesiąt sekund.

Więc przejście powyżej 2G byłoby wskazane. W moim przypadku urządzenia są w miastach więc nie powinno być problemu. No ale to później nieco.

Czyli max kilkaset utrzymanych połączeń, ale wymiana danych sporadycznie? To myślę, że bez problemu da radę. Tylko sprawdź koniecznie, czy ten chiński soft ma jakieś keepalive'y, czyli czy jeśli połączenie z jakiegoś powodu po cichu umrze, ale modem nie zostanie o tym powiadomiony, to czy modem mimo wszystko wykryje taką sytuację.

Może się to zdarzyć z różnych powodów. W praktyce - u jednego z operatorów (jakiś wirtualny, nie pamiętam już nazwy, nie Play w każdym razie) nawet kontekst PDP po cichu sobie padał i keepalive'y nie pomagały :) Ale chyba już to rozwiązali.

Czytam czytam, tylko odpisuję w miarę czytania :)

Czyli chcesz z tego zupełnie zrezygnować, wywalić soft producenta i zrobić łączność sieciową samemu?

Jeśli tak, to musisz pamiętać o kilku rzeczach - tak na szybko:

1. Keepalive'y - żeby nie było sytuacji, w której połączenie będzie aktywne tylko teoretycznie, ale w praktyce będzie martwe (bo np. wyleci z tablicy połączeń gdzieś po drodze, a klient nie złapie RST)
2. Ponawianie połączeń - bo połączenie może umrzeć w każdym momencie i klient musi sam połączyć się znowu
3. Szyfrowanie połączenia - żeby nikt nie podsłuchał ruchu
4. Uwierzytelnienie klienta - żeby nikt łącząc się na port serwera nie mógł się podszyć za danego klienta
5. Możliwość zablokowania konkretnego klienta - w przypadku kradzieży modemu

Co będzie rozmawiało z modemem od strony klienta? Jeśli jakiś pecet lub coś, na czym uruchomisz Linuksa, to doradzałbym Ci postawienie tam VPN-a i stworzenie prywatnej, zamkniętej sieci, w ramach której będziesz miał dostęp do wszystkich urządzeń. OpenVPN wspiera to, o czym piszę, i umożliwia łatwe zrobienie mutual authentication (czyli że nie tylko klient weryfikuje certyfikat serwera, ale serwer weryfikuje certyfikat klienta - czyli oba muszą mieć swój tajny klucz). Warunkiem jest to, żeby komputer kliencki (czyli ten połączony z modemem kablem) miał zegar RTC lub możliwość pobrania czasu w inny sposób (choćby z Twojego VPS-a), bo bez tego sesja TLS się nie uda z powodu ważności certyfikatów.

Problem może być jedynie z tym, że OpenVPN spodziewa się interfejsu socketowego - nie będzie gadał z modemem jego funkcjami. To można rozwiązać na kilka sposobów, najprościej napisać jakieś małe proxy, które będzie odbierało połączenia na localhoście i łączyło się z serwerem już poleceniami modemu.

Czyli:

1. OpenVPN łączy się z localhostem (po socketach)
2. Proxy odbiera to połączenie
3. Proxy wysyła prośbę o połączenie do modemu
4. Proxy tuneluje ruch
5. Jeśli OpenVPN się rozłączy, proxy zamyka połączenie na modemie
6. Jeśli serwer zdalny się rozłączy (modem musi jakoś o tym powiadomić), proxy zamyka połączenie z lokalnym OpenVPN-em

Rozumiem, że masz na myśli chiński soft w modemie ? Modem ma możliwość np. ustawienia heartbeat z jakimś tam dowolnie wybranym ciągiem danych. Więc po stronie serwera jest możliwość sprawdzania, czy modem żyje.

Poza tym modem jest resetowany co ustalony czas (można wybrać) - np. co godzinę. Więc wszystko to jest w miarę bezpieczne i niezawodne.

Nawet gdyby nie miał, to urządzenie może też okresowo żądać jakichś danych sprawdzających. Ale to nie ma wielkiego znaczenia - jeżeli operator z jakiegoś powodu przez dłuższy czas nie może się połączyć, to po prostu wsiada pan technik i jedzie. A przyczyn może być więcej niż brak połączenia z internetem. Chociażby awaria zasilania lokalna. Ta komunikacja cała jest "dodakowym komfortem użytkowania" - nie musi być gwarantowana za wszelką cenę. Ot - ma działać bez większych problemów.

Jedyne kłopoty jakie się faktycznie pojawiły podczas testów (no bo to testy są cały czas) to awarie chińskiego serwera. A to padał całkiem, a to jakieś masakryczne opóźnienia itp. Ostatnio zrobili coś tam i jest lepiej, ale polegać na tym jest mocno ryzykowne. Poza tym niezgodne z linią partii - nasze POLSKIE dane mają lecieć przez Chińskie serwery ? Żeby nam Chińczyk dane germanił ?? To jest właściwie

- chinolił ??

Jak pisałem, połączenia są sporadyczne - ale nie może być tak, że user sobie chce sprawdzić co tam słychać, a tu akurat serwer żółtków leży... W dodatku jakoś tak bywało, że najczęściej ten ich serwer padał w godzinach 10-14. Czyli akurat u nas szczyt pracy. No to może letko denerwować...

Z siecią problemy były sporadyczne - głównie w Krakowie (dlaczego ??). Kilka razy tam się zimą zdarzały pady sieci trwające kilka godzin. Notowane na downdetector.pl zresztą.

Ok, jak setki to nie ma tematu.

Z tym nie mam doświadczenia.

W sumie nawet nie wiedziałem - u nas umową z Playem zajmuje się dział operacji, a urządzenia nie korzystają z SMSów...

Ok :)

To teraz wyobraź sobie, że trzeba zaktualizować soft w urządzeniu, soft ma

8MB, a archaiczny protokół po pierwsze dubluje ilość tych danych, a po drugie nie wspiera ponawiania - czyli jak klient sobie ściągnie 6MB i mu się połączenie wywali, to musi ściągać od nowa :) Nie dało się tego wywalić i zastąpić czymś normalnym (kwestia polityki firmy i licencji na soft do zarządzania).

Efekt był taki, że pewną część urządzeń mieliśmy nieaktualizowalną i jak trzeba było zrobić zdalny update, to próbowaliśmy i jak po paru dniach ciągle się nie udawało, to po prostu jechał technik z laptopem i kabelkiem (a do niektórych urządzeń z pendrivem - nie każde miały możliwość aktualizacji z pendrive). Już nawet urządzenia dialowe (łączące się przez linię telefoniczną) działały lepiej - bardzo powoli, ale o ile klient nie miał linii VoIP, to stabilnie.

2G ma tę przewagę nad 3G (przynajmniej tak zauważyłem w tych modemach, które my mamy), że zauważalnie szybciej zapina się do sieci (nie wiem czy samo logowanie trwa szybciej, czy negocjacja kontekstu - nie sprawdzałem, wiem tylko organoleptycznie).

Z tego samego powodu zresztą wspomniane urządzenia dialowe miały wymuszoną niski baudate. Negocjowały połączenie dużo szybciej, a danych i tak podczas normalnej pracy (czyli o ile nie było update) nie było wiele (max kilkaset bajtów), więc czas nawiązywania połączenia był ważniejszy od czasu transmisji.

Mieliśmy za to karty wieloAPN-owe - każdy dostawca miał swojego prywantego APN-a i połączysz się z nim tylko po tym APN-ie. Jak od rozpoczęcia całego przełączania do uzyskania połączenia mijało 20 sekund, to już był dobry wynik...

W Playmetric oczywiście tego problemu nie ma, bo wychodzisz do Internetu.

nie no, skąd. Nic nie chcę wywalać. Modem ma pełne wsparcie dla komunikacji TCP. Sam zestawi połączenie, będzie go pilnować itp. Komendami AT można dane wysłać i pobrać. Wszystko od tej strony jest przygotowane przez skośnego.

Jedyne co chcę zrobić - to przestać korzystać z chmury producenta i samemu - albo przesyłać tylko dane (czyli tak jak w tej chińskiej chmurze) - albo lepiej, od razu te dane trzymać tam i pokazywać. Czyli thingsboard.

Ok.

Panie, pan to ma wymaganiaaa... :) Nie, tak to się nie da. Dlaczego ? Ano - ponieważ komputer użyszkodnika, to np. komputer pana technika w jakiejś firmie komunikacji miejskiej. Tam jest problem zainstalować w ogóle cokolwiek - trzeba składać podania w 6 egz. z życiorysem całek rodziny. I mieć paszport ABW do pozwolenia użycia konkretnego portu. W dodatku nie wiadomo nigdy co to za PC - przeważnie jeszcze z XP. Czasem windows 7, rzadko 10. Linuksa to tam nikt na oczy nie widział.

Ale to wszystko nie jest kłopot wielki - bo serwer (na razie chiński) pozwala stworzyć "grupę" urządzeń, podpiętych do tego wirtualnego COM. Poza tą grupę user nie wyjdzie. Poza tym, żeby się z urządzeniem połączyć trzeba znać jego numer seryjny. Nawet gdyby ktoś zaś się do tego wszystkiego włamał i chciał rozpracowywać ramkę danych itp. to musiałby poświęcić na to duużo czasu. Ale po co nie wiem :)

Dodatkowo są zabezpieczenia w postaci ograniczenia ilość połączeń/czas, czy nadawane przez urządzenie podczas połączenia "pieczątki" określajace max. czas sesji itp.

Nawet jednak, gdyby jakiś desperat włamał się do tego skutecznie, to i tak nie narobi szkód wielkich - bo ustawienia, które można zdalnie zmienić to tylko wybrane tak, aby nie spowodować zagrożeń.

A z racji tego, że modem jest poza urządzeniem i łączy się tylko via RS232 za pomocą określonych komend, to nie ma żadnej możliwości "hackowania" tak, aby urządzenie zrobiło cokolwiek poza tym, co wolno mu zrobić.

To wszystko zastosuję, kiedy dojdzie do skutku ten kontrakt, na który liczę, z US Army, na obsługę silosów z rakietami :) Ale dzięki - wiedza na pewno się mi przyda.

Byle tylko proces aktualizacji wspierał ponawianie, bo może być tak, że np. pobieranie pliku będzie trwało półtorej godziny, a po godzinie się zerwie, bo modem się zresetuje :)

Pytanie jakie dane latają - bo np. danych osobowych nie można eksportować poza UE. Ale zakładam że danych osobowych tam nie ma :)

Kwestia bardziej tego, czy w przypadku awarii serwera jest do kogo zadzwonić i opieprzyć, czyli czy macie z Chińczykiem jakąś umowę, czy po prostu serwer sobie działa, bo działa, a czy za 5 lat będzie działał, tego nie wie już nikt...

Może padał właśnie dlatego, że wtedy był największy ruch (od wszystkich klientów, nie od Was)...

Smog wawelski :)

Z tym nic się nie zrobi...

W dniu 12.06.2017 o 19:41, Adam Wysocki pisze:

Ten problem dopiero przede mną, żeby były możliwości zdalnej wymiany firmware. Obecne urządzenia nie były początkowo nawet projektowane do sterowania via GPRS - na szczęścia miały RS232, więc dało się firmware zmienić :)

Tak, że dopiero w nowych wersjach to uwzględnię - wtedy trzeba będzie pamiętać o tych kłopotach. Czyli, żeby ew. dało się ciągnąć "na raty" itp.

Jestem w tyle za wami znaczy :)