Rozwiązany: Neostrada przerywa połączenie co 10 minut

[b3rt]

Witam po raz kolejny. Od jakichś dwóch tygodni mam problem z internetem, a dokładniej z Neostradą TP 2 Mb/s. Prędkość pobierania, wyświetlania stron itp. jest ok, ale komputer co 10/20 minut traci połączenie z internetem. Tak sobie tkwi bez sieci jakieś 30 sekund, do minuty, po czym włącza się z powrotem. Mocno zirytowany tym faktem zadzwoniłem dzisiaj do pomocy technicznej tp, i pewien pan wytłumaczył mi że z ich strony wszystko jest ok. Powiedział mi też, że wygląda na to że z mojej strony co jakiś czas dochodzi sygnał zakończenia sesji (czy tak jakoś, nie kojarzę już terminologii fachowej ^^). Mam router Linksys WAG200G, i dowiedziałem się że gdyby łącze było zrywane, to lampki internetu i DSL by gasły, a tak się nie dzieje. W momencie kiedy tracę połączenie, lampka internetu zaświeca się na czerwono, i gdy internet wróci, zmienia się z powrotem na zieloną.

Zdaje sobie sprawę że trochę pokrętnie to napisałem, ale jestem mocno zdenerwowany, bo w taki sposób nie da się korzystać z internetu: nie da się grać, bo wywala z serwera, przeglądanie stron i korzystanie z komunikatorów również irytuje, bo co chwile przerywa. Jakby ktoś miał jakiś pomysł jak temu zaradzić, bądź też potrzebuje więcej informacji do diagnozy to niech piszę, chętnie odpowiem.

PS. Nie wiem czy ta informacja ma jakieś znaczenie, ale od jakiegoś czasu mam podpięty do sieci telefonicznej lekko uszkodzony aparat telefoniczny. Czy taki zepsuty telefon może być przyczyną takiego zachowania sieci? Bo jeśli tak, to go wymienię, a jeśli nie, to szkoda mi kasy. Niestety nie mam możliwości go odłączyć żeby sprawdzić jak będzie działało bez niego.

[Sevard]

Miejmy nadzieję, że masz ten sam soft, co ja u siebie.

Wejdź do konfiguracji routera (standardowo wpisujesz w przeglądarce adres 192.168.1.1, następnie wpisujesz login i hasło, standardowe to admin i admin) na karcie Setup > Basic Setup, w polu PPPoA Settings masz dwie opcje do wyboru:

Connect on Demand: Max Idle Time (jakaś wartość) Minutes

Keep Alive: Redial period (jakaś wartość) Seconds

Którą opcję masz wybraną i jaką masz ustawioną wartość w wybranej opcji?

[b3rt]

Keep Alive: Redial period 30 Seconds

[SwisteK]

Czy taki zepsuty telefon może być przyczyną takiego zachowania sieci?

Może. Odłącz go, w środku nocy nie potrzebujesz telefonu

Ale w tym przypadku stawiam na zmianę kodowania po stronie TP (z ADSL/G.DMT/PPPoA na ADSL 2+/PPPoE). Od połowy zeszłego roku zmieniają sprzęt i ustawienia na centralach, może teraz trafiło na ciebie

Ustawienia routera zostały po staremu, i to może być problem.

U mnie np. już nie połączysz się przy logowaniu PPPoA (jeśli nawet, to na tylko chwilę), a po zmianie konfiguracji routera na ADSL2+ i PPPoE łącze działa normalnie. Od strony centrali zmieniły się tylko ustawienia, nie sprzęt (to akurat wiem dokładnie) a problem wystąpił "nagle" (czyli w momencie zmiany ustawień portu).

Infolinia TP "nic nie wie", chyba że w końcu trafisz na bardziej "ogarniętego" pracownika (raczej na infolinii technicznej Neostrady niż na "ogólnej", trzeba mieć DUŻO szczęścia żeby na taką osobę trafić).

Co prawda ten model routera miewał podobne problemy z jedną wersją firmware, ale skoro "działało a przestało" chyba można zakładać że jest sprawny?

(przy innych uszkodzeniach, np. zasilacza, gaśnie dioda "DSL")

(jeśli możesz podłącz - dla testu - inny routera albo chociaż modem na USB)

[Sevard]

To tylko ja napiszę, że na takim ustawieniu wcześniej wspomnianej opcji router sam z siebie nie powinien się rozłączać, więc albo coś mu odbija (mało prawdopodobne przy takich objawach), albo rzeczywiście TP coś znowu mota. Jak wrócę do domu, to jeszcze przejrzę dokładniej co może za takie coś odpowiadać, ale z tego co pamiętam, to tylko ustawienie tej opcji powodowalo rozłączanie netu w dziwnych momentach.

Jakbyś mógł podaj jeszcze wersję firmware'u routera.

[b3rt]

@SwisteK

Czyli sugerujesz że powinienem zmienić ustawienia routera na ADSL 2+/PPPoE? Bo tak wywnioskowałem. Encapsulation mam ustawione właśnie na PPPoA, a DSL Modulation na MultiMode

"działało a przestało" chyba można zakładać że jest sprawny?

Działało bez problemów odkąd mam neo, czyli gdzieś tak od dwóch lat. Co prawda też codziennie kończyło sesje, nadając nowe IP itd, ale zawsze raz dziennie, około godziny ósmej rano. Problem pojawił się dokładnie 23 maja. Wtedy właśnie miała miejsce jakaś awaria, i cała moja gmina była odcięta od internetu i telefonu przez cały dzień. I odkąd internet zaczął "dopływać" tak właśnie przerywa.

(przy innych uszkodzeniach, np. zasilacza, gaśnie dioda "DSL")

Jedynym objawem przerwania połączenia jest zmiana koloru diody "Internet" z zielonej na czerwoną. Po 30 sekundach zmienia się z powrotem na zieloną, i wszystko działa. Innych objawów (oczywiście poza brakiem łącza) nie zauważyłem (od strony systemowej, i na routerze).

@Sevard

Firmware Version: 1.01.05

[SwisteK]

@SwisteK

Czyli sugerujesz że powinienem zmienić ustawienia routera na ADSL 2+/PPPoE? Bo tak wywnioskowałem. Encapsulation mam ustawione właśnie na PPPoA, a DSL Modulation na MultiMode

Dokładnie tak. Nie pomoże - wrócisz do poprzednich parametrów.

Przy okazji sprawdź jakie masz tłumienie i SNR.

I odłącz telefon na pół godziny, razem z mikrofiltrem.

[b3rt]

Podsumujmy dzisiejsze akcje:

- zaktualizowałem firmware routera do wersji 1.01.09, najnowszej jaka była na stronie Cisco,

- zmieniłem ustawienia routera na ADSL 2+/PPPoE,

- zresetowałem router, ustawiając wszystkie parametry od początku.

I jak na razie lampka ani razu nie zamieniła się na czerwoną. Aby sprawdzić czy łącze na pewno nie przerywa będę musiał w coś zagrać, bądź włączyć ściąganie czegoś większego, aby przez pewien czas mieć łącze stale napięte. Zrobię to raczej jutro, bo dzisiaj wolałbym się już położyć spać (muszę tylko skończyć skanowanie Anti-Malware i nynu ^^)

[Sevard]

Firmware 1.01.05 akurat jest dosyć stabilny, większych problemów z nim nie miałem, więc pewnie pomógł punkt 2. No nic miejmy nadzieję, że to rzeczywiście koniec. Cała Neostrada, najpierw zamotają coś, a potem nikt nic nie wie.

[b3rt]

Ech, za szybko się cieszyłem. Mimo poprawek net nadal przerywa. Co prawda rzadziej niż ostatnio, ale półgodzinne sesje to IMO wciąż za mało. Dzwoniłem znowu do TP, to mi coś zaczął ględzić że to może komputer, potem że to może router (mimo że na modemie też się tak działo), aż w końcu powiedział że zobaczą co się da zrobić, i jakby nic się nie poprawiło to żebym zadzwonił jeszcze raz a przyślą technika.

Normalnie, gdybym tylko mógł to bym zerwał umowę z TP, za samo olewanie podczas pomocy technicznej....

[SwisteK]

Ech, za szybko się cieszyłem.

Możesz odczytać parametry linii (attenuation, SNR margin) z modemu albo rutera?

Router ma włączone logowanie zdarzeń? co jest w logu?

Normalnie, gdybym tylko mógł to bym zerwał umowę z TP, za samo olewanie podczas pomocy technicznej....

Co Ty wiesz o olewaniu ...

LOL

Podpisz umowę ze "znanym największym operatorem alternatywnym" to dopiero zobaczysz olewanie. I to za Twoje pieniądze!!

