Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
eko.one.pl → Oprogramowanie / Software → Ograniczenia w Aero2
Strony Poprzednia 1 2
Zaloguj się lub zarejestruj by napisać odpowiedź
Ja mam Aero2 w routerze mobilnym więc w moim przypadku to samo co u tych co mają wpięte w Gargulca, tyle, że ja okazjonalnie używam. Dla mnie w sumie to nie będzie duży problem, ale dla tych co do tej pory korzystali z Aero2 jako głównego łącza na routerze albo jako backupowego to będzie problem.
Tu coś więcej jdtech.pl
No cóż - link podałeś ten sam co ja.
Pozostaje wiara, że to prima aprilis
No cóż - link podałeś ten sam co ja.
Pozostaje wiara, że to prima aprilis
Jak powiedzieli, tak zrobili:
I co najlepsze... próbowałem 4 razy, raz nie zgadzał się kod, a pozostałe 3 próby skończyły się brakiem połączenia z tą ich stroną przechwytującą. D...a.
To trochę lipa, ale niestety trzeba się będzie przyzwyczaić. Swoją drogą może będzie lepiej działać bo ostatnimi czasy było chyba ostro zatkane przez co niektórych.
Swoją drogą może będzie lepiej działać bo ostatnimi czasy było chyba ostro zatkane przez co niektórych.
Przecież to nic, zupełnie nic nie zmieni. Będzie działać tak samo jak działało do tej pory, tyle że będzie trzeba dodatkowo rozszyfrowywać dla Googla nieczytelne skany.
Właśnie testuję. Trzeba wpisać kod. Potem się rozłączyć modemem, połączyć na nowo i hula.
Router (chyba) blokuje odwołanie do strony z kapciem
possible DNS-rebind attack detected: bdi.free.aero2.net.pli ta strona nie wczytuje się, a nie bardzo mogę sobie poradzić z firewallem. Jaką regułkę trzeba wpisać i gdzie? A tak poza tym, po wpisaniu poprawnie kapcia trzeba zerwać połączenie i połączyć się ponownie.
simono napisał/a:Swoją drogą może będzie lepiej działać bo ostatnimi czasy było chyba ostro zatkane przez co niektórych.
Przecież to nic, zupełnie nic nie zmieni. Będzie działać tak samo jak działało do tej pory, tyle że będzie trzeba dodatkowo rozszyfrowywać dla Googla nieczytelne skany.
Przejściowo tak-u mnie to już widać, takie pingi na BDI to były do tej pory po godzinie 0.00
64 bytes from 8.8.8.8: icmp_seq=0 ttl=48 time=90.708 ms
64 bytes from 8.8.8.8: icmp_seq=1 ttl=48 time=69.713 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=48 time=68.700 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=48 time=68.042 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=48 time=66.928 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=48 time=78.859 ms
64 bytes from 8.8.8.8: icmp_seq=6 ttl=48 time=75.389 ms
64 bytes from 8.8.8.8: icmp_seq=7 ttl=48 time=74.010 ms
64 bytes from 8.8.8.8: icmp_seq=8 ttl=48 time=123.195 ms
64 bytes from 8.8.8.8: icmp_seq=9 ttl=48 time=72.266 ms
64 bytes from 8.8.8.8: icmp_seq=10 ttl=48 time=90.545 ms
64 bytes from 8.8.8.8: icmp_seq=11 ttl=48 time=69.730 ms
64 bytes from 8.8.8.8: icmp_seq=12 ttl=48 time=78.426 ms
64 bytes from 8.8.8.8: icmp_seq=13 ttl=48 time=78.114 ms
64 bytes from 8.8.8.8: icmp_seq=14 ttl=48 time=67.581 ms
64 bytes from 8.8.8.8: icmp_seq=15 ttl=48 time=85.555 ms
64 bytes from 8.8.8.8: icmp_seq=16 ttl=48 time=74.437 ms
64 bytes from 8.8.8.8: icmp_seq=17 ttl=48 time=73.372 ms
64 bytes from 8.8.8.8: icmp_seq=18 ttl=48 time=132.127 ms
64 bytes from 8.8.8.8: icmp_seq=19 ttl=48 time=81.098 ms
64 bytes from 8.8.8.8: icmp_seq=20 ttl=48 time=80.391 ms
64 bytes from 8.8.8.8: icmp_seq=21 ttl=48 time=79.592 ms
64 bytes from 8.8.8.8: icmp_seq=22 ttl=48 time=78.204 ms
64 bytes from 8.8.8.8: icmp_seq=23 ttl=48 time=77.093 ms
64 bytes from 8.8.8.8: icmp_seq=24 ttl=48 time=76.030 ms
64 bytes from 8.8.8.8: icmp_seq=25 ttl=48 time=74.885 ms
64 bytes from 8.8.8.8: icmp_seq=26 ttl=48 time=73.696 ms
64 bytes from 8.8.8.8: icmp_seq=27 ttl=48 time=92.564 ms
64 bytes from 8.8.8.8: icmp_seq=28 ttl=48 time=71.619 ms
64 bytes from 8.8.8.8: icmp_seq=29 ttl=48 time=100.474 ms
64 bytes from 8.8.8.8: icmp_seq=30 ttl=48 time=99.609 ms
64 bytes from 8.8.8.8: icmp_seq=31 ttl=48 time=109.238 ms
64 bytes from 8.8.8.8: icmp_seq=32 ttl=48 time=108.059 ms
64 bytes from 8.8.8.8: icmp_seq=33 ttl=48 time=76.777 ms
64 bytes from 8.8.8.8: icmp_seq=34 ttl=48 time=75.591 ms
64 bytes from 8.8.8.8: icmp_seq=35 ttl=48 time=84.259 ms
64 bytes from 8.8.8.8: icmp_seq=36 ttl=48 time=183.360 ms
64 bytes from 8.8.8.8: icmp_seq=37 ttl=48 time=81.947 ms
64 bytes from 8.8.8.8: icmp_seq=38 ttl=48 time=150.931 ms
64 bytes from 8.8.8.8: icmp_seq=39 ttl=48 time=89.690 ms
64 bytes from 8.8.8.8: icmp_seq=40 ttl=48 time=68.823 ms
64 bytes from 8.8.8.8: icmp_seq=41 ttl=48 time=78.263 ms
64 bytes from 8.8.8.8: icmp_seq=42 ttl=48 time=77.941 ms
Request timeout for icmp_seq 43
64 bytes from 8.8.8.8: icmp_seq=44 ttl=48 time=116.071 ms
64 bytes from 8.8.8.8: icmp_seq=45 ttl=48 time=75.932 ms
64 bytes from 8.8.8.8: icmp_seq=46 ttl=48 time=75.699 ms
64 bytes from 8.8.8.8: icmp_seq=47 ttl=48 time=74.479 ms
64 bytes from 8.8.8.8: icmp_seq=48 ttl=48 time=83.353 ms
64 bytes from 8.8.8.8: icmp_seq=49 ttl=48 time=82.262 ms, tj. raczej półśrodek-w dużych miastach niezbędne jest uruchomienie BDI na 2600MHz (tak prawdę mówiąc nie specjalnie jestem rozczarowany, gdyż w ciągu ok. roku jakość tego internetu tak "zeszła na psy" że nadaje się tylko do otwierania www, uruchamiania aplikacji pobierających dane na smartfonach, nie działają prawidłowo wszelkiego rodzaju komunikatory life audio-video).
Mam to samo: router gargoyle z aero2 blokuje dostęp do bdi.free.aero2.net.pl:8080 i nie można wyświetlić captchy. W smartfonie obok działa aero2 bez problemu i captcha pokazuje.
Jakie jest rozwiązanie, jak wyłaczyć w gargoyle blokadę zapytania na DNS?
Już podałem wątek obok...
Mam to samo: router gargoyle z aero2 blokuje dostęp do bdi.free.aero2.net.pl:8080 i nie można wyświetlić captchy.
Nie jestem przekonany do tego że router blokuje dostęp do tej strony (raczej zabezpieczenia przeglądarek). Otóż po 17-tej podłączyłem modem do MBP, nawiązałem połączenie i wpisałem to uwierzytelnianie (chwyciło za 1-razem), odpiąłem modem i podłączyłem do skonfigurowanego WR703N-nawiązał połączenie, które utrzymuje już 3godz. , bez ponownych autoryzacji. Co ciekawe przed chwilą jako swoiste pogotowie, miałem okazje aktualizować AirRouter z E353BDI (po 10 miesiącach pracy) i captcha się ukazała po nawiązaniu połączenia przez modem, zrobiłem restart poprzez odpięcie zasilania od routera i połączenie zostało nawiązane (teraz się zastanawiam czy pamięć przeglądarki w kompie nie pomogła przy tym lub że mój modem jest do bani-niby nowy był kupowany ale z aukcji, a E353 ze sklepu Play). 
Przed chwilą minęła kolejna godzina i połączenie ponownie zostało nawiązane bez autoryzacji.
Router blokuje. W wątku obok opisałem co i jak. OpenWRT domyślnie blokuje odpowiedzi DNS z puli adresów nieroutowalnych.
Póki co testowo captcha jest raz na dobę. Captcha jest aktywana dla karty z danym IMSI.
Router blokuje. W wątku obok opisałem co i jak. OpenWRT domyślnie blokuje odpowiedzi DNS z puli adresów nieroutowalnych.
To wytłumacz mi jakim cudem ok. 45min. temu, przy nawiązanym połączeniu BDI E353/AirRouter/najnowsze Gargoyle ukazała mi się strona z autoryzacją, wpisałem poprawnie kod i za 1-razem został przyjęty?
Wytłumacz mi dlaczego dziś koło 17 raz zdarzyła mi się identyczna sytuacja? Po prostu rebind protection nie zadziałał - przypadek.
Albo chłopcy z Aero2 coś jeszcze mieszają w sensie naprawiają to co spaprali.
Jednak jest zauważalna poprawa działania sieci Aero2-co wskazuje że co niektórzy doili tą sieć na maxa jako główne łącze. Nie jest to wygodne rozwiązanie, lecz trzeba się z tym pogodzić że takie utrudnienie będzie w dostępie darmowym, co prawda mam bardzo duże zastrzeżenia co do szczegółów autoryzacji (do odczytania niektórych kodów trzeba "wystawić oczy na wierzch"-w tej kwestii powinien interweniować UKE, bo niczemu nie przeszkadza aby był to normalny czytelny tekst). Rozwój tej usługi w dużych miastach nie spełni oczekiwań użytkowników bez uruchomienia pasma 2600MHz.
64 bytes from 8.8.8.8: icmp_seq=23342 ttl=48 time=67.993 ms
64 bytes from 8.8.8.8: icmp_seq=23343 ttl=48 time=67.853 ms
64 bytes from 8.8.8.8: icmp_seq=23344 ttl=48 time=76.919 ms
64 bytes from 8.8.8.8: icmp_seq=23345 ttl=48 time=65.796 ms
64 bytes from 8.8.8.8: icmp_seq=23346 ttl=48 time=174.165 ms
64 bytes from 8.8.8.8: icmp_seq=23347 ttl=48 time=73.384 ms
64 bytes from 8.8.8.8: icmp_seq=23348 ttl=48 time=102.122 ms
64 bytes from 8.8.8.8: icmp_seq=23349 ttl=48 time=92.369 ms
64 bytes from 8.8.8.8: icmp_seq=23350 ttl=48 time=70.547 ms
64 bytes from 8.8.8.8: icmp_seq=23351 ttl=48 time=68.819 ms
64 bytes from 8.8.8.8: icmp_seq=23352 ttl=48 time=68.591 ms
64 bytes from 8.8.8.8: icmp_seq=23353 ttl=48 time=67.412 ms
64 bytes from 8.8.8.8: icmp_seq=23354 ttl=48 time=76.949 ms
64 bytes from 8.8.8.8: icmp_seq=23355 ttl=48 time=76.063 ms
64 bytes from 8.8.8.8: icmp_seq=23356 ttl=48 time=64.941 ms
64 bytes from 8.8.8.8: icmp_seq=23357 ttl=48 time=64.581 ms
64 bytes from 8.8.8.8: icmp_seq=23358 ttl=48 time=83.788 ms
64 bytes from 8.8.8.8: icmp_seq=23359 ttl=48 time=82.867 ms
64 bytes from 8.8.8.8: icmp_seq=23360 ttl=48 time=91.950 ms
64 bytes from 8.8.8.8: icmp_seq=23361 ttl=48 time=80.983 ms
64 bytes from 8.8.8.8: icmp_seq=23362 ttl=48 time=90.831 ms
64 bytes from 8.8.8.8: icmp_seq=23363 ttl=48 time=73.444 ms
64 bytes from 8.8.8.8: icmp_seq=23364 ttl=48 time=77.908 ms
64 bytes from 8.8.8.8: icmp_seq=23365 ttl=48 time=77.100 ms
64 bytes from 8.8.8.8: icmp_seq=23366 ttl=48 time=66.006 ms
64 bytes from 8.8.8.8: icmp_seq=23367 ttl=48 time=65.269 ms-przed 1 kwietnia takie czasy odpowiedzi to były w środku nocy, z drugiej strony uruchomienie pasma 2600MHz wykosiło by kiepskich ISP.
Strony Poprzednia 1 2
Zaloguj się lub zarejestruj by napisać odpowiedź
eko.one.pl → Oprogramowanie / Software → Ograniczenia w Aero2
Forum oparte o PunBB, wspierane przez Informer Technologies, Inc