MikroTik debug log: Rozwiązywanie problemów z łącznością bezprzewodową

Domyślnie RouterOS w logach informuje nas o połączeniu i rozłączeniu klienta za pomocą prostych wpisów w stylu:

22:32:18 wireless,info 00:80:48:41:AF:2A@wlan1: connected

Normalnie taka informacja nam wystarcza bo wiemy że klient z mac address'em 00:80:48:41:AF:2A został połączony to interfejsu wlan1. Jeśli jednak mamy problemy z łącznością, autoryzacją itp możemy skorzystać z trybu debug który daje nam o wiele więcej informacji niż domyśle logi. Dla przykładu, ten sam klient łączy się przy włączonym trybie debug:

22:33:20 wireless,debug wlan1: 00:80:48:41:AF:2A attempts to connect
22:33:20 wireless,debug wlan1: 00:80:48:41:AF:2A not in local ACL, by default accept
22:33:20 wireless,info 00:80:48:41:AF:2A@wlan1: connected

Pierwsza linia mówi nam że ktoś próbuje się przyłączyć do naszego AP. W drugiej mamy informację o tym że AP sprawdza czy może go przyłączyć i wynik tej akcji. Ostatnia trzecia linia informuje o tym że klient został połączony. Jest to tylko jeden z przykładów informacji jakie możemy uzyskać wykorzystując tryb debug. Opis wszystkich komunikatów trybu debug znajdziecie poniżej.

Aby włączyć tryb debug wykonujemy:

[admin@MikroTik] > /system logging
[admin@MikroTik] system logging> add topics=wireless,debug action=memory

STATION MODE

[MAC]@[DEV]: lost connection, [REASON]
Stacja straciła połączenie z AP ponieważ [REASON]

[MAC]@[DEV]: failed to connect, [REASON]
Stacja próbowała połączyć sie z AP, ale połączenie nie powiodło się ponieważ [REASON]

[MAC]@[DEV]: established connection on [FREQ], SSID [SSID]
Stacja próbowała połączyć się, i próba połączenia powiodła się, z AP o SSID [SSID] na częstotliwości [FREQ]

[MAC]@[DEV]: MIC failure!!!
Sprawdzanie integralności wiadomości TKIP zakończyła się niepowodzeniem, ktoś próbuje się włamać lub wykonać DOS na sieć. Jeśli w ciągu 60 sekund otrzymamy więcej niż jedną informację MIC failure, sterownik karty przechodzi w stan "TKIP countermeasures" w którym odrzuca wszystkie przychodzące i czekające w kolejce pakiety używające TKIP.

[MAC]@[DEV]: enter TKIP countermeasures
Stacja weszła w stan "TKIP countermeasures", co oznacza że rozłączy się z AP i nie będzie się odzywać przez następne 60 sekund.

AP MODE

[DEV]: radar detected on [FREQ]
Wykryty został radar na częstotliwości [FREQ], AP podejmie prace na innym kanale.

[DEV]: data from unknown device [MAC], sent deauth [(XXX events suppressed, YYY deauths suppressed)]
Otrzymano dane od nieznanego urządzenia (tzn nie zarejestrowanego w tym AP) o mac-address'ie [MAC], AP wysłał ramkę deautoryzującą. XXX oznacza liczbę wystąpienia tego zdarzenia w celu przeciwdziałania nadmiernemu rośnięciu logów, YYY oznacza liczbę frame deautoryzujących które powinny zostać wysłane, ale nie zostały, co za tym idzie zasoby radiowe nie są marnowane na wysyłanie zbyt dużej liczby ramek deautoryzujących (maksymalnie 10 ramek na 1 sekundę).

Najczęstszym powodem pojawiania się w logach tej informacji jest sytuacja w której stacja będąca podłączona do AP, nie wie jeszcze o tym że została rozłączona, dalej wysyła dane do AP. Wiadomość deautoryzująca informuje stację że nie just już podłączona do AP.

[DEV]: denying assoc to [MAC], failed to setup compression
Inicjalizacja kompresji nie powiodła się, najczęściej z powodu zbyt dużej ilości podłączonych klientów chcących skorzystać z kompresji.

[DEV]: [MAC] is new WDS master
WDS slave ustanowił połączenie z WDS master'em, co oznacza że WDS slave zaczął akceptować klientów i pracuje jako AP.

[DEV]: [MAC] was WDS master
Wiadomość ta pojawia się w logach gdy dochodzi do rozłączenia z [MAC], co za tym idzie WDS slave deautoryzuje wszystkich klientów i zaczyna skanowanie w poszukiwaniu nowego WDS master'a.

