eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.misc.elektronikaNTG ale może...
Ilość wypowiedzi w tym wątku: 153

  • 71. Data: 2017-06-12 18:19:29
    Temat: Re: NTG ale może...
    Od: g...@s...invalid (Adam Wysocki)

    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


  • 72. Data: 2017-06-12 18:22:48
    Temat: Re: NTG ale może...
    Od: sundayman <s...@p...onet.pl>


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



  • 73. Data: 2017-06-12 19:11:27
    Temat: Re: NTG ale może...
    Od: g...@s...invalid (Adam Wysocki)

    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/ ]


  • 74. Data: 2017-06-12 19:26:31
    Temat: Re: NTG ale może...
    Od: g...@s...invalid (Adam Wysocki)

    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/ ]


  • 75. Data: 2017-06-12 19:28:18
    Temat: Re: NTG ale może...
    Od: sundayman <s...@p...onet.pl>


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




  • 76. Data: 2017-06-12 19:29:38
    Temat: Re: NTG ale może...
    Od: g...@s...invalid (Adam Wysocki)

    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/ ]


  • 77. Data: 2017-06-12 19:41:39
    Temat: Re: NTG ale może...
    Od: g...@s...invalid (Adam Wysocki)

    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/ ]


  • 78. Data: 2017-06-12 19:45:54
    Temat: Re: NTG ale może...
    Od: sundayman <s...@p...onet.pl>


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


  • 79. Data: 2017-06-12 19:50:09
    Temat: Re: NTG ale może...
    Od: g...@s...invalid (Adam Wysocki)

    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/ ]


  • 80. Data: 2017-06-12 19:51:09
    Temat: Re: NTG ale może...
    Od: sundayman <s...@p...onet.pl>

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

strony : 1 ... 7 . [ 8 ] . 9 ... 16


Szukaj w grupach

Szukaj w grupach

Eksperci egospodarka.pl

1 1 1

Wpisz nazwę miasta, dla którego chcesz znaleźć jednostkę ZUS.

Wzory dokumentów

Bezpłatne wzory dokumentów i formularzy.
Wyszukaj i pobierz za darmo: