warcraft 3 TFT + ROC, warcraft III,

Replaysowa strzałka Polskie Centrum Replayów - top
Replay Tygodnia / Best Replay
Nie ma żadnych replayów spełniających te wymogi.

Problemy z bramką: sprawdź czy masz ban na IP. Powiązanie problemów sprzętowych z logowaniem.

Artykuł porusza temat problemów z połączeniami. W większości jest dość zaawansowany. Chociaż tym razem nie da się nic popsuć, w odróżnieniu od poprzedniego artykułu, to trzeba poświęcić sporo czasu i pracy. Dla niezaawansowanych polecam końcowe wnioski i fragment o banach na IP.
 
Najpierw trochę teorii. Dane w Internecie są przesyłane przez protokół TCP/IP. Wszyscy o tym wiedzą, ale rzadko kiedy się zastanawiają, co to oznacza. Jest to zarówno siła jak i słabość tego protokołu. Nie trzeba się w to zazwyczaj wgłębiać, bo sprawnie działa. Problemy zaczynają się, gdy coś zawiedzie. Wtedy niewiele osób rozumie dokładnie, co się stało. Nie jest to jednak bardzo trudne, niemal wszystko tłumaczy model warstwowy. Polecam tutaj obrazek z wikipedii, dotyczący teoretycznego modelu OSI. Widać, że dzieli się on na warstwy – to jest bardzo ważne. Taki podział ogranicza, co może się stać w danej sytuacji, przez przypisanie jednej konkretnej roli karcie sieciowej, aplikacji czy też systemowi operacyjnemu. Z modelu OSI wywodzi się model TCP/IP. Najbardziej nas interesuje warstwa transportowa (TCP – Transmission Control Protocol). Jak widać jest umieszczona na warstwie sieciowej, w której znajduje się protokół IP. Warcraft III korzysta jeszcze z UDP, ale z tego co mi wiadomo, wyłącznie do rozgłaszania listy gier na LAN. Otrzymujemy więc model „warcraftowy” – na samym dole jest warstwa fizyczna, która nie jest interesująca (zakładamy, że w naszej sytuacji połączenia działają wszędzie, tylko nie na bramkę Battle.Net). Wyżej mamy IP, na którym z kolei są przesyłane pakiety TCP lub UDP. Po otrzymaniu pakietów przez warstwę transportową dane kierowane są do aplikacji (Warcraft III).
 
IP odpowiada za kierowanie danych pod odpowiedni adres IP (jak sama nazwa wskazuje). Jeśli masz ban na IP, to firewall Battle.netu spowoduje, że nie otrzymasz odpowiedzi na żaden pakiet w tej warstwie. W konsekwencji, nie będziesz w stanie wykryć, czy w ogóle odebrano cokolwiek po drugiej stronie, bo protokół IP nie posiada informacji zwrotnej na ten temat.
 
Jeśli pakiety IP przechodzą, i zawierają poprawne pakiety TCP wewnątrz, to zaczyna się połączenie. Wyróżnia się wiele stanów połączeń TCP, bo ta warstwa ma zapewniać poprawność transmisji. To oznacza wyeliminowanie duplikatów (czasem pakiety są wysyłane wielokrotnie, najczęściej jeśli upłynął czas na ich potwierdzenie), ustawienie odpowiedniej kolejności (pakiety mogą nadejść w dowolnej kolejności, bo w Internecie każdy pakiet może obrać inną drogę, „wyprzedzając” wcześniej wysłane), potwierdzanie odebrania danych (słynne ACK – to od TcpAckFrequency), a przede wszystkim nawiązanie i zerwanie połączenia.
 
