By default the log shows that RouterOS wireless clients connecting and disconnecting a simple entry:
That was enough for ordinary users to know that the wireless client with MAC address "00:80:48:41: AF: 2A" connected to the wireless interface "wlan1". But there are actually more available than the log entries are displayed in the standard logging. They're called 'debug' log which gives more detailed information. In the following example you will see the Debug Logs the same client connects to the AP in more detail than that found in typical logging:
Debug log will give you more specific informantion on every step of the client wireless connection and disconnection. The first line indicates that the wireless client tries to connect to the AP. On the second line AP examined to see whether the client is allowed to connect to the AP and the resulting action. And only in the third row you can see that the client is connected. This is just one example of the debug log messages. Overview of all debug entries are written below.
To enable log debug wireless you have to run a command like:
Or in Winbox:
This will help you understand and fix wireless problems with ease and with little interaction with the support team.
Station Mode
The station has lost its connection to the AP because
The station tries to connect to the AP, but fails because
The station tried and successfully connected to the AP with the SSID
TKIP message integrity check fails, one should try to get into DOS or network, if more than 1 MIC failures encountered during the period of the '60s, "TKIP countermeasures" state is entered.
Entered prevention TKIP countries, this means that the station will be disconnected from the AP and silent for 60s.
Ap Mode
Data frames from unknown devices (read - these unregistered AP) with
The likely cause of the message is that the previous station is connected to the AP, who do not know it had come down from the AP registration table, sending data to the AP. Deauthentication message telling stations that are no longer connected.
Failed to initialize the compression in the AP, most likely because there are too many clients try to connect and use compression.
WDS-slave has established a connection to master WDS, this means that the WDS slave began to receive clients and act as an AP.
This message appears after the connection with
Stations with addresses
Connection with the stations with addresses ending
Connection with the stations with addresses ending
prevention TKIP (60s period of silence) above, the AP resumes acting as AP.
Entering the state prevention TKIP (60S silent period), all clients will be lost.
"Joining failed" - can only occur on Prism cards in station mode, failed to connect to the AP for several reasons
"Join timeout" - which occurs in the station, failed to synchronize to an AP (receiving the first beacon frames). Most of the weak signal as possible, the remote is turned off, a strong disturbance, several other issues related to RF to make communication impossible.
"No beacons" - no beacon received from the remote end of WDS link. Most of the weak signal as possible, the remote is turned off, a strong disturbance, several other issues related to RF to make communication impossible.
"Extensive data loss" - local interface decided to drop the connection to the remote device due to the inability to send data to the remote after a few failures at the lowest possible level. Possible causes - too weak signal, the remote device is turned off, the disorder is strong, a few other issues related to RF to make communication impossible.
"Decided to deauth, <802.11 reason>" - local interface remote deauthenticate decided to use the excuse 802.11 <802.11 reason>.
"Inactivity" - the remote device is inactive for too long
"Device disabled" - local interface got disabled
"Got deauth, <802.11 reason>" - accept the separation of the frame from a remote device, 802.11 reason code is reported in <802.11 reason>
"Got disassoc, <802.11 reason>" - disassociation frame received from remote devices, 802.11 reason code is reported in <802.11 reason>
"Frames from the AP auth" - authentication frame from a remote device, known as AP, which seem to change the mode on the remote device from the AP to Station.
"Ssid bad" - bad for ssid WDS link
"Beacons from non-AP" - receive beacon frames from remote devices known non-AP node, the mode changes to the device, most likely away from the station to the AP.
"No WDS support" - did not report supports WDS
"Failed to confirm the SSID" - failed to confirm the SSID the other end of the WDS link.
"Hardware failure" - some hardware failures or unexpected behavior. It is impossible to see.
"Lost connection" - can only occur on Prism cards in station mode, the connection to the AP lost for several reasons.
"Auth failed <802.11 status>" - which occurs in the station, the AP denied authentication, 802.11 status code is reported in <802.11 status>.
"Assoc failed <802.11 status>" - which occurs in the station, the AP denied association, reported in the status code 802.11 <802.11 status>.
"Auth timeout" - which occurs in the station, Station does not receive a response to the authentication frame, either a bad link or AP ignore this station for several reasons.
"Assoc timeout" - which occurs in the station, Station does not receive a response to the frame of the association, either a bad link or AP ignore this station for several reasons.
"Reassociating" - happens on the AP: connection assumed to be lost, because the station was considered already associated attempts to associate again. All information related to the connection must be removed, because during the process of association of the connection parameters are negotiated (because it is "disconnected"). The reason why Station reassociates must look at the Station (the most likely cause is that the station for some reason dropped connection without telling AP - eg loss of data, configuration changes).
"Compression setup failure" - the connection is not possible, due to insufficient resources to do the compression (too many stations that want to use compression is already connected)
<802.11 Reason> And <802.11 status>
This is the reason for the status code numbers / encoded into the 802.11 management messages. Log messages include numeric codes and a textual description of the proper standards in the 802.11 standard. While this is intended to clearly as possible, should be taken into account that the real reason / status code that appears in the frame of management depends only on the equipment or software makers - in which one device sends 802.11 management frames including the right reason / status code for the situation that led to the frame others, can send frames with the reason "not specified" / status code. Hence the reason / status code should only be considered information.
Like the 802.11 standard evolved, RouterOS can lose a textual description for reason code / status that some devices are used. In such cases the numerical values should be used to search for meaning in the 802.11 standard.
In order to properly interpret the reason / status code, a good understanding of the 802.11 standard is required. Most of the textual descriptions are self-explaining. Explanation for some of the most commonly seen reson code / status follows.
Class 2 frames received (6) - received the "Class 2" frame (association / reassociation frame management) before completing the 802.11 authentication process;
Class 3 frame received (7) - the device receives a "class 3" frame (frame data) before completing the process of association;
- End -