DawidS28

Bo na tym porcie dostawca włączył captive portal.

Dostawca zablokował - ja nie odblokuję. Są co prawda metody obchodzenia tego, ale skoro płacisz za usługę, to po co kombinować. Skontaktuj się z ISP.

Twój router jest pod adresem http://192.168.1.1 i żeby cokolwiek sprawdzić, musisz mieć do niego dostęp. Jeżeli nie da się tak, to możesz spróbować przeskanować wszystkie porty w poszukiwaniu tych, na których router nasłuchuje na pakiety. Zainstaluj WinPcap: http://www.winpcap.org/ Potem pobierz to, wrzuć w jakieś miejsce, z którego będziesz mógł łatwo z CMD korzystać, ponieważ może kiedyś się przydać, to polecam Windows\System32, nie trzeba będzie za każdym razem ścieżki wpisywać: http://netdiag.pl/programs/tracetcp.exe Potem otwórz Wiersz poleceń, wpisz komendę tracetcp 192.168.1.1 -t 20 -s 1 65535 | find "OPEN" > C:\cmd_log.txt i po kilku minutach, jak się wykona, to poproszę C:\cmd_log.txt jako załącznik.

Czyli filtrowanie na routerze albo u dostawcy.

I jakaś poprawa? Domyślam się, że nie, co by wskazywało na dosyć brutalne wycinanie komunikacji ze stronami WWW. Spróbuj testowo zainstalować HotSpot Shield i przez niego połączyć się z dowolnie wybranym adresem z powyższych. Bez dostępu do routera nie jesteś w stanie usunąć tej blokady, chyba, że masz fizyczny dostęp do urządzenia i możesz go bez obaw zresetować.

Daj nowy Net-log. Chcę zobaczyć, ile się przez ten czas zmieniło. Tak samo statystyki ADSL.

Ok, zatem szybko tego nie przywrócimy do normalnego działania bez dostępu do routera. Ustaw sobie DNS-y na 8.8.8.8 i 8.8.4.4 według tego poradnika: http://netdiag.pl/artykuly/dns/

Ok, złe IP wziąłem. Teraz widzę, że masz jeszcze Hamachi. Tak pięknie pula wyglądała na publiczne IP, inne niż od Twojego dostawcy, od razu skojarzyłem z HSS, a tu jednak nie. Chodzi o tę linię: 68.68.107.8 255.255.255.255 192.168.1.20 192.168.1.101 20 Po czym poznać? Pierwszy adres będzie zmienny, to jest serwer HSS. Maska zawsze ustawiona na 255.255.255.255, bo wskazuje tylko jeden host. Adres bramy na 192.168.1.20, bo komunikacja ma przechodzić następnie przez Twój router, a nie tunelem, czy to z HSS-a, czy z Hamachi. Adres interfejsu wyjściowego to IP, które dostajesz od routera. Po raz kolejny powód tego, że komunikacja (zaszyfrowana) z serwerem HSS musi iść normalnym łączem. Pakietami do adresu 68.68.107.8 idzie ten wirtualny tunel, tylko tego z zewnątrz nikt nie widzi. A dokładniej: wszyscy widzą, że to VPN, ale nikt nie wie, co w nim jest. Metryka na 20, ewentualnie inna niska liczba. Ostatni pathping nic nie warty, bo test jest przeprowadzony względem Twojego komputera, no to wiadomo, że skoro sieć, po której idą pakiety ogranicza się do jednego urządzani, to wyniki będą idealne. Uważaj na jednoczesne wykorzystywanie Hamachi i HSS, bo może Ci się routing pogryźć. Teraz tunel z Hamachi idzie przez tunel z HSS, co nie jest optymalnym rozwiązaniem i może powodować dziwne błędy. HSS ma poblokowane porty. Bardzo dużo. Możesz to zobaczyć w ICSI Netalyzr, jest taka dosyć długa lista usług, z którymi nie udało się połączenie, bo porty są filtrowane. Normalne zjawisko na darmowych VPN-ach. Nie wiem, dlaczego połączenie się zrywa. Może mają jakiś sposób dynamicznego wykrywania nieodpowiednich działań i z miejsca je ucinają. Ja tak robiłem, jak mi ludzie na serwerze "wydobywali" bitcoiny. Dwa razy zabijałem (ręcznie), za trzecim blokowałem uruchamianie binarek. Przywrócenie tylko na pisemny wniosek, a to już idzie do akt. Moich prywatnych, ale zawsze.

Dokładnie, to jest spychologia stosowana. Przewidywanie, ilu klientów będzie jednocześnie korzystać z centralki i z jakiej przepustowości będą korzystać. Modele oparte są zazwyczaj na z d... księżyca wziętych przesłankach. A i prawdę powiedziawszy, takich rzeczy nie da się przewidzieć. Ja jedyne, czego się podejmuję, to ustawienia aktualizacji na godz. 3 w nocy i backupów na godz. 5 rano, ponieważ to drugie robi się częściowo zdalnie, a najmniejszy ruch jest zazwyczaj między 5 a 9 rano (patrz: statystyki PLIX albo TPIX, czyli międzyoperatorskich węzłów wymiany ruchu). Tylko że nie wyobrażam sobie przeciążenia centralki przez ADSL. Przez łącze, które idzie z centralki do jakiegoś routera brzegowego Netii, to nie ma problemu. Nie pierwszy i nie ostatni raz. Możliwe, że uruchomili za dużo linii ISDN, a te potrafią generować spore zakłócenia, ale jakoś nie wyobrażam sobie powszechnego użycia tej technologii w obecnych czasach. Za droga i za mało wydajna. No cóż. Tak samo nie wyobrażam sobie sztucznego zbijania synchronizacji ADSL w celu ścięcia pasma poszczególnym użytkownikom. Za skomplikowane, DLM został przez Orange/TP wprowadzony jakiś rok temu i do tej pory mają potężny problem z ogarnięciem jego działania. Zarówno tam na górze, jak i wśród techników. Pozostaje kwestia, czy cała linia i centralka są Netii (CU), czy tylko centralka (albo jej kawałek) jest Netii (LLU), czy wreszcie i kable, i centralka należą do Orange (BSA). W przypadku dwóch ostatnich rozwiązań nic mnie już chyba nie zdziwi, bo w LLU Netia nie odpowiada za to, w jakim stanie są kable i co po nich idzie, a w ostatnim modelu Netia nie odpowiada za nic, poza rozliczaniem faktur (no tak w skrócie). Przekazywanie informacji między Netią a Orange jest, jak pewnie sam zauważyłeś, niezadowalające. Przy czym, w mowie nie użyłbym tego słowa. A pismo zostaje, więc...

Zmień hasło na jakieś bardziej skomplikowane, idzie się domyślić. Wireless mode ustaw na WPA2 mode only. Tyle, jeśli chodzi o bezpieczeństwo bezprzewodówki.

Ok, widać, że niskie prędkości synchronizacji są powodowane przez niską jakość linii, a nie na przykład karną blokadę od DLM za zbyt częste zrywanie połączenia. Po prostu przy ADSL linia na więcej fizycznie nie pozwala. Tym razem pingi w normie. Strata 1/100 pakietów to jest nic. 0/ 100 = 0% | 1 1ms 0/ 100 = 0% 0/ 100 = 0% mikrotik [192.168.111.1] 0/ 100 = 0% | 2 1ms 0/ 100 = 0% 0/ 100 = 0% siemens [192.168.222.1] 0/ 100 = 0% | 3 40ms 0/ 100 = 0% 0/ 100 = 0% kra-bg2.neo.tpnet.pl [83.1.4.50] 0/ 100 = 0% | 4 34ms 0/ 100 = 0% 0/ 100 = 0% kra-r2.tpnet.pl [80.50.157.233] 0/ 100 = 0% | 5 34ms 0/ 100 = 0% 0/ 100 = 0% kra-ru3.tpnet.pl [80.50.159.70] 1/ 100 = 1% | 6 60ms 1/ 100 = 1% 0/ 100 = 0% aaqa230.neoplus.adsl.tpnet.pl [83.5.160.230] To może (ale nie musi!) sugerować problemy z Livebox. Może się po prostu zawieszać i utrudniać, a nawet uniemożliwiać, w ten sposób komunikację. Błędów na razie nie widać, ale to tylko dlatego, że jeszcze nie miały czasu się wygenerować. Zawsze jakieś się pojawiają i nic z tym nie zrobisz, taka natura sygnałów ciągłych (analogowych).