Pierwszymi pakietami są zawsze SYN – od synchronize. Właściwie SYN to tylko flaga (znacznik) nagłówka pakietu, ale dla uproszczenia przyjmijmy, że cały pakiet zawierajacy określoną flagę ma jedną funkcję. W rzeczywistości nie jest zabronione przesłanie innych danych razem z SYN, ale raczej się tego nie spotyka. W naszym przypadku pierwsze SYN wysyła gracz, później powinien otrzymać odpowiedź SYN+ACK (potwierdzenie otrzymania poprzedniego SYN) od Battle.netu. Jeśli tego nie ma, to najprawdopodobniej mamy do czynienia z banem na IP lub problemem z własnym firewallem. Następnie gracz wysyła ACK i wtedy może nastąpić wysyłanie danych, połączenie jest w stanie ESTABLISHED (nawiązane). Jeśli połączenie dotarło do tego momentu, to na pewno nie ma bana na IP, za to jeszcze nie został sprawdzony klucz CD - o tym później. Każdy następny pakiet jest później potwierdzany ACK, a wysyłany bez żadnego oznaczenia, lub czasem z PSH i/lub ACK (dla nas to akurat nie ma znaczenia).
Brak odpowiedzi na SYN może trwać dowolny czas, zależnie od opcji rejestru. Domyślnie około pół minuty, całkiem szybko. W tym czasie komputer z którym się łączymy musi odpowiedzieć – jeśli nie odrzuci połączenia, to czekamy aż Windows sam zrezygnuje. W TCPView jest widoczne połączenie w stanie SYN_SENT (do jakiegoś hosta – zaznaczyłem na niebiesko, oprócz tego widoczne jest połączenie ESTABLISHED do Battle.Netu).

Dużo roboty jak na taką „prostą” sprawę? Niespecjalnie, bo rozłączenie ma jeszcze więcej stanów. Błąd w tym miejscu jest bardzo widoczny, objawiający się zawieszeniem na chwilę listy gier. Odpowiada to sytuacji, gdy host, do którego się połączyliśmy wstępnie zaakceptował połączenie (SYN, SYN+ACK, ACK), ale zakończył je tylko częściowo. Do zakończenia wymagane jest albo wysłanie RST (reset), albo sekwencji zamknięcia FIN+ACK, ACK z obu stron połączenia Jeśli tylko jedna strona wysłała pakiet oznaczony FIN+ACK, ACK, to połączenie nadal nadaje się do wysyłania w jedną stronę i nie będzie zakończone. Błąd programu (nie wykonanie kodu zamykającego połączenie) w tym momencie skutkuje stanem połączenia FIN_WAIT1 (nie wysłano pierwszego FIN), CLOSE_WAIT (przed pierwszym ACK), lub FIN_WAIT2 (brak ACK lub FIN potwierdzającego zamknięcie z drugiej strony – klient, czyli nasza gra, musi czekać aż upłynie określony czas, żeby spróbować zamknąć czysto połączenie) w TCPView. Są jeszcze inne przypadki, ale tylko te trwają dłużej. W tym momencie lista gier jest zawieszona, bo nie wiadomo, czy jeszcze zostaną wysłane jakieś dane, czy nie. Nie trwa to bez końca, czas FIN_WAIT jest kontrolowany przez klucz rejestru. Oczywiście nie chcemy, żeby był inny, bo to może powodować problemy z różnymi aplikacjami. W rzeczywistości może się też zdarzyć w ciągu tych dwóch minut (tyle wynosi wartość domyślna), że dane dojdą, i połączenie będzie przerwane poprawnie. Taka sytuacja raczej graczy nie interesuje, bo to oznacza ekstremalne problemy z łączem, a w konsekwencji prawie pewne lagi. Można więc odblokować zawieszoną listę wchodząc do TCPView i zamykając połączenie programu war3.exe w stanie FIN_WAIT2 – nie ma to żadnych złych skutków ubocznych. Nie zostaniecie także zabanowani, bo cały proces odbywa się w warstwie transportu. Uważajcie tylko, żeby nie zamknąć połączenia do Battle.net, bo trzeba będzie się ponownie połączyć, a za robienie tego zbyt często są bany na IP.
 
