NOWY TEMAT
elektroda NewsGroups Forum Index - Elektronika Polska - Jak uruchomić lokalny serwer na VirtualBoxie do testów z urządzeniami GPRS?
Goto page Previous 1, 2, 3, 4, 5, 6 ... 9, 10, 11 Next
Adam Wysocki
Guest
Guest
Mon Jun 12, 2017 12:33 pm
sundayman <sundayman@poczta.onet.pl> wrote:
Quote:
Na razie w pewnej części wygląda mi to na napisane w obcym języku , ale
bardzo dziękuję za obszerny opis, bo na pewno się przyda. Jak nie teraz
to innym razem
bardzo dziękuję za obszerny opis, bo na pewno się przyda. Jak nie teraz
to innym razem
VPN to taki LAN, tylko że przez Internet
Tworzy Ci się po prostu
dodatkowe urządzenie sieciowe, któremu przypisujesz adresy i które
komunikują się tak, jakbyś miał komputery spięte LAN-em.
Przynajmniej w przypadku urządzenia TAP (Network Tap) tak jest, bo jest
jeszcze opcja TUN (Tunnel), która działa warstwę wyżej (na warstwie IP).
Dopóki nie robisz cudów typu bridging z innymi interfejsami lub transfer
innych protokołów (poza IP) to nie ma to znaczenia :)
--
[ Email: a@b a=grp b=chmurka.net ]
[ Web: http://www.chmurka.net/ ]
Adam Wysocki
Guest
Guest
Mon Jun 12, 2017 12:36 pm
sundayman <sundayman@poczta.onet.pl> wrote:
Quote:
Ha, no to trochę mi daliście nadziei...
Bo niby ten DSL to nie jest jakiś koszmarny koszt, ale jeżeli nie muszę,
no to nie muszę.
A obecne czasy w mikrobiznesie jakoś nie wykazują objawów dobrej zmiany
Bo niby ten DSL to nie jest jakiś koszmarny koszt, ale jeżeli nie muszę,
no to nie muszę.
A obecne czasy w mikrobiznesie jakoś nie wykazują objawów dobrej zmiany
Nie tam, dziś wszystko trzyma się zdalnie - ja sam, mając wiele lat serwer
w domu, w końcu olałem to i wykupiłem VPS-a.
--
[ Email: a@b a=grp b=chmurka.net ]
[ Web: http://www.chmurka.net/ ]
Adam Wysocki
Guest
Guest
Mon Jun 12, 2017 12:38 pm
sundayman <sundayman@poczta.onet.pl> wrote:
Quote:
Tylko teraz, do nauki i testów obawiam się, że "na biurku" będzie mi
łatwiej. Moja znajomość tematu jest na razie dość symboliczna i boję się
walki ze zdalnym VPS-em.
łatwiej. Moja znajomość tematu jest na razie dość symboliczna i boję się
walki ze zdalnym VPS-em.
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.
--
[ Email: a@b a=grp b=chmurka.net ]
[ Web: http://www.chmurka.net/ ]
J.F.
Guest
Guest
Mon Jun 12, 2017 12:40 pm
Użytkownik "Adam Wysocki" napisał w wiadomości grup
dyskusyjnych:ohlplu$t48$4$gof@news.chmurka.net...
sundayman <sundayman@poczta.onet.pl> wrote:
Quote:
- urządzenie ma modem GPRS z kartą telemetryczną.
Moim zdaniem ona ma publiczny adres (oczywiście nie stały).
Pewności nie mam, ale gdyby nie miała, to chyba by to wszystko nie
działało, jak działa.
Nie ma - i dlatego aktywny FTP mi nie działał. Swoją drogą aktywny
FTP
(gdzie klient otwiera port, a serwer próbuje się z nim połączyć) to
wg
mnie jakaś pomyłka...
Moim zdaniem ona ma publiczny adres (oczywiście nie stały).
Pewności nie mam, ale gdyby nie miała, to chyba by to wszystko nie
działało, jak działa.
Nie ma - i dlatego aktywny FTP mi nie działał. Swoją drogą aktywny
FTP
(gdzie klient otwiera port, a serwer próbuje się z nim połączyć) to
wg
mnie jakaś pomyłka...
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"
Quote:
Ogólnie w takich rozwiązaniach raczej unika się połączenia aktywnego
non-stop, o ile to tylko możliwe, i robi się heartbeaty, wysyłane
przez
klienta (czyli klient łączy się, pyta serwera czy coś dla niego ma, i
wtedy następuje wymiana danych).
non-stop, o ile to tylko możliwe, i robi się heartbeaty, wysyłane
przez
klienta (czyli klient łączy się, pyta serwera czy coś dla niego ma, i
wtedy następuje wymiana danych).
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.
Marek
Guest
Guest
Mon Jun 12, 2017 2:22 pm
On Mon, 12 Jun 2017 01:39:27 +0200, "J.F."
<jfox_xnospamx@poczta.onet.pl> wrote:
Quote:
Raczej nie ma - sieci GSM z reguly ukrywaja.
W plusie jest usługa "publiczne IP" kosztuje 5 zl (ip się zmienia)
zamiast 20 zł za stały ip.
--
Marek
Guest
Mon Jun 12, 2017 2:55 pm
W dniu poniedziałek, 12 czerwca 2017 14:40:56 UTC+2 użytkownik J.F. napisał:
Quote:
Użytkownik "Adam Wysocki" napisał w wiadomości grup
dyskusyjnych:ohlplu$t48$4$gof@news.chmurka.net...
sundayman <sundayman@poczta.onet.pl> wrote:
- urządzenie ma modem GPRS z kartą telemetryczną.
Moim zdaniem ona ma publiczny adres (oczywiście nie stały).
Pewności nie mam, ale gdyby nie miała, to chyba by to wszystko nie
działało, jak działa.
Nie ma - i dlatego aktywny FTP mi nie działał. Swoją drogą aktywny
FTP
(gdzie klient otwiera port, a serwer próbuje się z nim połączyć) to
wg
mnie jakaś pomyłka...
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"
Ogólnie w takich rozwiązaniach raczej unika się połączenia aktywnego
non-stop, o ile to tylko możliwe, i robi się heartbeaty, wysyłane
przez
klienta (czyli klient łączy się, pyta serwera czy coś dla niego ma, i
wtedy następuje wymiana danych).
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.
dyskusyjnych:ohlplu$t48$4$gof@news.chmurka.net...
sundayman <sundayman@poczta.onet.pl> wrote:
- urządzenie ma modem GPRS z kartą telemetryczną.
Moim zdaniem ona ma publiczny adres (oczywiście nie stały).
Pewności nie mam, ale gdyby nie miała, to chyba by to wszystko nie
działało, jak działa.
Nie ma - i dlatego aktywny FTP mi nie działał. Swoją drogą aktywny
FTP
(gdzie klient otwiera port, a serwer próbuje się z nim połączyć) to
wg
mnie jakaś pomyłka...
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"
Ogólnie w takich rozwiązaniach raczej unika się połączenia aktywnego
non-stop, o ile to tylko możliwe, i robi się heartbeaty, wysyłane
przez
klienta (czyli klient łączy się, pyta serwera czy coś dla niego ma, i
wtedy następuje wymiana danych).
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.
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
sundayman
Guest
Guest
Mon Jun 12, 2017 3:40 pm
Quote:
Pod warunkiem że modem będzie utrzymywał połączenie z serwerem. Takie
utrzymanie połączenia, w przypadku tysięcy modemów, zaczyna być bolesne
dla sieci. Najlepiej jakbyś ustalił z Playem, czy dadzą radę utrzymywać
po jednym połączeniu z X urządzeń rozsianych na obszarze Y...
utrzymanie połączenia, w przypadku tysięcy modemów, zaczyna być bolesne
dla sieci. Najlepiej jakbyś ustalił z Playem, czy dadzą radę utrzymywać
po jednym połączeniu z X urządzeń rozsianych na obszarze Y...
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ś...
Quote:
Teraz kwestia protokołu - jest znany? Bo może to jakiś zamknięty protokół
producenta?
producenta?
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ę.
Quote:
Co potem gada do tego RS-a? Twoja aplikacja? Bo jeśli tak, to może w ogóle
pominąć tego "wirtualnego RS-a" i zrobić aplikację, która zamiast po RS-ie
komunikuje się przez TCP lub web (zwykłym request/response lub poprzez
websockety)?
pominąć tego "wirtualnego RS-a" i zrobić aplikację, która zamiast po RS-ie
komunikuje się przez TCP lub web (zwykłym request/response lub poprzez
websockety)?
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.
Quote:
Można oczywiście jeszcze via SMS, z tego korzystałem na samym wstępie.
Fajne, ale do dupy :)
I zje kosztowo
Fajne, ale do dupy :)
I zje kosztowo
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.
sundayman
Guest
Guest
Mon Jun 12, 2017 3:48 pm
Quote:
Hmm, czyli modemy są połączone z serwerem cały czas i operator na PC
wymusza transfer danych? Ile masz tych urządzeń? Jak 100 to jeszcze
się da, ale jak np. 10000, to może być problem...
wymusza transfer danych? Ile masz tych urządzeń? Jak 100 to jeszcze
się da, ale jak np. 10000, to może być problem...
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.
Quote:
Ogólnie w takich rozwiązaniach raczej unika się połączenia aktywnego
non-stop, o ile to tylko możliwe, i robi się heartbeaty, wysyłane przez
klienta (czyli klient łączy się, pyta serwera czy coś dla niego ma, i
wtedy następuje wymiana danych).
non-stop, o ile to tylko możliwe, i robi się heartbeaty, wysyłane przez
klienta (czyli klient łączy się, pyta serwera czy coś dla niego ma, i
wtedy następuje wymiana danych).
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.
sundayman
Guest
Guest
Mon Jun 12, 2017 3:51 pm
Quote:
Swoja droga - sa taryfy z bezplatnymi SMS, ale operator sie pewnie
obrazi jak ich bedzie za duzo
obrazi jak ich bedzie za duzo
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.
sundayman
Guest
Guest
Mon Jun 12, 2017 3:58 pm
Quote:
A gdybyś chciał zrezygnować z softu producenta, to ten modem ma
zaimplementowany jakiś (prosty) stos TCP/IP i polecenia AT do tworzenia
połączeń (TCP) lub wymiany datagramów (UDP)? Czy musisz mieć własny stos
TCP/IP?
zaimplementowany jakiś (prosty) stos TCP/IP i polecenia AT do tworzenia
połączeń (TCP) lub wymiany datagramów (UDP)? Czy musisz mieć własny stos
TCP/IP?
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ć.
Quote:
Hmm, czyli tak naprawdę główną zaletą tego modemu jest przezroczysty
sieciowo RS-232, który jest w pakiecie z serwerem producenta, tak?
sieciowo RS-232, który jest w pakiecie z serwerem producenta, tak?
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 :)
Quote:
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...
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.
sundayman
Guest
Guest
Mon Jun 12, 2017 4:22 pm
Quote:
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ć.
Quote:
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.
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.
sundayman
Guest
Guest
Mon Jun 12, 2017 5:28 pm
Quote:
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ę.
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ć...
Quote:
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.
(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ą.
sundayman
Guest
Guest
Mon Jun 12, 2017 5:45 pm
Quote:
Czyli chcesz z tego zupełnie zrezygnować, wywalić soft producenta i zrobić
łączność sieciową samemu?
łą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.
Quote:
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
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.
Quote:
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ń.
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ć.
Quote:
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
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.
sundayman
Guest
Guest
Mon Jun 12, 2017 5:51 pm
W dniu 12.06.2017 o 19:41, Adam Wysocki pisze:
Quote:
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
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
sundayman
Guest
Guest
Mon Jun 12, 2017 5:54 pm
W dniu 12.06.2017 o 19:50, Adam Wysocki pisze:
Quote:
Pytanie jakie dane latają - bo np. danych osobowych nie można eksportować
poza UE. Ale zakładam że danych osobowych tam nie ma
poza UE. Ale zakładam że danych osobowych tam nie ma
Np. aktualne napięcie, temperatura, niektóre ustawienia. Mało osobowe :)
Quote:
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...
A skąd, to jest "usługa" free producenta modemu. Jak mu się odwidzi, to
wyłączy. Do testów może być, ale na poważnie to absolutnie.
Quote:
Może padał właśnie dlatego, że wtedy był największy ruch (od wszystkich
klientów, nie od Was)...
klientów, nie od Was)...
A cholera wie. Powiem, że to jakieś przeklęte miejsce - w okolicach
Zamku Wawelskiego. No cuda tam się działy. Czyżby jakaś zła energia tam
zagościła od czasy pochówku ostatniego "króla" ?... hmmmm
Quote:
Z tym nic się nie zrobi...
Ano. Piszę o tym w "disclaimerach" ale słabo dociera
elektroda NewsGroups Forum Index - Elektronika Polska - Jak uruchomić lokalny serwer na VirtualBoxie do testów z urządzeniami GPRS?