To masz w końcu WiFi w routerze czy nie? Jeżeli masz, to podłączasz się do routera przy pomocy dowolnego komputera, może być po kablu, logujesz się do strony konfiguracyjnej i wyłączasz WiFi i masz spokój.

Livebox pokazuje dosyć mało statystyk, z których ciężko wyciągnąć więcej użytecznych informacji. Z tego, co pokazuje, to można wnioskować, że masz synchronizację ADSL pozwalającą na transmisję z prędkością 6,7 Mb/s dla download i 0,72 Mb/s dla upload. Jednak pojawia się problem stabilności linii. Każdy błąd, który wystąpił w transmisji, musi zostać skorygowany. Błędy CRC (ich na szczęście jest niewiele) powodują, że konieczne jest przesłanie fragmentu danych jeszcze raz, co oczywiście obniża pasmo i zwiększa ping, bo modem musi wysłać żądanie ponowienia transmisji, a potem cierpliwie poczekać na dostarczenie informacji, wreszcie sprawdzić ich poprawność. Z błędami FEC jest inaczej. Są one na podstawie odpowiednich sum kontrolnych korygowane na bieżąco bez retransmisji, więc odpada zapychanie pasma przez nie, ale wymagają wykorzystania dodatkowej mocy obliczeniowej modemu. O ile w przypadku większości urządzeń nie jest to większy problem (mój modem jest w stanie przetwarzać kilkadziesiąt błędów FEC na sekundę, a użycie procesora nawet mu nie drgnie), to Livebox jest urządzeniem starym, mało wydajnym i na dodatek awaryjnym. Może powstawać zjawisko zatoru, ponieważ modem nie ma wystarczająco mocy obliczeniowej, by przetwarzać na bieżąco wszystkie otrzymywane żądania. Livebox nie pokazuje ilości błędów FEC, ale prawie zawsze jest ich przynajmniej kilkadziesiąt razy więcej niż CRC. Zauważ, że występowanie wysokiego pingu już potwierdziliśmy. Ponieważ Liveboxy uwielbiają się zawieszać, to poproszę o zrestartowanie modemu. Wyłączasz go z prądu, po kilkunastu sekundach podłączasz ponownie, czekasz, aż się uruchomi. Potem wrzuć na forum screen z nowych statystyk ADSL. Chciałbym zobaczyć, na ile się zmieniają, co pomoże stwierdzić, czy prędkość synchronizacji jest stała i modem zawsze synchronizuje się na ADSL, czy też może uda się tym razem inaczej. Tak samo chciałbym zobaczyć SNR Margin zaraz po zestawieniu połączenia, żeby móc stwierdzić, czy parametr ten ulega jakimś wahaniom. Skoki w zakresie 2 - 3 dB są normalne. Większe często wskazują mało stabilną linię lub po prostu awarię.