[MAC]@[DEV]: connected [, is AP][, wants WDS]
Stacja z adresem [MAC] została połączona. Jeśli obecne jest pole "is AP" - zdalne urządzenie jest AP, w przypadku "is WDS" - zdalne urządzenie żąda zestawienia połączenia typu WDS.

[MAC]@[DEV]: disconnected, [REASON]
Połączenie ze stacją z adresem [MAC] zerwane z powodu [REASON]

[DEV]: TKIP countermeasures over, resuming
Okres milczenia w stanie "TKIP countermeasures" zakończył się, AP wraca do normalnej pracy.

[DEV]: starting TKIP countermeasures
AP wchodzi w stan "TKIP countermeasures" i przez 60 sekund będzie milczał, wszyscy klienci zostają rozłączeni.

[REASON]

"joining failed" - może przydarzyć się tylko z kratami Prism w trybie Station.

"join timeout" - występuje tylko w trybie Station, synchronizacja z AP nie powiodła się. Powodem przeważnie jest słaby sygnał, zdalny AP przestał działać, silne interferencje, inne zjawiska radiowe uniemożliwiające nawiązanie połączenia.

"no beacons" - brak ramek beacon z drugiego końca połączenia WDS. Powodem przeważnie jest słaby sygnał, silne interferencje, inne zjawiska radiowe uniemożliwiające nawiązanie połączenia.

"extensive data loss" - lokalny interfejs zadecydował aby zerwać połączenie ze zdalnym urządzeniem z powodu niemożliwo wymiany danych ze zdalnym urządzeniem mimo wielokrotnych próba nawiązania połączenia z najniższą możliwą prędkością. Powodem przeważnie jest słaby sygnał, zdalny AP przestał działać, silne interferencje, inne zjawiska radiowe uniemożliwiające nawiązanie połączenia.

"decided to deauth, [802.11 reason]" - lokalny interfejs zdecydował że zdezautoryzuje zdalne urządzenie z powodu [802.11 reason].

"inactivity" - zdalne urządzenie przez zbyt długi czas było nieaktywne.

"device disabled" - lokalny interfejs został wyłączony.

"got deauth, [802.11 reason]" - otrzymano od zdalnego urządzenia ramkę deautoryzującą z kodem powodu deautoryzacji [802.11 reason].

"got disassoc, [802.11 reason]" - otrzymano od zdalnego rządzenia ramkę deasocjującą z kodem powodu deasocjacji [802.11 reason].

"auth frame from AP" - otrzymano ramkę autoryzującą od urządzenia które było AP, przeważnie spowodowane jest to zmianą tryby pracy zdalnego urządzenia z AP na Station.

"bad ssid" - zły SSID dla połączenia WDS

"beacon from non AP" - otrzymano ramkę beacon od urządzenia które nie było AP, przeważnie z powodu zmiany trybu pracy zdalnego urządzenia z Station na AP.

"no WDS support" - urządzenie nie wspiera trybu WDS.

"failed to confirm SSID" - próba potwierdzenia SSID na drugim końcu połączenia WDS nie powiodła się.

"hardware failure" - problemy ze sprzętem lub nieoczekiwane zachowanie.

"lost connection" - może przydarzyć się tylko z kratami Prism w trybie Station.

"auth failed [802.11 status]" - występuje w trybie Station, AP nie zezwala na autoryzacją, zwracany jest kod statusu [802.11 status].

"assoc failed [802.11 status]" - występuje w trybie Station, AP nie zezwala na autoryzacją, zwracany jest kod statusu [802.11 status].

"auth timeout" - występuje w trybie Station, urządzenie w tym trybie nie otrzymało odpowiedzi na ramkę autoryzującą, powodem może być słaby sygnał lub AP z jakiegoś powodu ignoruje to urządzenie.

"assoc timeout" - występuje w trybie Station, urządzenie w tym trybie nie otrzymało odpowiedzi na ramkę asocjującą, powodem może być słaby sygnał lub AP z jakiegoś powodu ignoruje to urządzenie.

"reassociating" - występuje na AP, połączenie przypuszczalnie zostało zerwane ponieważ urządzenie uważane za połączone łączy się jeszcze raz. Wszystkie informacje dotyczące połączenia musza zostać usunięte, ponieważ podczas łączenia wszystkie parametry są negocjowane na nowo. Powodów rozłączenia należy szukać na zdalnym urządzeniu. Przeważnie jest to zerwanie połączenia z jakiegoś powodu nie informując o tym AP, na przykład zmiana w konfiguracji, utrata danych.

"compression setup failure" - połączenie niemożliwe ponieważ podłączonych jest zbyt wiele stacji, które wykorzystują kompresje.

oryginał: http://wiki.mikrotik.com/wiki/Wireless_Debug_Logs