mikrotik Wireless Debug Logs

Debugging wireless problems using Logs.

By default RouterOS wireless log shows that client connects and disconnects as simple entries:

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

It is enough for regular users to know that the wireless client with MAC address «00:80:48:41:AF:2A» is connected to wireless interface «wlan1». But actually there are more log entries available than are shown in standard logging. They are called ‘debug’ logs which give more detailed information. In the following Debug Log example you will see the same client connecting to the AP in more detail than found in typical logging:

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

Debug Logs will give you more specific informantion on each step of the Client wireless connection and disconnection. The first line shows that the wireless client tried to connect to the AP. On the second line the AP checked to see if that client is allowed to connect to the AP and the resulting action. And only on the third line do you see that the client is connected. This is merely one example of the debug log messages. The description of all debug entries is written below.

To enable the wireless debug logs you should execute such commands:

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

Or in Winbox: 
This will help you understand and fix wireless problems with ease and with less interaction with the support team.

STATION MODE 

<MAC>@<DEV>: lost connection, <REASON>

Station has lost connection to AP because of <REASON>

<MAC>@<DEV>: failed to connect, <REASON>

Station attempted to connect to AP, but failed due to <REASON>

<MAC>@<DEV>: established connection on <FREQ>, SSID <SSID>

Station attempted and succesfully connected to AP with SSID <SSID> on frequency <FREQ>.

<MAC>@<DEV>: MIC failure!!!

TKIP message integrity check failure, somebody must be trying to break into or DOS network, If more than 1 MIC failure is encountered during 60s period, «TKIP countermeasures» state is entered.

<MAC>@<DEV>: enter TKIP countermeasures

Entered TKIP countermeasures state, this means that Station will disconnect from AP and keep silence for 60s.

AP MODE 

<DEV>: radar detected on <FREQ>

Radar detected on frequency <FREQ>, AP will look for other channel

<DEV>: data from unknown device <MAC>, sent deauth [(XXX events suppressed, YYY deauths suppressed)]

Data frame from unknown device (read — not registered to this AP) with mac address <MAC> received, AP sent deauthentication frame to it (as per 802.11). XXX is number of events that are not logged so that the log does not become too large (logs are limited to 1 entry per 5s after first 5 entries), YYY is the number of deauthentication frames that should have been sent, but were not sent, so that resources are not wasted sending too many deauthentication frames (only 10 deauth frames per second are allowed).

The likely cause of such a message is that the Station previously connected to the AP, which does not yet know it has been dropped from AP registration table, sending data to AP. Deauthentication message tells the Station that it is no longer connected.
<DEV>: denying assoc to <MAC>, failed to setup compression

Failed to initialize compression on AP, most likely because there are too many clients attempting to connect and use compression.
<DEV>: <MAC> is new WDS master

WDS slave has established connection to WDS master, this means that WDS slave starts accepting clients and acting as AP.
<DEV>: <MAC> was WDS master

This message appears after connection with <MAC> is lost, means that WDS slave will disconnect all clients and start scanning to find new WDS master.
<MAC>@<DEV>: connected [, is AP][, wants WDS]

Station with address <MAC> connected. if «is AP» present — remote device is AP, if «is WDS» presents, remote device wants to establish WDS link.
<MAC>@<DEV>: disconnected, <REASON>

Connection with Station with address <MAC> terminated due to <REASON>
<DEV>: TKIP countermeasures over, resuming

TKIP countermeasures (60s silence period) over, AP resumes acting as AP.
<DEV>: starting TKIP countermeasures

Entering TKIP countermeasures state (60s silence period), all clients will be lost.

<REASON> 

«joining failed» — can only happen on Prism cards in station mode, failed to connect to AP due to some reason

«join timeout» — happens on Station, failed to synchronize to AP (receive first beacon frame). Most likely weak signal, remote turned off, strong interference, some other RF related issue that makes communication impossible.

«no beacons» — no beacons received from remote end of WDS link. Most likely weak signal, remote turned off, strong interference, some other RF related issue that makes communication impossible.

«extensive data loss» — local interface decided to drop connection to remote device because of inability to send data to remote after multiple failures at lowest possible rate. Possible causes — too weak signal, remote device turned off, strong interference, some other RF related issue that makes communication impossible.

«decided to deauth, <802.11 reason>» — local interface decided do deauthenticate remote device using 802.11 reason <802.11 reason>.

«inactivity» — remote device was inactive for too long

«device disabled» — local interface got disabled

«got deauth, <802.11 reason>» — received deauthentication frame from remote device, 802.11 reason code is reported in <802.11 reason>

«got disassoc, <802.11 reason>» — received disassociation frame from remote device, 802.11 reason code is reported in <802.11 reason>

«auth frame from AP» — authentication frame from remote device that is known to be AP, most likely mode changes on remote device from AP to Station.

«bad ssid» — bad ssid for WDS link

«beacon from non AP» — received beacon frame from remote device that is known to be non-AP node, most likely mode changes on remote device from Station to AP.

«no WDS support» — does not report WDS support

«failed to confirm SSID» — failed to confirm SSID of other end of WDS link.

«hardware failure» — some hardware failure or unexpected behaviour. Not likely to be seen.

«lost connection» — can only happen on Prism cards in station mode, connection to AP lost due to some reason.

«auth failed <802.11 status>» — happens on Station, AP denies authentication, 802.11 status code is reported in <802.11 status>.

«assoc failed <802.11 status>» — happens on Station, AP denies association, 802.11 status code is reported in <802.11 status>.

«auth timeout» — happens on Station, Station does not receive response to authentication frames, either bad link or AP is ignoring this Station for some reason.

«assoc timeout» — happens on Station, Station does not receive response to association frames, either bad link or AP is ignoring this Station for some reason.

«reassociating» — happens on AP: connection assumed to be lost, because Station that is considered already associated attempts to associate again. All connection related information must be deleted, because during association process connection parameters are negotiated (therefore «disconnected»). The reason why Station reassociates must be looked for on Station (most likely cause is that Station for some reason dropped connection without telling AP — e.g. data loss, configuration changes).

«compression setup failure» — connection impossible, because not enough resources to do compression (too many stations that want to use compression already connected)

<802.11 reason> and <802.11 status> 

These are numeric reason/status codes encoded into 802.11 management messages. Log messages include numeric code and textual description from appropriate standard in 802.11 standards group. Although these are intended to be as descriptive as possible, it must be taken into account that actual reason/status code that appears in management frames depends solely on equipment or software manufacturer — where one device sends 802.11 management frame including proper reason/status code for situation that caused the frame, other may send frame with «unspecified» reason/status code. Therefore reason/status code should only be considered informational.

As 802.11 standards evolve, RouterOS may miss textual descriptions for reason/status codes that some devices use. In such case numeric value should be used to lookup meaning in 802.11 standards.

In order to properly interpret reason/status code, good understanding of 802.11 group standards is necessary. Most of the textual descriptions are self-explaining. Explanation for some of most commonly seen reson/status codes follows.

class 2 frame received (6) — device received «class 2» frame (association/reassociation management frame) before completing 802.11 authentication process;

class 3 frame received (7) — device received «class 3» frame (data frame) before completing association process;

http://wiki.mikrotik.com/wiki/Manual:Wireless_Debug_Logs