Manual:Wireless Debug Logs

Debugging wireless problems using Logs.

By default RouterOS wireless log shows that the client connects and disconnects in a simple matter:

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

It is enough for regular user to know that the wireless client with MAC address "00:80:48:41:AF:2A" is connected to wireless interface "wlan1". But actually there a more log entries that aren't shown here. They are called 'debug' logs which give more detailed information. For example the same client connects to the AP and with debug logs you will see more info than previosly:

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

These logs will give you more specific info what is happening, first line shows that the wireless client tries to connect to the AP. On the second line the AP checks if that client is allowed to connect to the AP. And only on the third line you will see that the client is connected. This only one example of the debug log messages. The description of all the 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

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 log does not get polluted (logs are limited to 1 entry per 5s after first 5 entries), YYY is 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).

Likely cause of such message is Station previously connected to AP, which does not yet know it has been dropped from AP registration table, sending data to AP. Deauthentication message tells Station it is not connected any more.

<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)