J.F. <j...@p...onet.pl> wrote:

> 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"

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

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

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 :)

--
[ Email: a@b a=grp b=chmurka.net ]
[ Web: http://www.chmurka.net/ ]

Wysłano z telefonu bez polskiej klawiatury, przepraszam za brak polskich znaków

do góry

> Jak chcesz to możemy coś takiego zestawić, VPS-a póki co mam :)

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

> Mamy teraz 20 (do testów) + kilkaset w polu, były problemy z przełączaniem
> operatorów, ale okazało się, że to po stronie naszego softu. Ogólnie ten
> Play działa stabilnie (jak na GPRS...) tylko są lokalizacje, gdzie trzeba
> wymusić wybór konkretnego operatora, bo automatyczny wybór zrywa.
>
> Korzystamy tylko z 2G.

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.

do góry

sundayman <s...@p...onet.pl> wrote:

> 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.

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.

--
[ Email: a@b a=grp b=chmurka.net ]
[ Web: http://www.chmurka.net/ ]

do góry

sundayman <s...@p...onet.pl> wrote:

> Nie czytacie... :)

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

>> No to teraz pytanie, czy protokół producenta jest znany lub czy możesz
>> otrzymać od producenta pliki serwera do postawienia u siebie, tak żebyś
>> nie był zależny od chińskiego, padającego serwera...
>
> 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.

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

--
[ Email: a@b a=grp b=chmurka.net ]
[ Web: http://www.chmurka.net/ ]

do góry

> 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ę.

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ć...

> 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.

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ą.

do góry

sundayman <s...@p...onet.pl> wrote:

> 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ś...

Ok, jak setki to nie ma tematu.

> 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.

Z tym nie mam doświadczenia.

>> I zje kosztowo :)
>
> Nawet nie to, bo w pakiecie telemetrycznym jest chyba z 500 SMS. A
> użycie to jest max. kilka dziennie.

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

--
[ Email: a@b a=grp b=chmurka.net ]
[ Web: http://www.chmurka.net/ ]

do góry

sundayman <s...@p...onet.pl> wrote:

>> Jak chcesz to możemy coś takiego zestawić, VPS-a póki co mam :)
>
> Bardzo dziękuję, na razie spróbuję jeszcze sam walczyć :)
> Jakby co będę pamiętać.

Ok :)

> 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.

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.

> 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.

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.

--
[ Email: a@b a=grp b=chmurka.net ]
[ Web: http://www.chmurka.net/ ]

do góry

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

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.


> 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

Ok.


> 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ń.

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ć.

> 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

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.

do góry

sundayman <s...@p...onet.pl> wrote:

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

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 :)

> 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ł ??

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...

> 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ć...

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

>> 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.
>
> Z siecią problemy były sporadyczne - głównie w Krakowie (dlaczego ??).

Smog wawelski :)

> Kilka razy tam się zimą zdarzały pady sieci trwające kilka godzin.
> Notowane na downdetector.pl zresztą.

Z tym nic się nie zrobi...

--
[ Email: a@b a=grp b=chmurka.net ]
[ Web: http://www.chmurka.net/ ]

do góry

W dniu 12.06.2017 o 19:41, Adam Wysocki pisze:
> 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

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 :)

do góry