Przy standardzie G.922.1 (ADSL G.dmt) nie ma szans działać pełne 10 Mb/s, aktualna synchronizacja na 8416 kb/s daje w rzeczywistości pasmo w okolicach 6,7 Mb/s. Przy czystym ADSL, jak tutaj, nie jesteś w stanie wyciągnąć więcej, zwłaszcza, że SNR Margin jest graniczny (6 dB) i nie pozwala na zsynchronizowanie się na więcej, co mnie zresztą przy takim tłumieniu nie dziwi. Określona teoretycznie w standardzie G.992.1 maksymalna prędkość, czyli 8 Mb/s jest w stanie działać w 100%, ale użytkownik musiałby dosłownie siedzieć z modemem na centralce. Teraz pozostają do zrobienia dwie rzeczy. 1. Próba wymuszenia na Livebox synchronizowania się na ADSL2+. Nie mam pojęcia, czy na Livebox jest to możliwe, bo te modemy są bardzo okrojone z wszelkich ustawień przez stronę konfiguracyjną. Przez telnet może i by się dało, ale Orange/TP oficjalnie żadnej konfiguracji przez telnet nie wspiera, a ja nie chcę brać odpowiedzialności za sprzęt, którego nie znam i do którego nie będę miał fizycznego dostępu, gdy coś się zepsuje. 2. Kontakt z Orange i wymuszenie konfiguracji portu na centralce do działania z ADSL2+. Wykonalne, o ile oczywiście taki port w centralce istnieje i jest wolny. Znam kilka przypadków, kiedy klienci Orange dostali port działający tylko w ADSL, co nie pozwalało na rozwinięcie prędkości wpisanej w umowie (kluczowa sprawa, to nie jest Neostrada 10 Mb/s. To jest Neostrada DO 10 Mb/s, czyli widełki 1-10 Mb/s mieszczą się w umowie). Orange sobie doskonale zdaje sprawę, że na porcie z nagim ADSL ruszy nie więcej niż 6,5 - 7 Mb/s, a mimo to takie przydziela. Czy wskutek błędu, czy świadomie, bo inne się skończyły, a konsultant podpisał umowę - nie wiem. Warto interweniować, że chcesz ADSL2+, bo inaczej pełne 10 Mb/s nie ma prawa ruszyć. Czy 10 Mb/s przy ADSL2+ ruszy to ciężko powiedzieć, bo mam same statystyki z ADSL G.992.1. Tłumienie może podskoczyć kika dB, nie będę zgadywał o ile. 27 dB nie jest jeszcze takim dużym tłumieniem, więc powinniśmy coś zyskać na wyższych częstotliwościach. Patrząc na wyniki pathping do Twojego Liveboxa, to faktycznie jest problem: 0/ 100 = 0% | 1 0ms 0/ 100 = 0% 0/ 100 = 0% mikrotik [192.168.111.1] 0/ 100 = 0% | 2 1ms 0/ 100 = 0% 0/ 100 = 0% siemens [192.168.222.1] 0/ 100 = 0% | 3 36ms 0/ 100 = 0% 0/ 100 = 0% kra-bg2.neo.tpnet.pl [83.1.4.50] 0/ 100 = 0% | 4 30ms 0/ 100 = 0% 0/ 100 = 0% kra-r2.tpnet.pl [80.50.157.233] 0/ 100 = 0% | 5 32ms 0/ 100 = 0% 0/ 100 = 0% kra-ru3.tpnet.pl [80.50.159.70] 2/ 100 = 2% | 6 149ms 2/ 100 = 2% 0/ 100 = 0% aaiz49.neoplus.adsl.tpnet.pl [83.4.233.49] Duże czasy pingów (powinno być góra 50 ms, a nie 149 ms), trochę strat pakietów.

Krótka odpowiedź, bez zagłębiania się w szczegóły kryptograficzne. WPA2-PSK (AES) przy trudnym haśle starczy. WPA-PSK (TKIP) starczy, ale nie gwarantuję własną głową. WEP nie starczy, ataki znane od dawna, istnieje popularne oprogramowanie, które umożliwia zdobywanie hasła. Robiłem już tak wiele razy, jak musiałem odzyskać hasło do sieci WiFi u znajomych.

Pokaż statystyki ADSL z Livebox, czyli takie coś: http://obrazki.elektroda.pl/9708193800_1330000265.png Livebox powinien być dostępny pod adresem http://192.168.1.1/ Przy okazji proponuję zmienić szyfrowanie na WPA zamiast WEP, ponieważ to drugie jest bardzo proste do złamania i de facto każda trochę ogarnięta w sprawach sieci osoba będąca w pobliżu może korzystać z Twojego Internetu. W linku instrukcja: http://www.orange.pl/kid,4002313715,id,4002313639,title,Livebox-11-problemy-z-WiFi-zmiana-hasla-i-szyfrowania,article.html

http://technet.microsoft.com/pl-pl/library/cc755872%28v=ws.10%29.aspx Wiem, że coś takiego istnieje. Dosyć dawno nie korzystałem. Jak będziesz miał problem, to napisz.

To masz w ogóle jakieś urządzenie, które łączy się po WiFi? Jeśli nie, no to po prostu wyłącz na routerze bezprzewodówkę i potem nie miej obaw, że ktoś korzysta z Twojego połączenia internetowego. Jeśli pamiętam, kilka postów temu pisałeś o tym, stąd cały wątek WiFi. Jak tam pingi?

Same pliki ze wszystkich katalogów i podkatalogów bez zachowania struktury katalogów, czyli tak, żeby wszystko było w jednym?

