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;
Кадры Управления и сообщения Подключения/Разъединения
managementframes.pdf
http://wiki.mikrotik.com/wiki/Wireless_Deb...02.11_status.3E