DawidS28

Pięknie. Dostawca (albo Twój router) blokuje pakiety ICMP, dzięki czemu nawet nie jestem w stanie ocenić, którędy idzie transmisja do Facebooka. Ponieważ problem dotyczy dziś większej liczby użytkowników, jestem skłonny zaryzykować stwierdzenie, że usterka leży u jakiegoś operatora, przez którego infrastrukturę idą połączenia do Facebook.com.

Jeszcze jedno, o którym zapomniałem: pathping facebook.com >> C:\cmd_log.txt Potem do wrzucenia ten sam plik.

Nie znam żadnej możliwości, żeby obecne ustawienie mogło w jakiś sposób zaszkodzić. Niech zostanie. I tak dotyczy tylko komunikacji do localhost, a nie normalnych połączeń z Internetem. Co do głównego problemu: ponieważ widzę, że problem z Facebookiem ma dużo użytkowników, to zrobimy diagnostykę dostosowaną pod Facebook.com. Start -> Programy -> Akcesoria -> prawym na: Wiersz poleceń -> Uruchom jako administrator. Wpisz komendy (po każdej naciskając Enter): netsh int ip show int > C:\cmd_log.txt tracert facebook.com >> C:\cmd_log.txt nslookup facebook.com >> C:\cmd_log.txt nslookup facebook.com 8.8.8.8 >> C:\cmd_log.txt ping -f -l 1444 facebook.com >> C:\cmd_log.txt ping -f -l 1464 facebook.com >> C:\cmd_log.txt Po wykonaniu poleceń wrzuć jako załącznik C:\cmd_log.txt.

Uzasadnij, w jaki sposób ewentualny problem na Twoim komputerze ma wpływać na działanie pozostałych urządzeń w sieci bezprzewodowej. Nie jesteś w stanie normalnym komputerem wygenerować takich zakłóceń, żeby oddziaływały na resztę sieci. Jeśli to by była Neostrada (czyli ADSL), to postawienie modemu na wadliwym zasilaczu jest w stanie skutecznie uniemożliwić działanie usługi, zwłaszcza, jak parametry linii są słabe. Proponuję jeszcze rozejrzeć się za jakimś sprzętem, który może powodować takie zakłócenia, np. kuchenki mikrofalowe. Według mnie odpowiedź jest jedna: router nie radzi sobie z poprawnym funkcjonowaniem WiFi i pod wpływem takiego typu obciążenia zaczynają pojawiać się przerwy w działaniu. Widziałem już naprawdę wiele Linksysów, które zawieszało się z mniej lub bardziej oczywistych powodów. To nie jest prawdziwe Cisco, tylko firma przez Cisco przejęta kilka lat temu, a niedawno (miesiąc temu) sprzedana do Belkin.

Większość ICSI Netalyzr niewykonana. Net-log praktycznie analogiczny do tego, co było widać na poprzednim, natomiast screeny z testów pozwalają już zauważyć problem. Według mnie do zgłoszenia dostawcy.

Jesteś w dziale Sieci. Zastosuj się do jego zasad: http://www.fixitpc.p...w-dziale-sieci/

Jesteś w dziale Sieci. Zastosuj się do jego zasad: https://www.fixitpc.pl/forum-44/announcement-11-wazne-zasady-obowiazujace-w-dziale-sieci/

Tylko, że z Twoich logów i ze screenów, które pokazujesz, nie widać żadnych problemów. Chciałem poszukać, czy są inne zgłaszane problemy z tym dostawcą.

Na drugim komputerze też widać problem, chociaż środowisko zupełnie inne. Moim zdaniem winny jest router i należałoby go wymienić. Jeśli masz dostęp do jego konfiguracji, to proponuję zresetować go do ustawień domyślnych, skonfigurować od nowa i sprawdzić działanie. Jeżeli to nie pomoże, to - przynajmniej moim zdaniem - router jest uszkodzony.