Niestety nie udało mi się uzyskać zrzutu ekranu z tej sytuacji, bo zdarza się to ekstremalnie rzadko. Połączenie musi zostać nawiązane do stanu ESTABLISHED, a później niepoprawnie zerwane, przy jednoczesnym nie przesłaniu żadnych sensownych danych, które pozwalają dołączyć do gry. Tak się dzieje praktycznie tylko gdy ktoś nas wykopie z niesamowitym refleksem, albo właśnie zamyka grę, gdy my dołączamy. Jednak czasami widać grę, która to powoduje, wiszącą na liście przez bardzo długi czas. Wydaje mi się, że jest to możliwe tylko w przypadku błędnie skonfigurowanego/zabugowanego firewalla lub źle napisanego bota (najbardziej prawdopodobny przypadek). Teoretycznie może wystąpić taka awaria sieci, że połączenie jest nawiązane i wszystko jest poprawnie, oprócz ostatniego FIN, ale szanse są niewielkie. Najgorsze tutaj jest to, że wpadnięcie w FIN_WAIT2 w przypadku gdy nasz serwer już nie odpowie kończy się wyjątkowo długim oczekiwaniem - ponad kilka minut. Jak wcześniej, w zależności od kilku opcji rejestru. Na szczęście taka sytuacja jest możliwa tylko w liście gier. Gdy już jesteśmy „w środku”, to rozłączenie następuje w tle. Czemu nie jest tak na samej liście? Powód jest prosty – program nie jest w stanie określić dopóki nie zakończy się to połączenie, czy skończyliśmy dołączać do gry. W przypadku zwykłej rozgrywki otrzymywane są wcześniej pakiety, które jednoznacznie określają, że już zakończyliśmy i rozłączenie może być poza naszą kontrolą. Bardzo często tak jest, że połączenia wiszą po kilka minut z poprzednich gier, mimo, że dawno już jesteśmy w nowej – możecie to sobie sami sprawdzić.
 
Teraz trochę praktyki. Wykorzystam TCPView, jak w poprzednim artykule, oraz analizator ruchu sieciowego WireShark. Korzysta on z WinPCap, opartego o sterownik NDIS. W skrócie to oznacza, że jest w stanie złapać pakiety powyżej warstwy sprzętowej. Taki Process Monitor dla sieci. Nie jest to dla nas zbyt korzystne, bo interesujący jest jedynie ruch TCP i do tego dotyczący jednego programu. Na szczęście jest możliwość skorzystania z bogatej kolekcji filtrów, które pozwolą usunąć „szum” sieci. A jest tego naprawdę niesamowita ilość – wirusy, zapytania komputerów pochodzących z sieci Microsoft Network, pakiety ARP (głównie określające kto ma jaki adres IP na sieci LAN), i wiele innych rzeczy. W szczególności ciekawe jest, że korzystając z programu P2P, będziemy otrzymywać wiele pakietów dużo po wyłączeniu naszego programu (zazwyczaj nie jest to wielkie obciążenie), nawet do kilku godzin. Omówię teraz dokładnie, jak wykonać taki filtrowanie i na co się wtedy można natknąć.
 
Po pierwsze wchodzimy do menu Capture/Options:

Tutaj należy wybrać adapter, czyli kartę sieciową. Używa się nazwy adapter, bo nie zawsze mamy tu do czynienia z fizycznym urządzeniem. Przykładem jestw irtualny „adapter for generic dialup and VPN capture”, występujący w standardowej instalacji Windows XP. Wybieram swoją kartę sieciową i wciskam przycisk start po prawej na dole.