(płatne połączenie z infolinią, podczas którego głównie słuchasz muzyki - średnio godzinę, w porywach do półtorej)

[Sevard]

To, żeby ułatwić szukanie odpowiednich. Zakładając, że w tej, wersji softu jest tak samo, jak u mnie:

Logowanie w tym routerze jest niestety domyślnie wyłączone. Można je włączyć w Administration/Reporting. Logi są nawet dokładne, ale niestety przeglądanie ich może być męczące, dlatego warto je wysyłać do jakiegoś kompa w sieci i tam je odczytywać, aczkolwiek trzeba się trochę pomęczyć z konfiguracją tego, żeby działało.

Parametry linii można odczytać w zakładce Status/DSL Connection.

Skoro zarówno router, jak i modem tak robią, to przyczyna jest raczej po ich stronie.

W konfiguracji routera nie znalazłem już nic innego, co mogłoby powodować tego typu rzeczy.

[b3rt]

Logi dopiero co włączyłem, więc siłą rzeczy są na razie puste. Jutro zerknę co się tam dzieje.

Co do parametrów linii itd.:

Downstream Line Attenuation:      23 db

Upstream Line Attenuation:     4 db


Downstream Margin:      24 db

Upstream Margin:     34 db

O to chodzi?

[zecik]

Normalnie, gdybym tylko mógł to bym zerwał umowę z TP, za samo olewanie podczas pomocy technicznej....

dzwon do upadlego do pomocy technicznej, potem przysla ci fachowca i jesli on nic nie pomoze to wymysla jaka bajke ;p wtedy ty sie nie zgodzisz i mowisz o zerwaniu umowy z przyczyn technicznych z ich strony, wtedy to jest darmowe, wtedy wystarczy opisac caly problem, ilosc wykonwywanych polaczec do pomocy technicznej, oswiadczenie fachowca i z tym listem udac sie do punktu tp ;p niestety nie ma zwrotu kasy za dany miesiac ;p

[SwisteK]

Logi dopiero co włączyłem, więc siłą rzeczy są na razie puste. Jutro zerknę co się tam dzieje.

Wrzuć na forum, sie poczyta.

Co do parametrów linii itd.:

Downstream Line Attenuation:      23 db

Upstream Line Attenuation:     4 db


Downstream Margin:      24 db

Upstream Margin:     34 db

O to chodzi?

O to chodzi.

Bardzo ładne, prawie "wzorcowe". Chciałbym takie mieć na swojej linii

[b3rt]

Dobra, logi z Linksysa faktycznie dość topornie się obsługuje, ale udało mi się wyrwać fragment zaraz po ponownym połączeniu:

Thu, 2010-06-03 17:20:12 - TCP Packet - Source:192.168.1.101,50974 Destination:79.191.98.30,443 - [Outgoing]


Thu, 2010-06-03 17:20:12 - TCP Packet - Source:192.168.1.101,50975 Destination:79.191.98.30,80 - [Outgoing]


Thu, 2010-06-03 17:20:12 - We have just avoided a PPPRceivedTerminate right now


Thu, 2010-06-03 17:20:13 - UDP Packet - Source:192.168.1.101,56607 Destination:194.204.152.34,53 - [Outgoing]


Thu, 2010-06-03 17:20:13 - UDP Packet - Source:192.168.1.101,56607 Destination:194.204.159.1,53 - [Outgoing]


Thu, 2010-06-03 17:20:13 - TCP Packet - Source:192.168.1.101,50972 Destination:79.191.98.30,45015 - [Outgoing]


Thu, 2010-06-03 17:20:13 - TCP Packet - Source:192.168.1.100,2137 Destination:195.88.51.205,80 - [Outgoing]


Thu, 2010-06-03 17:20:14 - lcp echos pending >= lcp_echo_fails! 


Thu, 2010-06-03 17:20:14 - chld,got_sigchld=1


Thu, 2010-06-03 17:20:14 - ret=18335


Thu, 2010-06-03 17:20:14 - Couldn't increase MTU to 1500.


Thu, 2010-06-03 17:20:14 - Couldn't increase MRU to 1500


Thu, 2010-06-03 17:20:14 - LCP down.


Thu, 2010-06-03 17:20:14 - reap_kids,waitfor=0


Thu, 2010-06-03 17:20:20 - This terminate is called from lcp_finished()


Thu, 2010-06-03 17:20:20 - Connection terminated.