Po nazwie sieci lub adresie MAC, przynajmniej tak sądzę. Ewentualnie jest wyliczana jakaś suma kontrolna z parametrów sieci i potem według tego się porównuje. Niezabezpieczone sieci bezprzewodowe? Tylko teraz to już są moje przypuszczenia. Mogę sprawdzić i odpowiedzieć później.

Pingi bardzo dobre, jitter minimalny, więc skoków pingu nie powinno być. Względem czego testujesz ping?

Zmieniałeś MTU dla złego interfejsu, akurat dla pętli zwrotnej, czyli loopback. Nie wiem, czemu ma MTU równe 1500 B. Niech tak będzie, ale domyślnie pod Windows 7 jest 4294967295, czyli pełny zakres unsigned int (maksymalna liczba, jaką można zapisać na 32 bitach bez bitu znaku). Niech tak zostanie, ale pamiętaj o tym. Wpisz z uprawnieniami admina polecenia: netsh int ip set int 10 mtu=1472 netsh int ip set int 11 mtu=1472 Potem uruchom ponownie komputer.

Tak na początek poza tematem. Co sądzisz o tym? http://www.niezgrani.pl/2013/02/18/dlaczego-w-world-of-tanks-nigdy-nie-bedziesz-kiepskim-graczem/ Stawianie serwera do czegokolwiek na takim łączu, to jest proszenie się o problemy. Już lepiej wykupić sobie jakiś mały hosting i z niego korzystać. Nie będzie drogo, a będzie działać idealnie u wszystkich poza Tobą, bo - jak sam zauważyłeś - masz problemy. Chodzi o kartę WiFi czy normalną kablową Ethernet? Opis wskazuje ewidentnie na przegrzewanie się. Zainstaluj HWINFO i pokaż screen z okienka "sensors". Widać potężne problemy już przy samym łączeniu się z siecią bezprzewodową. Czy jesteś w stanie wykonać raport z Net-log z innego komputera, który działa po WiFi? Chciałbym je porównać. Sygnał wygląda na silny, jest w porządku, ale połączenie praktycznie nie działa. Proszę jeszcze o poniższe informacje:

Polecenie netsh int ip reset reset.log? Wklejenie w uruchom i wywołanie tego nie pójdzie, bo komenda wymaga do działania uprawnień administratora. Jedyna szansa, że to poszło jest taka, że miałeś wyłączone UAC (Kontrola konta użytkownika), wtedy wszystko uruchamia się z uprawnieniami administracyjnymi. Normalnie trzeba przez Akcesoria -> Wiersz poleceń -> Uruchom jako administrator. Na przyszłość: staraj się pamiętać/zapisywać, jakie komendy wykorzystujesz. Jaki ping test? Może jakieś wyniki do niego? Sprawdź, co pokazują http://speedstest.net i http://pingtest.net Daj linki do wyników z nich. Net-log wygląda tak, jakby dostawca filtrował komunikaty ICMP, a to mnie bardzo nie cieszy. Raz, że nie pozwala na proste badanie łącza, dwa: może powodować wiele problemów z działaniem sieci, chociażby uniemożliwia działanie Path MTU Discovery (więcej tutaj: http://www.fixitpc.p...nsmission-unit/). Dostawca to Shentel Network? Ruch do D-Linka i do pierwszego routera dostawcy wygląda w porządku, co się dzieje dalej ciężko powiedzieć - patrz akapit wyżej. Na próbę połącz się z routerem kablem Ethernet i sprawdź, czy wtedy będzie działać lepiej.