Wszystkie raporty wykonywane przy połączeniu przez HSS i to widać. Wystarczy spojrzeć, na ścieżki w tracert i pathping. Co więcej, widać kilkunastosekundową wyrwę w połączeniu w raporcie net-log zielona.txt. Teraz pytanie, czy to problem z HSS, czy z samym połączeniem od dostawcy. Po samych raportach nie jestem w stanie stwierdzić. EDIT W sumie jeszcze jedna rzecz. Można sprawdzić, czy nie zawodzi czasem połączenie z serwerem HSS. Wszystko, co idzie do Internetu od Ciebie, idzie przez ten wirtualny tunel. Ale komunikacja z serwerem idzie normalnie przez Internet. Możesz sprawdzić w tabeli routingu (polecenie route print), przez jaki serwer idzie komunikacja i odpalić pathping do niego. Tak to wygląda w net-log zielony.txt, zazwyczaj są to wpisy, które mają najwyższą metrykę: 25.0.0.0 255.0.0.0 On-link 25.74.171.22 9256 25.74.171.22 255.255.255.255 On-link 25.74.171.22 9256 25.255.255.255 255.255.255.255 On-link 25.74.171.22 9256 Właściwym poleceniem będzie pathping 25.74.171.22.

Tak, ale z komputera, który jest wyposażony w kartę WiFi, chciałeś bowiem dowiedzieć się, czy sieć jest bezpieczna, więc muszę zobaczyć jej konfigurację.

Nie wyświetla się nic, czy po prostu nie znasz hasła? Domyślny login i hasło to admin.

No ale co tu jeszcze pisać?

Rodzi się kilka wątpliwości... Skąd pod WAN jest SSID? SSID to nazwa sieci bezprzewodowej. Dlaczego na routerze pod WAN external masz wlan0? WLAN0 to Wireless LAN 0, czyli znowu sieć bezprzewodowa. Wektor ma zwrot do operatora, więc nie za bardzo rozumiem, co to tam robi. Gdybyś miał radiowe połączenie z dostawcą, to byłbym w stanie zrozumieć, ale tutaj widać, że masz ADSL po łączu telefonicznym. Dla ADSL najwłaściwszą nazwą interfejsu byłoby ppp0, bo ADSL korzysta w warstwie sieciowej z Point-to-Point Protocol, który tworzy coś w rodzaju wirtualnego tunelu między serwerem dostawcy a Twoim modemem/routerem. Przypominam, że PPP jest warstwę wyżej, niż ADSL. To ostatnie odpowiada za właściwości fizyczne (tłumienie, szumy, transmisję bitów, bez wiedzy, czym te bity są). Laptop ma dwa interfejsy: eth0 i wlan0, odpowiednio kabel i bezprzewodówka. Nie wiem, czemu masz wpisany 1. Może dlatego, że z jednego z nich nie korzystasz. Co oznaczają pytajniki?

To wygląda zdecydowanie lepiej. Synchronizacja na pełne 10 Mb/s dla downstream. Dla upstream 1192 kb/s, czyli normalna przy tej opcji i takiej odległości (1312 kb/s widziałem może 5 razy w życiu, a modem znajdował się prawie na centralce). Znikoma ilość błędów, te 1108 FEC to prawie nic. Spadł Interleave delay z 16 ms do 8 ms, czyli pingi także powinny spaść o około 10 ms. Zamiast READSL (stosowanego na słabszych i dłuższych, o wiele dłuższych łączach), uaktywniło się ADSL2+, zapewniające przy takim tłumieniu najwyższą wydajność. Wystarczający zapas na SNR Margin (11 dB), o ile parametr nie będzie się wiele chwiał. Wnioski: wczoraj obserwowaliśmy fizyczny problem z linią, ewentualnie samą centralką. Wąskie gardło nie ma tu wiele do rzeczy, problem występowałby przy połączeniu między centralką a siecią operatora, a nie do samej centralki. Wzrost liczby użytkowników może wpływać na zwiększenie zakłóceń na linii, ale według mnie nie w aż takim stopniu, chyba, że Netia korzysta z uszkodzonego kabla telefonicznego, albo masz rozparowaną linię, wtedy faktycznie przy zwiększonym użyciu sąsiednich łącz pojawiają się takie dziwy. Domyślnie nie. Można go sobie doinstalować jako funkcję Windows. Ale nie warto, PuTTY jest zdecydowanie lepszym klientem Telnet. Spróbuj jeszcze skorzystać z programu RouterStats (podobno wspiera Twojego D-Linka): http://www.vwlowen.co.uk/internet/files.htm