Po wybraniu z menu opcji Capture/Stop mamy pierwszy zrzut pakietów. Jak wcześniej wspominałem, występuje kompletny chaos. Pakiety ARP stanowią większość, gdy sieć jest „bezczynna”. O ile kogoś może interesować jak wybierany jest komputer z LAN (na obrazku pakiety BROWSER), który przechowuje listę maszyn obsługujących Microsoft Network (potocznie nazywane jest to otoczeniem sieciowym, bo przez tak nazwaną ikonę wchodziło się kiedyś do tej listy), to również tej informacji nie potrzebujemy. Właściwie cała informacja poniżej TCP nie jest dla nas ciekawa – trzeba założyć odpowiedni filtr (zaznaczyłem kolorem niebieskim na zrzucie ekranu).

Jeśli odczekaliśmy długo od uruchomienia ostatnich programów sieciowych, nie ma nic aktywnego w tle i jest założony filtr tcp, to można przystąpić do podsłuchiwania pakietów należących do gry. Jeśli jesteś w LANie, gdzie są luźno skonfigurowane switche lub archaiczne dzisiaj huby, to może się jeszcze przydać odznaczenie opcji „capture packets in promiscuous mode”, żeby nie otrzymywać pakietów nieskierowanych do twojego komputera (zadziwiające, ale często coś w ten sposób leci – to akurat temat na inną okazję, napiszę tylko, że w takiej sieci bardzo łatwo stracić hasło do poczty, „prawie jak w bezprzewodowej”).

Nie wiadomo po co mój komputer otrzymuje pakiety od kogoś innego z sieci lokalnej. Widać, że ktoś otwiera przeglądarkę, albo inny program przesyłający dane po http (WireShark posiada możliwość interpretacji i składania ogromnej ilości różnych protokołów, więc mógłbym sobie to podejrzeć, gdyby mnie to interesowało). Wyżej widać typową sytuację odmowy połączenia – z jakiegoś nieznanego mi bliżej komputera nadchodzą pakiety oznaczone SYN. Ponieważ nie mam uruchomionego nasłuchiwania na porcie, do którego przyszło zapytanie, Windows odsyła RST+ACK, czyli reset połączenia - aktywna odmowa. Oczywiście można nie odpowiadać w ogóle, ale domyślnie zakłada się, że jeśli jakaś usługa (otwarty port) jest niedostępna, to łączący się komputer powinien być natychmiast poinformowany. Firewalle często to blokują, obniżając obciążenie łącza w przypadku ataku (SYN flood). Jest to typowe zachowanie dużych serwerów, którym bardziej się opłaca nie odpowiadać, niż wysyłać reset. Wrócę do tego później na przykładzie Battle.netu, a teraz kilka przykładów typowych sytuacji „sukcesu” połączenia.
 
Trzykrotny uścisk dłoni (three-way handshake), czyli to, co następuje na starcie każdego połączenia TCP (SYN, SYN+ACK,  ACK).

Zaznaczyłem też pierwszy pakiet danych na niebiesko. Na dole widać całą zawartość pakietu, głównie nagłówki, adresy ip (zaczernione), sumy kontrolne. Na niebiesko jest zaznaczony fragment, który jest rzeczywistymi danymi – 01. To jest pierwszy przesłany bajt przez grę do Battle.netu, określa protokół, jaki będzie później zastosowany (obecnie jest tylko 01 – protokół sesji chat, autoryzacji gry, lub 02 – protokół przesyłania plików). Jak widać bardzo dużo miejsca „na drucie” zajmują informacje samych protokołów. Przesłanie jednego bajtu wymaga kilkadziesiąt bajtów informacji, tzw. narzutu (overhead). Warto się nad tym zastanowić, przed uruchomieniem opcji TcpAskFrequency, która powoduje powstanie oddzielnego pakietu dla odesłania samego ACK (który nie zawiera wtedy danych, oznaczenie pakietu jako ACK jest w nagłówku).
 
Sekwencja zakończenia połączenia przez obopólną zgodę klienta i serwera (FIN+ACK, ACK, FIN+ACK, ACK).