Identyfikacja sieci pod Windows to po prostu łączenie się z tą siecią. System dokonuje uwierzytelnienia, pobiera adres IP, buduje tablicę routingu, sprawdza połączenie z Internetem poprzez próbę dostępu do jakiegoś zewnętrznego serwera, generuje statystyki do Centrum sieci i udostępniania, a potem wyświetla stosowny komunikat o połączeniu (zakończonym powodzeniem lub nie). Tyle w tak naprawdę dużym skrócie. Jeżeli sieć nie została zidentyfikowana, to znaczy, że któryś z tych etapów zakończył się niepowodzeniem. Nie ma jednego rozwiązania, które pozwalałoby pozbyć się tego komunikatu i braku dostępu do Internetu, bo może się on wyświetlać z różnych przyczyn. Akurat to się ustawia ręcznie i chodzi o ustawienia udostępniania danych i zapory/firewalla. Można to konfigurować z Centrum sieci i udostępniania: http://www.sevenforums.com/tutorials/43629-network-location-set-home-work-public-network.html Access Point rozgłasza ją w tzw. ramkach beacon. Pokaż przypadek, gdy jedna sieć ma wiele SSID. To są wtedy odrębne sieci, bez znaczenia, czy emitowane są z tego samego access pointa, czy z różnych. W jednej sieci może być wiele BSSID, które identyfikują odpowiedniego access pointa i pozwalają na roaming między nimi. Chodzi o to, że możesz poruszać się po większym budynku i nie łączyć się osobno do każdej sieci, tylko być cały czas w jednej, a zmieniać tylko punkty dostępowe. Sieci możesz sobie wylistować pod Windows poleceniem netsh wlan show all, poniżej przykład sieci z jednym SSID i dwoma BSSID (czyli roamingu): SSID 3 : AdminWirelessNetwork Typ sieci : Infrastruktura Uwierzytelnianie : WPA2-Enterprise Szyfrowanie : CCMP BSSID 1 : d3:c5:67:2a:54:bc Sygnał : 2% Typ radia : 802.11g Kanał : 1 Podstawowe szybkości transmisji (Mb/s): 1 2 5.5 11 Inne szybkości transmisji (Mb/s): 6 9 12 18 24 36 48 54 BSSID 2 : d3:c5:67:52:11:52 Sygnał : 4% Typ radia : 802.11g Kanał : 11 Podstawowe szybkości transmisji (Mb/s): 1 2 5.5 11 Inne szybkości transmisji (Mb/s): 6 9 12 18 24 36 48 54 Komputer uzyskuje adres IP z serwera DHCP, który zazwyczaj jest uruchomiony na routerze. Jest cała procedura uzyskiwania adresu IP, w tym momencie nie musimy się na niej skupiać. Rzecz w tym, że odpowiedzi z serwera DHCP do klienta mogą być wysyłane jako pakiety unicast (skierowane do konkretnego klienta), ale mogą być także rozsyłane jako broadcast (dostaje je cała sieć, w tym uzyskujący adres klient). Można to kontrolować poprzez ustawienie odpowiedniej flagi w pakietach DHCP wysyłanych do serwera przez komputer, który chce uzyskać połączenie, jednak nie wszystkie serwery je poprawnie przetwarzają. W Windows XP klient oczekiwał odpowiedzi jako unicast i zazwyczaj to działało. W Windows Vista wymuszany był już broadcast jednocześnie bez domyślnego zapewnienia możliwości sprawdzenia, czy serwer DHCP obsługuje takie komunikaty. Powodowało to czasem problemy, których głównym objawem był brak dostępu do Internetu, stosowny komunikat o niezidentyfikowanej sieci oraz adres IP przyznany z puli 169.254.0.0/16, czyli tzw. adres link-local, przyznawany, gdy serwer DHCP jest niedostępny. Windows 7 i nowsze ma już to rozwiązane normalnie, najpierw domyślnie wysyła 4 komunikaty DHCP z ustawionym żądaniem odpowiedzi unicast i czeka na odpowiedź, potem kolejne 4 z ustawionym broadcast. System zapamiętuje, w jaki sposób ostatnio uzyskał adres i z tej metody później korzysta. Tylko, że "toggling" sprawia, że całe sprawdzanie może trwać ponad minutę i stąd komunikat "Trwa identyfikowanie...". Więcej o tym możesz poczytać: http://blogs.technet.com/b/teamdhcp/archive/2009/02/12/dhcp-broadcast-flag-handling-in-windows-7.aspx http://support.microsoft.com/kb/928233/en-us Ten sam problem z siecią niezydentyfikowaną może być spowodowany przez uszkodzenie Winsock. Zazwyczaj powodowane są przez programy antywirusowe (wpinają się w Winsock, żeby skanować cały ruch sieciowy) i Multicast DNS (np. Apple Bonjour): https://www.fixitpc.pl/topic/8870-naprawa-reset-katalogu-sieciowego-winsock/

