Problemy z przesyłem danych.

[felix]

Aby nie zaśmiecać wątku o HP3501 postanowiłem założyć nowy wątek.

A tak apropo stacji mam znów problem. Nie będę zakładał nowego tematu aby zbytnio nie śmiecić forum dlatego zapytam tu. Czy ktoś z Was miał taki problem iż stacja w tym przypadku EFWS 2900 jest podłączona do routera a nie wysyła danych do internetu (ani na WU ani na Ecowitt) mimo że wszystko jest w porządku. Zdjecie konsoli:
https://zapodaj.net/1a61b481901c7.jpg.html
Jak widać ikonka WiFi jest a stacja normalnie się aktualizuje. Restart routera pomógł tylko na chwilę. Stacja przesłała dosłownie jeden raz dane i znów cisza....Czy ktoś ma jakiś pomysł co jeszcze by moja mama mogła zrobić gdyż nie ma mnie w Polsce a z danych tej stacji korzysta np lokalne radio podając w cogodzinnej prognozie aktualne warunki panujące w mieście. Czy wszystko musi się za przeproszeniem s****** jak mnie nie ma na miejscu....

Czy był u Ciebie jakiś zanik zasilania? Czy Twój router ma dwuzakresowe WiFi?

Problem jest chyba bardziej złożony bo na WeatherCloud chyba wszystkie stacje nie nadają od kilku godzin.
Na WU pokazują się jakieś dziwne czasy ostatniej aktualizacji i wykresy coś słabo się odświeżają.
Ecowitt oprócz Twojej stacji działa chyba normalnie.

[Mark]

Nie mam dzisiaj problemów z WU, ale na WeatherCloud dane przestały być przesyłane po 12:00.

Może trzeba zrobić reset ustawień sieci wi-fi? Nie mam stacji EFWS, ale w konsoli HP3501 jest opcja "Reset Wi-Fi".

[felix]

Nie mam dzisiaj problemów z WU

Według WU Twoja stacja aktualizowała się 15 minut temu.

Dodano:
Parę minut później WU podaje,że Twoja stacja aktualizowała się 14 godzin temu.

[adrian34245]

Router to NetiaSpot a z tego co wiem one mają tylko 2,4 GHZ. Zanik zasilania nawet jeżeliby się pojawił to wątpię aby miał coś wspólnego z tą sytuacją dlatego iż router i konsola jest podłączona pod UPS. Więc po stracie zasilania elektrycznego stacja jest natychmiast przełączana na zasilanie awaryjne. Po wykresie na WU widać że dane przestały być wysyłane o 16:29. Stacja na chwilę powróciła o 17:49 co było spowodowane restartem routera:
https://www.wunderground.com/dashboard/pws/IOSTROWI6/graph/2019-10-10/2019-10-10/daily
Po resecie routera stacja wysłała jeden pakiet danych z 16 sekund na WU i ECOWITT po czym znów zaprzestała mimo że na konsoli ikonka WiFi widniała a więc stacja poprawnie była z nim skonfigurowana. Stacja jest sparowana z tym routerem od marca i nigdy nie miałem podobnego problemu.

[felix]

NetiaSpot może też mieć 5GHz, a ta stacja podobno tego nie lubi.
Chyba nie pozostaje Ci nic innego jak po powrocie zrobić reset stacji i na nowo ją skonfigurować.

[adrian34245]

Kazałem mamie pobrać Ws view. Czuję że ta apka będzie ciężkim orzechem do zgryzienia dla niej ale na rozmowie wideo sprobuje jej wszystko jutro rano wytłumaczyć. Może da radę ją skonfigurować. Jeśli to nie pomoże to nie wiem. W najgorszym wypadku chyba moduł WIFI w stacji poszedł się *****

[adrian34245]

A więc problem leży chyba po stronie dostawcy internetu. Mama robiła speed test to pobieranie danych jest a wysyłanie 0 albo 0,30 mb/s. W dodatku mówiła że widziała koparke Netii w okolicach. A po drugie na telefonie obok ikonki WiFi wyskakuje jej wykrzyknik. Niby brak dostępu do internetu a net działa. Poprostu pobieranie danych jest a wysyłanie już nie. Pierwszy raz się z czymś takim spotykam. I to by wyjaśniało w sumie czemu stacja się nie aktualizuje na WU i Ecowitt

[felix]

Twoja stacja już chyba wysyła dane.
Wychodzi, że pierwsza diagnoza była trafna:

A internet działa?

[adrian34245]

Tak właśnie wróciła z 15 minut temu. Diagnoza była trafna ale jednak trudna. Bo internet działał a nie było jedynie wysyłania danych. Pierwszy raz widzę tympodobną awarię. Dzięki za pomoc

[felix]

Czyżby Twój dostawca internetu miał znów problemy? Bo Twoja stacja znów nie przesyła danych.
Mój dostawca też niestety miewa zwiechy dlatego dokupiłem sobie modem LTE i skonfigurowałem go jako zapasowe źródło internetu.
Myślałem też o UPS ale przerwy w dostawie prądu są u mnie tak rzadkie, że na razie odpuściłem.

[Rychu_Świbno]

Tak właśnie wróciła z 15 minut temu. Diagnoza była trafna ale jednak trudna. Bo internet działał a nie było jedynie wysyłania danych. Pierwszy raz widzę tympodobną awarię. (...)

Wprawdzie już po fakcie ale pewnie przyda się wielu z nas taka oto informacja w nawiązaniu do rodzaju awarii sieci internetowej jaką zarejestrował u siebie @adrian34245 - jw.