Thu, 2010-06-03 17:20:20 - Connect time 119.7 minutes.


Thu, 2010-06-03 17:20:20 - Sent 15385517 bytes, received 88539381 bytes. 


Thu, 2010-06-03 17:20:20 - Doing disconnect


Thu, 2010-06-03 17:20:20 - Exit.


Thu, 2010-06-03 17:20:53 - Initialize LCP.


Thu, 2010-06-03 17:20:53 - Plugin pppoe loaded.


Thu, 2010-06-03 17:20:53 - PPPoE Plugin Initialized


Thu, 2010-06-03 17:20:53 - Plugin pppoe called.


Thu, 2010-06-03 17:20:53 - pppd 2.4.1 started by root, uid 0


Thu, 2010-06-03 17:20:53 - setting line discipline hook


Thu, 2010-06-03 17:20:53 - Sending PADI 


Thu, 2010-06-03 17:21:31 - Initialize LCP.


Thu, 2010-06-03 17:21:31 - Plugin pppoe loaded.


Thu, 2010-06-03 17:21:31 - PPPoE Plugin Initialized


Thu, 2010-06-03 17:21:31 - Plugin pppoe called.


Thu, 2010-06-03 17:21:31 - pppd 2.4.1 started by root, uid 0


Thu, 2010-06-03 17:21:31 - setting line discipline hook


Thu, 2010-06-03 17:21:31 - Sending PADI 


Thu, 2010-06-03 17:22:04 - sendto returned:


Thu, 2010-06-03 17:22:04 - Exit.


Thu, 2010-06-03 17:22:06 - Initialize LCP.


Thu, 2010-06-03 17:22:06 - Plugin pppoe loaded.


Thu, 2010-06-03 17:22:06 - PPPoE Plugin Initialized


Thu, 2010-06-03 17:22:06 - Plugin pppoe called.


Thu, 2010-06-03 17:22:06 - pppd 2.4.1 started by root, uid 0


Thu, 2010-06-03 17:22:06 - setting line discipline hook


Thu, 2010-06-03 17:22:06 - Sending PADI


Thu, 2010-06-03 17:22:06 - HOST_UNIQ successful match 


Thu, 2010-06-03 17:22:06 - Connecting PPPoE socket: 00:90:1a:a0:46:a5 ce0e nas0 0x1000d398


Thu, 2010-06-03 17:22:06 - using channel 22


Thu, 2010-06-03 17:22:06 - Using interface ppp0


Thu, 2010-06-03 17:22:06 - Connect: ppp0 <--> nas0


Thu, 2010-06-03 17:22:06 - Couldn't increase MTU to 1500.


Thu, 2010-06-03 17:22:06 - Couldn't increase MRU to 1500


Thu, 2010-06-03 17:22:06 - LCP is allowed to come up.


Thu, 2010-06-03 17:22:06 - Couldn't increase MRU to 1500


Thu, 2010-06-03 17:22:07 - CHAP authentication success


Thu, 2010-06-03 17:22:07 - local IP address 83.22.181.86 


Thu, 2010-06-03 17:22:15 - TCP Packet - Source:192.168.1.101,51123 Destination:77.70.7.42,443 - [Outgoing]


Thu, 2010-06-03 17:22:15 - TCP Packet - Source:192.168.1.101,51118 Destination:89.253.146.214,9774 - [Outgoing]


Thu, 2010-06-03 17:22:15 - TCP Packet - Source:192.168.1.101,51124 Destination:89.253.146.214,80 - [Outgoing]


Thu, 2010-06-03 17:22:16 - TCP Packet - Source:192.168.1.101,51125 Destination:89.215.106.33,443 - [Outgoing]


Thu, 2010-06-03 17:22:16 - TCP Packet - Source:192.168.1.101,51126 Destination:95.176.220.169,443 - [Outgoing]


Thu, 2010-06-03 17:22:16 - chld,got_sigchld=1


Thu, 2010-06-03 17:22:16 - reap_kids,waitfor=0


Thu, 2010-06-03 17:22:16 - reap_kids:pid=18649


Thu, 2010-06-03 17:22:16 - TCP Packet - Source:192.168.1.101,50783 Destination:93.90.176.151,38112 - [Outgoing]


Thu, 2010-06-03 17:22:16 - TCP Packet - Source:192.168.1.101,50785 Destination:93.90.176.134,38121 - [Outgoing]