Trochę tych błędów CRC i HEC się pojawia, ale to raczej tego, że jedziesz na granicy możliwości swojego łącza i, jak widać, na razie działa. Tłumienie się nie chwieje, SNR Margin też nie, więc tutaj OK. Raport z Net-log nie pokazuje żadnych problemów. Poproszę jeszcze link do wyników z ICSI Netalyzr.

Chodzi prawdopodobnie o ADSL/ADSL2/ADSL2+. Użycie modemu ADSL bez obsługi ADSL2(+) wymusi zastosowanie synchronizacji ADSL G.dmt, co powinno się udać, ponieważ jeżeli karta centralce jest kompatybilna z ADSL2(+), to także obsługuje czyste ADSL. Oczywiście prędkość nie będzie wyższa, niż 8 Mb/s (w praktyce jest to jakieś 6 - 7 Mb/s), ponieważ na więcej pozwala dopiero ADSL2 i ADSL2+. Odpowiednio jest to 12 i 20 Mb/s. I wszystko byłoby dobrze, gdyby nie fakt, że to nie wyłącznie modem i centralka ustalają synchronizację na podstawie parametrów łącza (Rate Adaptive), ale są jeszcze przedziały dopuszczalnej synchronizacji ustawione przez dostawcę. Np. dla opcji "do 20 Mb/s" przedziały to 10 - 20 Mb/s i dzięki temu, gdy ktoś podepnie modem obsługujący tylko stare ADSL G.dmt, np. Thomson SpeedTouch 330 po USB, to nigdy nie uzyska on jakiejkolwiek synchronizacji, ponieważ ADSL pozwala tylko na transmisję do klienta z prędkością maksymalną równą 8 Mb/s. A to jest ostro mniej niż 10 Mb/s. Co do screenów. Statystyki są z kilknastu zaledwie minut, więc niewiele mówią. Modem wskazuje, że jest w stanie wyciągnąć 14 Mb/s pobierania, prawdę powiedziawszy, przy takim SNR Margin jest to mało prawdopodobne, chociaż tłumienie pozwala o tym myśleć. Znane są przypadki, gdy SNR Margin było sztucznie obniżane poprzez obniżanie mocy, zwłaszcza, gdy klient znajduje się blisko centralki. Widać trochę błędów, ale screen jest z około kwadransa, czyli dosyć mało, żeby ocenić linię. Na koniec proszę o uzupełnienie wymaganych ogłoszeniem działu Sieci logów: https://www.fixitpc.pl/forum-44/announcement-11-wazne-zasady-obowiazujace-w-dziale-sieci/

Jeżeli piszesz w kontekście mojego zasilacza, to już dawno umarł ze starości, kupiłem OCZ i nie ma problemu. Z Sadistic.pl jest problem, Mistrzowie.org i Demotywatory.pl również. Problem zaczyna się gdzieś w okolicach routera fra-5-6k.fr.eu [91.121.131.97], przez który idzie ruch do Francji, przynajmniej z TP. Ten router należy do OVH, a OVH hostuje wszystkie w.w. serwisy. Od innych dostawców routing może iść inaczej, więc mogą u nich nie występować problemy. Warto zauważyć, że TP ma bardzo słaby peering z innymi operatorami.