Zaznaczyłem na czarno cztery ostatnie pakiety tego połączenia TCP – reszta należy do innego (inny port). Łącząc się z Battle.netem niemal zawsze przeplatają się dwa połączenia – jedno to zwykłe logowanie, a drugie to ściągany banner. Można podejrzeć co jest co, oglądając fragmenty danych w pakietach. Tutaj ostatni pakiet z danymi zawiera tekst, który pokazuje się przed wejściem na czat (zaznaczone na niebiesko na dole i niebieskim paskiem na liście pakietów). Żeby pozbyć się problemu, można ustawić szybko filtr na pojedyncze połączenie. Wystarczy wybrać z menu kontekstowego „Follow TCP stream” i będziemy mieli nie tylko wyłącznie dane dotyczące połączenia, do którego należy wybrany pakiet, ale również opcję pokazania ich w bardziej czytelnej, tekstowej formie.

Najbardziej przydatna jest opcja obejrzenia samych danych jako wartości szesnastkowe i tekst jednocześnie. Jeśli wycofamy się z oglądania, to w polu tekstowym „filter” będzie odpowiedni filtr, ograniczający widok do pojedynczego połączenia (na obrazku - na zielonym tle).
 
Wszystko fajnie, ale pewnie się zastanawiacie, po co tyle roboty? Po co komuś ta wiedza? Oczywiście nie napisałem tego na darmo. Teraz możecie sobie sprawdzić, w którym momencie połączenie jest odrzucane przez serwer, a nawet czy cdkey jest poprawnie przetwarzany.
 
Zacznę od prostego przypadku – ban na IP. Jeśli rzeczywiście jesteśmy blokowani na poziomie IP, to nie będzie żadnej odpowiedzi na wysyłany przez grę pakiet SYN. Co więcej, można w łatwy sposób sprawdzić to nawet bez analizy pakietów. Istnieje możliwość połączenia się przez obecny w Windows program telnet, z pominięciem procedury sprawdzania cdkeya. Należy wejść do menu start/uruchom, wpisać cmd i wcisnąć enter. Pojawia się „dosowe” okienko, gdzie możemy użyć komendy: telnet europe.battle.net 6112
Koniecznie ten port, brak tej liczby na końcu spowoduje próbę połączenia na port 23, który nic nie odpowie. Pojawi się migoczący kursor, należy wtedy wcisnąć raz klawisz „c” (nie trzeba powtarzać, jeśli nie wszedł za pierwszym razem). Wtedy pokazuje się okienko:

Gdzie oczywiście adres IP będzie wypełniony twoim adresem zewnętrznym. Po wypisaniu tej informacji serwer natychmiast przerwie połączenie, co zresztą jest napisane. Wciśnięcie dowolnego klawisza wróci nas do linii komend. Uzyskanie takiego wyniku oznacza, że nie ma bana na IP. Kompletny podgląd tego połączenia w WireSharku jest bardzo krótki. Telnet nie zawiera żadnych nagłówków, a przesłany tekst jest widoczny jak na dłoni.

Sekwencja połączenia, pakiet o długości danych 1 (Len = 1 na obrazku), czyli „c”, 67 bajtów odpowiedzi serwera (na obrazku zaznaczony niebieskim kolorem pakiet na liście i na dole jego zawartość), oraz zerwanie połączenia (cztery ostatnie pakiety na liście). Pierwsze FIN+ACK wysłał serwer, czyli zostaliśmy rozłączeni zdalnie.
 
A tak wygląda porażka, ban na IP (w tym przypadku skorzystałem z faktu, że połączenie na standardowy port 23 nie daje odpowiedzi):