Tyle, potem ponawia się ten zwrot co przez dwie ostatnie linijki.

[SwisteK]

Sekwencja powodująca rozłączenie:

Thu, 2010-06-03 17:20:14 - lcp echos pending >= lcp_echo_fails!

Thu, 2010-06-03 17:20:14 - chld,got_sigchld=1

Thu, 2010-06-03 17:20:14 - ret=18335

Thu, 2010-06-03 17:20:14 - Couldn't increase MTU to 1500.

Thu, 2010-06-03 17:20:14 - Couldn't increase MRU to 1500

Thu, 2010-06-03 17:20:14 - LCP down.

Thu, 2010-06-03 17:20:14 - reap_kids,waitfor=0

Thu, 2010-06-03 17:20:20 - This terminate is called from lcp_finished()

Thu, 2010-06-03 17:20:20 - Connection terminated.

Thu, 2010-06-03 17:20:20 - Connect time 119.7 minutes.

Thu, 2010-06-03 17:20:20 - Sent 15385517 bytes, received 88539381 bytes.

Thu, 2010-06-03 17:20:20 - Doing disconnect

Thu, 2010-06-03 17:20:20 - Exit.

Po czym następuje ponowne połączenie (prawidłowo).

LCP odpowiada za sprawdzanie aktywności linii i połączenia, np. przy ustawiony timerze "nieaktywności" ma za zadanie zakończyć sesję PPP i wyłączyć interfejs ADSL. Ale co robi w pokazanym przypadku i dlaczego, tego nie wiem.

Sprawdź :

http://www.tp.pl/prt/pl/klienci_ind/obslug.../bezp/bezp_usl/

(opcja: BEZ_OCHRONY)

Nie rozumiem skąd i dlaczego jest to:

Thu, 2010-06-03 17:20:12 - We have just avoided a PPPRceivedTerminate right now

Może Sevard będzie wiedział, ja nie mam dostępu do identycznego routera żeby sprawdzić czy podobne wpisy normalnie pojawiają się w logu.

Ustaw na routerze MTU = 1492, albo lepiej 1462. Toretycznie bez znaczenia dla sprawy, praktycznie ... różnie bywa z tym MTU.

A powiem Ci, że wcale bym się nie zdziwił gdyby chodziło o jakiegoś robaka "wycelowanego" w użytkowników konkretnego modelu routera. Były już masowe włamania na routery Siemens, po włamaniu robal dopisywał swój IP w jednym miejscu konfigu ... potem robił ciekawsze rzeczy.

[Sevard]

Nie rozumiem skąd i dlaczego jest to:

Thu, 2010-06-03 17:20:12 - We have just avoided a PPPRceivedTerminate right now

Może Sevard będzie wiedział, ja nie mam dostępu do identycznego routera żeby sprawdzić czy podobne wpisy normalnie pojawiają się w logu.

Też nie wiem co to jest, ale się pojawia przy okazji rozłączeń.

LCP działa jak ping, gdy nie uzyska on odpowiedzi, to uznaje, że coś jest nie tak z połączeniem i je zrywa. W zależności od ustawień routera/modemu robi to po którymś kolejnym błędzie, lub w ogóle. Nie wiem, jak to wygląda w przypadku tego Linksysa. Prawdopodobnie przyczyną jest jednak to, że ten pakiet z jakichś powodów ginie (fragment "Thu, 2010-06-03 17:20:14 - lcp echos pending >= lcp_echo_fails! ") i router głupieje. b3rt napisał, że na modemie też się tak działo, więc sądzę, że problemem może być linia, tylko pytanie co dokładniej. Na początek sprawdziłbym kabel łączący router i gniazdko telefoniczne. Warto też sprawdzić za pomocą jakiegoś sniffera, czy pakiety nie giną. Łatwym w obsłudze snifferem programowym jest Wireshark.

Jaka jest wartość

DSL Path Mode:

w Status>DSL Connection (możliwe wartości to Fast i Interleaved)?

[b3rt]

DSL Path Mode: Interleaved

Swoją drogą, mała ciekawostka, a dokładniej to dwie ciekawostki. Pierwszą jest gość z infolinii TP (tak, spamuje im tą infolinię), który powiedział że to mogą być przeciążenia na linii. Do linii telefoniczno-internetowej mam podłączone dwa aparaty telefoniczne i dwa, w porywach trzy komputery (czasami laptopa podłączam bezprzewodowo). Jeszcze niedawno miałem internet 1 Mb/s, i wszystko działało dobrze. Problem zaczął się pojawiać jak zwiększyłem prędkość do 2 Mb/s. Na początku to nie przeszkadzało, bo rozłączało się raz dziennie, ale teraz jest jak jest... Gość po prostu stwierdził że linie mogą nie wytrzymywać, i przez to przerywa, ale wszystkie informacje od TP traktuje z dużą ostrożnością