FEC i HEC nie warto się bardzo przejmować, ważniejsze są CRC (uncorrectable errors). Liczba błędów zależy od zakłóceń panujących na łączu. Mogą być one powodowane przez bardzo wiele czynników, np. transmisję na równoległych liniach abonenckich, urządzenia elektryczne znajdujące się w pobliżu kabli (zasilacz do mojego starego komputera powodował podbicie o jakieś 103 razy liczby błędów). Mogą być wreszcie powodowane przez wadliwą instalację. Doświadczalnie można stwierdzić, że linia jest najstabilniejsza rano (u mnie godziny 6 - 10), wieczorem zaczynają się problemy, bo więcej użytkowników korzysta. Przykład z logów, że są dobre okresy i słabe okresy: Time TxCrcErr TxFecErr RxCrcErr RxFecErr Los Sef LosSec SefSec ErrSec RxBlk TxBlk SNR Atten 23:03:33 0 0 1 143 0 0 0 0 6 53178 53178 9.0 27.0 22:48:32 0 0 2 258 0 0 0 0 9 53178 53178 9.0 27.0 22:33:31 0 0 0 171 0 0 0 0 7 53179 53178 9.0 27.0 22:18:30 0 0 1 25 0 0 0 0 6 53178 53179 9.0 27.0 22:03:30 0 0 2 162 0 0 0 0 8 53178 53178 9.0 27.0 21:48:29 0 0 1 195 0 0 0 0 6 53178 53178 9.0 27.0 21:33:28 0 0 3 1734 0 0 0 0 18 53178 53178 9.0 27.0 21:18:27 0 0 0 46 0 0 0 0 5 53178 53178 9.0 27.0 21:03:26 0 0 1 69 0 0 0 0 2 53178 53178 9.0 27.0 20:48:25 0 0 0 107 0 0 0 0 5 53178 53178 9.0 27.0 20:33:24 0 0 2 179 0 0 0 0 7 53179 53178 9.0 27.0 20:18:23 0 0 4 390 0 0 0 0 37 53166 53167 9.0 27.0 20:03:22 0 0 3 226 0 0 0 0 4 53190 53190 9.0 27.0 19:48:21 0 0 2 323 0 0 0 0 7 53178 53178 9.0 27.0 19:33:20 0 0 0 310 0 0 0 0 26 53178 53178 6.5 27.0 19:18:20 0 0 0 1528 0 0 0 0 202 53166 53166 7.0 27.0 19:03:19 0 0 0 8667 0 0 0 0 346 53179 53178 6.5 27.0 18:48:18 0 0 0 13263 0 0 0 0 900 53178 53179 9.0 27.0 18:33:17 0 0 0 24584 0 0 0 0 900 53154 53154 9.0 27.0 18:18:16 0 0 0 17537 0 0 0 0 900 53202 53202 9.5 27.0 18:03:15 0 0 0 14565 0 0 0 0 484 53178 53178 9.5 27.0 17:48:14 0 0 1 13658 0 0 0 0 530 53179 53179 6.0 27.0 17:33:13 0 0 1 5827 0 0 0 0 401 53179 53179 9.0 27.0 17:18:12 0 0 1 5750 0 0 0 0 377 53178 53178 9.5 27.0 17:03:11 0 0 3 413 0 0 0 0 17 53179 53178 6.0 27.0 16:48:11 0 0 0 104 0 0 0 0 4 53178 53179 7.5 27.0 16:33:10 0 0 0 22 0 0 0 0 7 53178 53178 7.0 27.0 16:18:09 0 0 0 2 0 0 0 0 1 53166 53166 7.0 27.0 16:03:08 0 0 1 171 0 0 0 0 37 53190 53190 9.0 27.0 15:48:07 0 0 0 4 0 0 0 0 4 53166 53166 9.0 27.0 15:33:06 0 0 2 302 0 0 0 0 9 53178 53178 9.0 27.0 15:18:05 0 0 3 208 0 0 0 0 3 53178 53178 9.0 27.0 15:03:04 0 0 0 0 0 0 0 0 0 53178 53178 9.0 27.0 14:48:03 0 0 1 527 0 0 0 0 32 53179 53178 9.0 27.0 14:33:02 0 0 1 12945 0 0 0 0 900 53178 53179 9.0 27.0 14:18:02 0 0 8 14294 0 0 0 0 900 53178 53178 9.0 27.0 14:03:01 0 0 0 11578 0 0 0 0 897 53084 53084 8.5 27.0