Dwie ciekawe rzeczy rzucają się w oczy. IP serwera Battle.net nie jest stałe, lecz należy do dużej grupy. Po każdym połączeniu otrzymujemy nowy IP z tej samej nazwy DNS (europe.battle.net). To jest bardzo często stosowany trik, pozwalający rozłożyć obciążenie na wiele maszyn. Druga sprawa, to ogromna liczba pakietów SYN i ich czasy wysłania. Zanim Windows porzuci próbę połączenia, wysyła domyślnie (sterowane jak zawsze opcją rejestru) trzykrotnie SYN, w regularnych odstępach czasu (drugi SYN po prawie trzech sekundach, trzeci po pięciu). W tym momencie program otrzymuje informację o porażce połączenia i albo użytkownik dostanie informację o tym, albo jak w tym przypadku (telnet), nastąpi ponowna próba. Dlatego adresy IP zmieniają się co trzy pakiety SYN, bo ponowne rozwikłanie nazwy europe.battle.net następuje dopiero pod kontrolą aplikacji (programy nie kontrolują liczby SYN wysyłanych przez system operacyjny). Nie należy się dziwić, jeśli podobnie będzie wyglądać próba połączenia przez Warcraft III.
 
Nawet laik może użyć telnetu, więc problem sprawdzenia bana na IP jest rozwiązany jak wyżej. Jednak niektórzy nadal nie mogą się połączyć! Tutaj ogromną rolę odgrywają problemy sprzętowe. Wydaje się to przeciwne intuicji, ale tylko pozornie. Początkowa faza, w której zestawione jest połączenie, rzeczywiście jest praktycznie niezależna, ale to nie wystarcza, żeby się poprawnie zalogować. Co gorsza, przed zalogowaniem następuje autoryzacja, czyli sprawdzenie plików gry, cdkeya (oraz w pewnym sensie oryginalności) a nawet zawartości fragmentów pamięci. Jeśli przeczytaliście mój artykuł o Wardence, to już wiecie po co takie zabezpieczenia. Boty obciążają nadmiernie serwer, zużywając jego bardzo ograniczone zasoby. Zaczerpnę trochę wiedzy z BNetDocs:

Sekwencja logowania, określająca kolejne otrzymywane i wysyłane pakiety. Wszystkie zaczynają się od wartości szesnastkowej 0xFF, a później specyficznych nagłówków, o których zawartości można poczytać na BNetDocs. U mnie zdarza się jeszcze jeden pakiet w tej sekwencji, ale również jest opisany i nie ma wielkiego znaczenia. Małe niezgodności są możliwe, bo strona nie jest aktualizowana tak często jak Battle.Net. Jak widać, najbardziej prawdopodobna jest porażka w momencie przesyłania pakietu 0x51, który zawiera wynik autoryzacji. Niestety nie istnieje dużo łatwiejsza metoda, niż przeglądanie przesłanych do Battle.Netu pakietów, żeby to sprawdzić. Zdaję sobie sprawę, że większość tych, którzy mają z tym problem, takie coś przerasta. Dlatego polecam prewencyjnie testować pamięć, procesor i dysk. Wystarczy raz przez kilka godzin, na całe „życie” komputera. Zapewniam, że większość błędów manifestuje się bardzo szybko w programach podanych przeze mnie w poprzednim artykule.
 
Nawet podglądając pakiet 0x51 trudno stwierdzić, czy jego zawartość jest poprawna, ze względu na metodę jego generowania, która powoduje, że jest prawie za każdym razem nieco inny. Mogę tylko spróbować was przekonać, że jest to możliwe, przez przytoczenie kolejnego źródła wiedzy na temat Battle.Netu – artykuł na stronie uninformed, a konkretnie jego fragment, określający dokładnie, co jest sprawdzane. Dwie rzeczy są objęte sumą kontrolną: fragmenty plików gry, załadowane w pamięci, oraz sam moduł sprawdzający. To powoduje, że przy uszkodzonej pamięci RAM, można się czasem zalogować, a czasem nie. Typowe uszkodzenie, przestawienie pojedynczego bitu przy odczycie, jest niezauważalne w większości przypadków. Cała gra może działać niemal bez problemu. Czasem obserwuje się dziwne zachowanie, ale rzadko. Suma kontrolna za to jest bardzo wrażliwa na takie sytuacje – bardziej niż zwykły kod, bo właśnie do wykrywania takich rzeczy została zaprojektowana.