Drugą ciekawostką jest fakt, że moja mama zaczęła mi się dzisiaj skarżyć na dziwne działanie telefonu. Sam się rozłącza podczas rozmowy, kilka razy dziennie pojawiają się "głuche telefony", a często jest tak, że dzwoni, i jak się odbierze to słychać tylko trzy piski, po czym pojawia się sygnał, jakbym to z mojego telefonu do kogoś dzwonił. Kiedyś też się tak działo, i myślałem że to wina aparatu, ale wymieniłem go w środę, a problem zamiast zniknąć, jeszcze się spotęgował. Mówiłem o tym na infolinii TP, ale u nich oczywiście wszystko jest ok, jak zawsze zresztą....

Doprawdy, dziwy nie z tej ziemi

EDIT: Aha, i co z tym WireSharkiem? Program stworzy jakiś log który mam tu zamieścić, czy jak?

[Sevard]

Skoro do tego zrywa normalne połączenia telefoniczne, to dzwoń na infolinię techniczną. Problemem może być uszkodzony kabel, lub jakieś uszkodzone urządzenie podłączone do linii, trudno stwierdzić. Router jest najprawdopodobniej w takim układzie niewinny. Powinien to sprawdzić technik.

Wireshark zaznacza uszkodzone pakiety na czarno, więc łatwo stwierdzić, czy się jakieś pojawiają, czy nie. W tym przypadku niepotrzebne są logi, wystarczy użyć oczu. Po prostu uruchamiasz nasłuchiwanie na odpowiednim urządzeniu i jakiś czas czekasz. Potem sprawdzasz, czy są jakieś czarne wpisy. mam tylko nadzieję, że router ich nie odfiltruje, ale nie powinien.

DSL Path Mode: Interleaved

W normalnych warunkach jest to złe ustawienie (większe pingi), ale to przy trybie Fast mogą pojawiać się pojedyncze uszkodzone pakiety, przy Interleaved nie powinny.

[SwisteK]

W tej chwili tryb "interleaved" jest ustawiany "z urzędu" dla wszystkich łącz powyżej 512. Co najwyżej wielkość przeplotu może litościwy technik zmienić (żeby nie był czterocyfrowych pingów), ale te ustawienia są zarządzane zdalnie i po każdym restarcie portu będzie na centrali będzie włączony "typowy" (dla danej prędkości) przeplot.

b3rt - kable do sprawdzenia, w domu i na zewnątrz. Zgłaszaj i molestuj do skutku

[b3rt]

Zrobiłem sobie ten test Wiresharkiem. Na początku wszystkie pakiety wyświetlają się na zielono, po chwili zaczynają się pojawiać czarne. Dodatkowo jest sporo niebieskich. Jednak z tego co widzę to czarnych jest dość sporo. BTW, zrobiłem sobie ten test również po podpięciu modemu Sagem F@ST 800, i wynik jest praktycznie ten sam.

Zgłaszaj i molestuj do skutku

Na razie męczę ich co chwile. Ciągle się upierają że "z ich strony jest wszystko dobrze". Ale kiedyś się złamią. Każdy się łamie

[b3rt]

Odświeżam temat tylko po to żeby powiedzieć że problem jest nieaktualny. Miałem szczęście i trafiłem na kompetentnego człowieka na infolinii TP (w niedzielę!), który powiedział że zmieniali ostatnio ustawienia w centrali, po czym odpisał ode mnie model routera, podyktował mi łopatologicznie jakie mam wprowadzić ustawienia, sam też coś podobno u siebie pozmieniał, i wszystko jak na razie działa jak należy. Problem rozwiązywaliśmy w niedzielę rano, jest poniedziałek popołudniu, a internet ani razu nie przerwał połączenia, gry nawet przestały lagować i w ogóle jak na razie jest gites.

Także problem uważam za zakończony, temat do zamknięcia.

[Sevard]

Problem rozwiązany, więc temat zamykam.

W razie potrzeby otwarcia tematu, proszę o kontakt przez PW.