Skoro zamieściłeś temat w dziale Sieci, to proszę o wykonanie wymaganych logów: https://www.fixitpc.pl/forum-44/announcement-11-wazne-zasady-obowiazujace-w-dziale-sieci/

diox, proponuję zwrócić uwagę na routing do forum (polecenie tracert). Zazwyczaj dochodzi do xe0-1-0.cloud.leaseweb.net [85.17.129.217], a potem się gubi. Tutaj dochodziło do jednego węzła wcześniej, czyli po100.sr1.evo.leaseweb.net [85.17.100.226]. Zakładając, że nie jest to po prostu skrócenie ścieżki przez wywalenie jednego routera i bezpośrednie podpięcie serwera z forum do routera wcześniej, to albo świadczy to o błędzie w routingu, albo o celowym odcięciu kawałka sieci, np. w celu przeprowadzenia konserwacji serwerów. I jedno, i drugie nie jest zależne od Fixitpc.pl.

Może tego nie widzę na screenach, ale chodziło mi o to: Nie ma być tak skonfigurowane oczywiście, tutaj jest ustawione pełne udostępnianie połączenia, czyli dla Twojego przypadku źle. Masz mieć wszystko odznaczone. Jeśli czegoś takiego nie masz, to nie ma problemu. Nie mam żadnego XP Home pod ręką, żeby to sprawdzić. Bardziej zastanawiające są statystyki z Liveboksa. Jak na około 110 godzin trwania połączenia ADSL liczba błędów jest dosyć duża i świadczy o problemach z łączem. Dla downstream (pobierania) tłumienie, SNR Margin i sama prędkość synchronizacji wygląda poprawnie, natomiast dużo gorzej wygląda upstream, synchronizacja na poziomie około 700 kb/s to zdecydowanie poniżej średniej dla opcji "do 10 Mb/s", a przy takim tłumieniu (9 dB) powinno pójść zdecydowanie więcej. Ja mam jakieś 1150 kb/s przy tłumieniu 14,5 dB, widziałem też ponad 1000 kb/s przy tłumieniu 30 dB i działało. Ale tutaj wkracza SNR Margin, który jest prawie graniczny (8 dB, granicą jest 6 dB), i który nie pozwala na rozwinięcie prędkości. Ogółem. Wygląda na to, że linia bardzo traci na jakości przy niskich częstotliwościach. Może to być zależne od wielu czynników, najbardziej prawdopodobnym jest słaba jakość instalacji w domu, uszkodzony lub niewłaściwie zainstalowany mikrofiltr, wreszcie uszkodzenie samego Liveboksa (sprzęt jest, nawiasem mówiąc, bardzo awaryjny). W drugiej kolejności podejrzewałbym uszkodzenie samej linii Orange/TP. Proponuję sprawdzić kabelki, pożyczyć od kogoś modem do Neostrady, spróbować się na nim połączyć i sprawdzić statystyki. Koszt mikrofiltra to około 5 PLN, a raz na jakiś czas warto wymienić. Jak to nie pomoże, to sytuacja do zgłoszenia do Orange. Jeżeli sugerować się samym tłumieniem i zakładać w miarę normalny stan sieci (co będzie się przekładało na SNR Margin), to przy takich parametrach jesteś w stanie wyciągnąć jakieś 14 Mb/s. Oczywiście tylko wtedy, gdy uda się usunąć awarię.

Może przypomniała sobie miejsce jej pozostawienia.

http://www.youtube.com/watch?v=CxGu5HjarmU

To jest kwestia braku znajomości mod_rewrite przez twórcę strony simcity.ea.com, bo można było zrobić przekierowania dla wszystkiego, co jest w domenie na ten facebookowy adres. Temat zamykam.