Ja od kilku lat w mojej lokalizacji mam właśnie cyklicznie taki typ awarii sieci internetowej. Polega ona na tym, że kanał transmisji UP/Down jest zestawiony a jednak Internetu brak. Brak dlatego ponieważ występują kłopoty z tablicami DNS ale nie w moim ruterze lecz w górze sieci.

Gdy taka sytuacja zaistnieje loguję się do mojego rutera poprzez wpisanie IP w pasku adresowym przeglądarki internetowej 192.168.1.1. Widzę wtedy formatkę logowania do mojego rutera. Loguję się i robię test.

Po teście widzę:
Test połączenia portu LAN4/WAN - UDANY
Test synchronizacji ADSL: UDANY - tzn zestawiony kanał transmisji Up/Down wg umowy z operatorem z udziałem mojego ADSL/rutera
Test połączenia z serwerem PPP:    NIEUDANY     
Test uwierzytelniania z siecią dostawcy Internetu:    NIEUDANY    
Test przydzielonego adresu IP:    UDANY   
Ping do bramy domyślnej:    NIEUDANY
Ping do preferowanego serwera DNS: NIEUDANY.

Co to oznacza. kable miedziane w moim domu OK - światłowód OK - kanał transmisji zestawiony do DSLAM Operatora czyli mój ruter OK - brak  dostępu do serwera DNS czyli w kanale nie hulają pakiety danych - inaczej "brak Internetu" - a to już problem Operatora i to w części wirtualnej ich sieci.  Wtedy właśnie przeważnie stacja/konsola wykazuje połączenie z Internetem i dziwimy się, że np na WU brak danych.

W tym miejscu warto wspomnieć, że sieć Internetowa zbudowana jest z 7-miu warstw - od 1 do 7.  Dolne warstwy bliskie 1 to sieć fizyczna (światłowód kabel miedziany w mieszkaniu/domu), urządzenia fizyczne transmisji danych (ruter), brama  w szafach w terenie DSLAM z urządzeniami - w środku zakresu 1-7 jest protokół IP oraz DNS a najwyżej warstwa użytkownika czyli wszelkiego rodzaju aplikacje np wunderground czy aplikacje innego serwera pogodowego w naszym - userów stacji - wypadku.

Dlatego przy takim rodzaju uszkodzenia podczas kontaktu z Operatorem sieci nie można dać się nabijać w butelkę. Oni wtedy robią zdalny test i on wykazuje im, że kanał transmisji zestawiony więc problem lezy u mnie (kabel miedziany/ruter). Wtedy należy przesłać screen z testów i pokazać że to problem w górze sieci Operatora w tej warstwie logicznej od 5 do 7. Tam gdzie ulokowane są tablice DNS których ruter nie może odczytać. Ja mam ten problem co 2-3 miesiące - cyklicznie od kilku lat. Nic więcej z tym nie mogę zrobić. Przedstawiam stanowczo aby grzebali w swojej sieci na serwerach przesyłających treści i nie przysyłali mi do domu technika który zrobi test uwaga: zestawienia kanału – który jest przecież zestawiony - i wali głupa. Po takim postawieniu sprawy sieć wraca w ciągu kilku minut. A gdy zgłosi to ktoś z innych domowników to walą głupa i to trwa nawet dwa dni z jałową wizytą technika na drugi dzień po zgłoszeniu włącznie.

Opisałem to dosyć łopatologicznie ponieważ wiem, że nie każdy jest wkręcony w ta dziedzinę - a jak widać taka wiedza  przydałaby się niejednemu z nas.

PS: gdy chcemy szybko sprawdzić czy ruter jest sprawny – wpisujemy w wierszu polecenia komputera (czarny prostokąt) ping [spacja] 192.168.1.1 – jeśli wynikiem jest b.krótki czas odbicia w milisekundach to ruter OK

Warto też mieć pod ręka trasę routowania naszych pakietów po wyjściu z naszego rutera w górę sieci. Należy to zrobić gdy sieć jest sprawna. Robimy to  poprzez wpisanie w wierszu polecenia jw: tracert [spacja] adres – np www.wunderground.com - patrz zrzut drogi rutowania poniżej.

Otrzymamy drogę rutownia naszych pakietów. Warto mieć pod ręką taki routing w tym w szczególności adresy IP serwerów swojego Operatora – patrz pozycja 2 i 3. Wtedy podczas braku Internetu robimy Tracert lub Ping kolejno do tych serwerów i wiemy gdzie jest awaria – i z taką informacją z pozycji siły rozmawiamy z infolinią Operatora   


C:\Users\Rysiek>tracert www.wunderground.com

Tracing route to e12930.e12.akamaiedge.net [23.211.150.161]
over a maximum of 30 hops:

  1     3 ms     2 ms     3 ms  192.168.1.1
  2    20 ms    21 ms    20 ms  gda-bng2.tpnet.pl [80.50.18.102]
  3    22 ms    20 ms    22 ms  gda-r2.tpnet.pl [80.50.122.101]
  4    30 ms    30 ms    31 ms  194.204.175.237
  5    93 ms    53 ms    54 ms  ae16-10.ffttr7.-.opentransit.net [193.251.249.5]
  6    59 ms    52 ms    64 ms  81.52.188.25
  7    53 ms    53 ms    53 ms  a23-211-150-161.deploy.static.akamaitechnologies.com [23.211.150.161]

Trace complete.