Pozornie może wyglądać to na problem z patchem. Jest to konsekwencja tego, że program nie kontroluje dokładnie, gdzie zostanie załadowany w fizycznym RAMie. Losowość jest bardzo mała, ale możliwa. Gdy gra jest spatchowana, zmienia się „miejsce” w pamięci, które jest sprawdzane. Suma kontrolna nie wykrywa każdego błędu (wyjaśnienie tego jest np. w moim artykule o Wardence), więc nie jest wykluczone, że logowanie jednak się powiedzie. Jest to jednak logiczne wytłumaczenie, dlaczego powiązanie błędu logowania z patchem jest mniej prawdopodobne, niż powiązanie go z uszkodzeniem pamięci. Dodajmy do tego, że logowanie się na inne bramki umieszcza dane w nieco innych miejscach pamięci i prosta droga do teorii spiskowej – u mnie wszystko jest w porządku – gotowa.
 
Częsta jest też sytuacja, że pierwsze połączenie się udaje mimo wszystko. Być może (nie jestem tego w stanie sprawdzić) jest to rozwiązanie podobne do dawnego zachowania zabezpieczenia antypirackiego (zanim w ogóle się go Blizzard pozbył). Pierwsze uruchomienie było dozwolone bez dobrej płyty – dzięki temu w razie problemów z zabezpieczeniem można ściągnąć patch (był taki przypadek, problem z napędami firmy Samsung). Podobnie nie ma sensu blokować pierwszego po instalacji dostępu do Battle.Netu – wystarczy, że cdkey jest poprawny, pamięć już nie musi.
 
Czy wirusy mogą spowodować podobny efekt? Według mnie tak. Nie tylko ładując dodatkowy kod mogą przemieścić rzeczy w region uszkodzonej pamięci, ale również mogą same uszkodzić kod gry. Z natury wirusy nie są w stu procentach kompatybilne. Używanie w nich trików mających za zadanie ominąć detekcję jest powszechne. Spora część z nich działa niestabilnie, a ponieważ szkodliwy kod jest potencjalnie ładowany do każdego procesu (w tym gier), to istnieje możliwość przeniesienia bugów do wnętrza konkretnego programu. W konsekwencji wirusy rzeczywiście mogą spowodować, że nie uda się zalogować przez błąd autoryzacji.
 
Wnioski:
  1. Główną przyczyną problemów z połączeniami jest samo łącze – tak wiem, bardzo odkrywcze.
  2. Problem braku połączenia z konkretną bramką, jeśli nie jest banem na IP, wynika najprawdopodobniej z uszkodzonej pamięci/dysku lub konfliktu z inwazyjnym oprogramowaniem (antywirus, wirus). W przypadku takich problemów odsyłam do poprzednich artykułów.
  3. IP ban jest nieodróżnialny od problemów z połączeniem wynikających z awarii łącza/serwera Battle.net lub źle skonfigurowanego firewalla.
  4. „Wieszanie się” listy gier na dwie minuty nie jest błędem gry. Można się przyczepić, że nie ma przycisku „anuluj”, który przerywałby operację połączenia – to jest możliwe do wykonania. Naruszenie standardu najbardziej uciążliwej, bo najdłuższej, sekwencji zamykania połączenia mogłoby jednak odbić się na kompatybilności.

Zamieścił: pyton, dnia: 18:29:16, Friday 15. August 2008

Komentarze:

[19:25:34, Friday 15. August 2008] , Zgłoś do moderacji

[19:30:19, Friday 15. August 2008] , Zgłoś do moderacji

[22:56:37, Saturday 16. August 2008] , Zgłoś do moderacji
wow naprawde n1 . :) GJ

4: KlimO, Newsman&tourmaker&admin
[14:06:44, Sunday 17. August 2008] , Zgłoś do moderacji
Ostatnio siedzac na BN, nagle niemoglem nic zrobic (sprawdzalem profile i nic, zmieniac kanalow tez nie moglem, wygladalo to jak jakis lag, jednak net chodzil spokojnie) gdy sie polaczam z botem wyskakuje mi cos takiego [14:01:05] All connections closed.
[14:01:27] [BNLS] Error 10060: The attempt to connect timed out
[14:01:27] [BNLS] The server took too long to respond to your computer. The BNLS server appears to be unreachable at this time. Please check back in an hour or two, or configure local hashing. (For more information
ktory z arty moze pomoc?:< Mam radiowke i IP na ktorym hostowac nie moge (nie pamietam czy to sie nazywa wew, czy zew.,) Tak samo mam czasami po grach, np. wygrywam wylaczam statystyki po grze wracam na czat a tam bum polaczenie zostalo przerwane mimo ze int dalej dziala, i przez jakies 5min nie moge sie polaczyc z Europe Bramka, ktos mowil zeby odblokowac porty ale ja sie na tym za bd nie znam i szukam pomocy.

5: pyton, Support
[15:02:25, Sunday 17. August 2008] , Zgłoś do moderacji

[16:06:17, Thursday 21. August 2008] , Zgłoś do moderacji
dokladnie, artykul swietny jak zawsze, jednak mam dziwne wrazenie ze topici w stylu "nie moge sie zalogowac na northrend" itp i tak czesto beda sie pojawiac;p

[04:45:08, Sunday 30. November 2008] , Zgłoś do moderacji
Yhym a ja i tak dalej nie wiem co mam zrobic zebym mogl wejsc na "northrend":/...

Więcej?

Chcesz znaleźć informacje na konkretny temat? Przejrzyj hasła, których najczęściej dotyczą dodane ostatnio nowości! WC3L, TURNIEJ, WCG, NETWARS, LCW, WORLD CYBER GAMES, TERROR, DOTA, GRUBBY, MYM, PALADYN, WYWIAD, REPPACK, WARCRAFT, BLIZZARD, MOON, PORADNIK, POL-TEAM, BIOT, POLSKA, ESL, KONKURS, LIGA, WORLD ELITE, FUZJA, NGL-ONE, ENC, NGL, TOD, TDEL, SPQR, SLH, MOUZ, PGS, TOUR, GFO, WILQ, BRONZE, KODE5, WILDA, PATCH, TEAM FIGHTING, LADDER, REPREZENTACJA, SILVER, HEADSHOT, EXTREME MASTERS, HEYAH, FLY100%, VOODOO, LYN, KUJA, BIOHAZARD-TEAM, BVG, WICKED, ESWC, ALMOST, TH000, ACIS, KWAKI, CYKLOP, SHOW, KLIMO, REPLAYPACK, INCUP, CLAN BASE, HOORAI, SASE, ELIMINACJE, FINAłY, FNATIC, POLTEAM, SHOWMATCH, WCG 2006, IEST, SRS, FINAł, CYBERSPORT, WE.EU, PLD, SKY, PRAE, REMIND, JAGR, CASIN, LAN, REPLAYS.PL, CHALLENGE, ANIMATOR, 2007, BATTLENET, CARMAC, HAPPY, NATIONS, STARCRAFT, PEDAL, KONKURSIWO, W3ARENA

Copyright © Wszelkie prawa zastrzeżone,
kopiowanie tylko za zgodą właściciela.
2003/2007 by: CyklOP, Muzami, Julas [ Mapa Strony ]
Replayów w bazie: 19538 Kont użytkowników: 11428

Pomysł, oskryptowanie, administracja: CyklOP [jak kupić zagraniczne akcje] [Jak wypełnić W-8BEN] [Jak tanio wymienić walutę] [deutschtests]
Design: Muzami, art w topie strony nadesłał Z4buZa
Skrypt obsługujacy replaye: Juliusz 'Julas' Gonera [ Replay Parser ]
Wykonano w czasie 0.3929009437561 sekund