Wireless Troubleshooting

Wireless Troubleshooting

Summary

This document provides comprehensive guidance for troubleshooting MikroTik wireless connectivity issues. Wireless networks can experience various problems ranging from simple configuration errors to complex RF environment challenges. Understanding how to effectively diagnose and resolve these issues is essential for maintaining reliable wireless connectivity.

The troubleshooting process begins with understanding the wireless logging system, which provides detailed information about connection attempts, successful associations, and disconnection events. RouterOS offers multiple log levels, with debug logs providing the most detailed information about each step of the wireless connection process. By enabling and analyzing these logs, network administrators can quickly identify the root cause of connectivity problems.

Common wireless issues include authentication failures, signal quality problems, interference from external sources, hardware limitations, and configuration mismatches between access points and client devices. This guide covers the complete range of troubleshooting techniques, from basic log analysis to advanced RF environment assessment, enabling administrators to diagnose and resolve wireless problems efficiently.

Enabling Wireless Debug Logs

Understanding Log Levels

RouterOS wireless logging operates at different verbosity levels, each providing varying amounts of detail about wireless events. By default, the system logs only basic connection events, which may be insufficient for diagnosing complex issues. Enabling debug-level logging reveals detailed information about each step of the connection process, including authentication attempts, access list checks, rate negotiations, and disconnection reasons.

The default wireless log provides simple entries indicating client connections and disconnections:

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

While sufficient for basic monitoring, this output lacks the detail needed for troubleshooting connection failures. Debug logging expands this output significantly, showing each step of the connection negotiation:

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

Enabling Debug Logging

To enable wireless debug logs, add a logging rule that captures wireless events at debug level:

/system logging
add topics=wireless,debug action=memory

This configuration sends debug-level wireless messages to the memory log buffer. For persistent logging or troubleshooting in production environments, consider using a disk-based log action:

/system logging action set memory memory-lines=1000 memory-stop-on-full=no
/system logging action add name=disk disk-file-name=wifi-debug disk-lines-per-file=10000 disk-size=10M
/system logging add topics=wireless,debug action=disk

After enabling debug logging, reproduce the connectivity issue while monitoring the logs. The detailed entries will reveal exactly where the connection process fails, enabling targeted troubleshooting.

Station Mode Log Messages

Connection Loss Events

Station mode devices generate specific log messages when experiencing connectivity issues. Understanding these messages helps quickly identify the underlying cause.

Lost Connection Messages:

The message format <MAC>@<DEV>: lost connection, <REASON> indicates that a station has lost its connection to the access point. The reason field contains specific information about why the disconnection occurred. Common reasons include signal degradation, interference, timeout events, and authentication failures. When this message appears repeatedly, it typically indicates an ongoing connectivity problem that requires investigation.

Connection Failure Messages:

The format <MAC>@<DEV>: failed to connect, <REASON> appears when a station attempts but fails to establish a connection. This differs from a lost connection in that the station never successfully associates. The reason field provides details about the specific failure point, such as authentication rejection, association timeout, or incompatibility with the access point.

Successful Connection Messages:

The format <MAC>@<DEV>: established connection on <FREQ>, SSID <SSID> confirms a successful connection, including the operating frequency and network name. This message is useful for verifying that stations can connect successfully and for documenting the connection parameters.

Security-Related Messages

MIC Failures:

The message <MAC>@<DEV>: MIC failure!!! indicates a Message Integrity Check failure using TKIP encryption. This typically indicates either interference corrupting frames or, more seriously, someone attempting to breach the network security. When multiple MIC failures occur within a 60-second period, the device enters TKIP countermeasures mode.

TKIP Countermeasures Mode:

When a station enters TKIP countermeasures mode with message <MAC>@<DEV>: enter TKIP countermeasures, the device disconnects from the access point and remains silent for 60 seconds. This protective measure prevents further attacks during an active security breach. After the countermeasures period expires, the station resumes normal operation.

Access Point Mode Log Messages

Radar and Frequency Events

Radar Detection:

The message <DEV>: radar detected on <FREQ> indicates that the access point has detected radar activity on the current operating frequency. This is particularly relevant in 5GHz bands where DFS (Dynamic Frequency Selection) is required by regulatory authorities. Upon detecting radar, the AP automatically switches to a different channel to avoid interference with radar systems. This behavior is normal and expected in environments where radar systems operate.

CAC (Channel Availability Check)

When using DFS channels in 5GHz bands, MikroTik devices must perform a Channel Availability Check (CAC) before using those frequencies. CAC involves scanning the channel for radar signals for a specified period (typically 60 seconds for standard DFS channels, up to 10 minutes for some regulatory domains).

CAC Log Messages:

The message <DEV>: DFS channel <FREQ> <state> indicates CAC status during startup or after radar detection. Common states include:

• starting CAC - Beginning the channel availability check
• CAC completed - Channel is clear and ready for use
• CAC failed - Radar detected during check, channel blocked

CAC Troubleshooting:

If your AP is slow to come up on 5GHz DFS channels or clients cannot connect:

1. Check if CAC is in progress - Monitor logs for CAC status:

   /log print where message~"CAC"

2. Use skip-dfs-channels option - If rapid startup is needed, skip channels requiring long CAC:

   /interface wifi channel add name=5ghz frequency=5180,5200,5240,5260 skip-dfs-channels=10min-cac

3. Avoid DFS entirely for reliability - Use non-DFS channels (36-48, 149-165):

   /interface wifi channel add name=5ghz-nodfs frequency=5180,5200,5240,5260 skip-dfs-channels=all

4. Check regulatory domain - Some regions have longer CAC requirements. Verify your country setting allows the channels you want to use:

   /ip cloud print

The 10-minute CAC applies to certain frequencies in some regulatory domains (particularly ETSI/Europe). If operating in those regions and needing quick AP startup, use the skip-dfs-channels=10min-cac option to avoid those channels.

Unknown Device Events

Data from Unknown Devices:

The message <DEV>: data from unknown device <MAC>, sent deauth [(XXX events suppressed, YYY deauths suppressed)] appears when an access point receives data frames from a device that is not registered in its association table. This commonly occurs when a previously connected client loses its association state on the AP while still attempting to transmit data. The AP sends deauthentication frames to inform the client that it is no longer connected.

The message includes counters indicating how many similar events were suppressed (XXX) to prevent log flooding and how many deauthentication frames were not sent (YYY) to conserve system resources. These suppression mechanisms prevent denial-of-service conditions from excessive logging.

WDS-Related Messages

WDS Master Events:

WDS (Wireless Distribution System) operations generate specific log messages indicating master-slave relationships. The message <DEV>: <MAC> is new WDS master indicates that a WDS slave has successfully connected to a WDS master, and the slave will now begin accepting client connections and acting as an access point. Conversely, <DEV>: <MAC> was WDS master indicates that the connection to the WDS master has been lost, and the slave will disconnect all clients and begin scanning for a new master.

Connection State Messages

Client Connection:

The message <MAC>@<DEV>: connected [, is AP][, wants WDS] indicates that a station has connected to the access point. The optional flags provide additional information: “is AP” indicates that the connected device is itself an access point (useful for WDS configurations), and “wants WDS” indicates the device is requesting a WDS link establishment.

Client Disconnection:

The message <MAC>@<DEV>: disconnected, <REASON> indicates that a previously connected station has disconnected. The reason field provides specific information about why the disconnection occurred.

TKIP Countermeasures on AP:

The access point generates <DEV>: starting TKIP countermeasures when entering the 60-second TKIP countermeasures state, during which all clients are disconnected. The message <DEV>: TKIP countermeasures over, resuming indicates that the countermeasures period has ended and normal operation has resumed.

Compression and Resource Events

Compression Setup Failure:

The message <DEV>: denying assoc to <MAC>, failed to setup compression indicates that the AP cannot initialize frame compression for a connecting client. This typically occurs when too many clients are already connected and using compression, exhausting available system resources. The client connection is denied to maintain performance for existing clients.

Disconnection Reason Codes

Connection Establishment Failures

“joining failed”: This reason applies only to Prism cards operating in station mode. It indicates that the station failed to connect to the access point for an unspecified reason. When this error occurs, review the debug logs to identify the specific failure point in the connection process.

“join timeout”: This error occurs in station mode when the device fails to receive beacon frames from the access point. Common causes include weak signal strength, the remote device being powered off, significant interference, or other RF-related issues preventing synchronization. Check signal strength and verify that the access point is operational.

“no beacons”: Specific to WDS links, this reason indicates that beacon frames are not being received from the remote WDS endpoint. This indicates a fundamental connectivity problem requiring investigation of the RF link between devices.

“extensive data loss”: This reason indicates that the local interface has decided to drop the connection after multiple failures to transmit data at the lowest possible rate. The connection is terminated when the interface determines that reliable communication is impossible. Common causes include extremely weak signal, remote device failure, interference, or other RF issues preventing frame delivery.

Authentication and Association Failures

“auth failed <802.11 status>”: This message appears in station mode when the access point denies authentication. The 802.11 status code provides more specific information about why authentication was rejected. Common reasons include incorrect credentials, MAC filtering enabled on the AP, or the client being blacklisted.

“assoc failed <802.11 status>”: Similar to authentication failure, this message indicates that the access point has rejected the association request. Even after successful authentication, the association can fail due to resource limits, security policy violations, or incompatibility between the client and AP capabilities.

“auth timeout”: This error occurs when the station does not receive a response to its authentication frames. Either the wireless link is insufficiently reliable for frame delivery, or the access point is intentionally ignoring the station (such as when MAC filtering rejects the client).

“assoc timeout”: The station sent association frames but received no response. This indicates either link reliability problems or the AP choosing not to respond to the association request.

Deauthentication and Disassociation

“decided to deauth, <802.11 reason>”: The local interface initiated deauthentication of the remote device using an 802.11 reason code. This typically occurs when the local device determines that maintaining the connection is no longer desirable, such as when an access point disconnects an inactive client.

“got deauth, <802.11 reason>”: The device received a deauthentication frame from the remote endpoint. The 802.11 reason code indicates why the remote device initiated the disconnection. This could be due to the remote device restarting, changing configuration, or intentionally disconnecting.

“got disassoc, <802.11 reason>”: Similar to deauthentication, this indicates receipt of a disassociation frame. Disassociation differs from deauthentication in that it preserves the authentication state while removing the association.

Configuration and Mode Issues

“bad ssid”: This error occurs during WDS link establishment when the SSID configured on one end does not match the other end. Verify that both WDS endpoints have identical SSID configurations.

“beacon from non AP”: This message indicates that beacon frames were received from a device that is not configured as an access point. This typically occurs when one endpoint of a WDS link changes mode from station to access point or vice versa without proper coordination.

“no WDS support”: One endpoint of a WDS link does not advertise WDS capability. Ensure that both devices have WDS enabled in their wireless configuration.

“failed to confirm SSID”: The WDS link establishment failed because the SSID could not be confirmed between endpoints. This may indicate configuration mismatch or transient communication issues.

Hardware and System Issues

“hardware failure”: This rare reason indicates unexpected hardware behavior or a hardware fault. If this error persists, the wireless card may require replacement or further diagnosis.

“device disabled”: The local wireless interface has been disabled. Check the interface status using /interface wireless print and enable the interface if necessary.

“inactivity”: The remote device has been inactive for too long, triggering the inactivity timeout. This is normal behavior for access points managing client session timeouts.

“reassociating”: This message appears on access points when a station that was previously associated attempts to associate again. This typically indicates that the station lost its connection without properly disconnecting, such as due to data loss, configuration changes, or power saving mode. The AP clears all connection state for the station and requires a fresh association.

Compression and Frame Issues

“compression setup failure”: The connection cannot be established because insufficient system resources are available for frame compression. This occurs when too many stations are already connected and using compression features.

“control frame timeout”: The access point was unable to transmit to the client, similar to the “extensive data loss” condition. This indicates fundamental communication problems at the lowest transmission rates, often due to severe signal degradation or interference.

802.11 Reason and Status Codes

Understanding Protocol Codes

802.11 management frames include numeric reason and status codes that provide detailed information about protocol-level events. RouterOS logs include both the numeric code and a textual description from the applicable 802.11 standards. However, the accuracy of these descriptions depends on the remote device correctly implementing the standard.

Different manufacturers implement 802.11 reason and status codes with varying degrees of compliance. A device may send an appropriate reason code describing the exact situation, while another device may simply send an “unspecified” code regardless of the actual cause. Therefore, these codes should be considered informational rather than definitive.

Common Reason Codes

Class 2 Frame Received (6): This code indicates that the device received a class 2 management frame (association or reassociation frame) before completing the 802.11 authentication process. This typically occurs when a client attempts to associate before authentication completes, which may indicate timing issues or client software problems.

Class 3 Frame Received (7): This code indicates that the device received a class 3 frame (data frame) before completing the association process. This suggests that a client is transmitting data before fully associating with the access point, which may indicate client configuration problems or timing issues in the connection sequence.

Wireless FAQ

Connection Issues

Why Can’t I Connect to MikroTik 802.11n AP with Apple Mac Devices?

This problem occurs specifically with Apple devices using Broadcom wireless chipsets. To resolve connectivity issues with these devices, ensure that the wireless access point is not using short preamble mode. Configure the preamble mode to “long” or “both” in the wireless security profile:

/interface wireless security-profile set default preamble-mode=both

Short preamble is designed for efficiency in environments with low interference, but Broadcom chipsets have compatibility issues with this mode on 802.11n networks. Using long preamble ensures broader device compatibility at a minimal performance cost.

After Changing Wireless Settings, the Link Works Unstably

When wireless tuning experiments result in an unstable or non-functional link, the configuration can be reset to restore known-good settings. Use the reset-configuration command within the wireless menu to reset only wireless-specific settings:

/interface wireless reset-configuration wlan1

Caution

The reset-configuration command disables the wireless interface. If you are connected to the router remotely through the wireless link being reset, you will lose connectivity. Perform this operation from a wired connection or ensure you have physical access to the device.

Performance and Statistics

What Are Wireless Retransmissions and Where to Check Them?

Wireless retransmissions occur when a device transmits a frame but does not receive an acknowledgment (ACK), causing the frame to be re-sent. Each unsuccessful transmission attempt counts as a retransmission. High retransmission rates indicate signal quality problems and reduce effective throughput while increasing latency.

To check retransmission statistics, compare the “frames” value to the “hw-frames” value in the interface registration table:

/interface wireless registration-table print detail

The difference between hw-frames and frames represents the number of retransmissions. A small number of retransmissions is normal on any wireless link. However, if frames significantly exceeds hw-frames multiple times, investigate signal quality, interference sources, and potential obstructions in the RF path.

Can I Compare Frames with hw-frames on Nstreme Links?

The Nstreme protocol has different frame counting behavior. The “frames” counter only includes frames containing actual data. In Nstreme mode, acknowledgment frames may be transmitted alone when no data is available, and these ACK-only frames are not counted in “frames” but appear in “hw-frames”. When traffic flows bidirectionally at maximum speed, the comparison between frames and hw-frames behaves similarly to standard wireless links.

Transmit Power Configuration

What TX-Power Values Can I Use?

The default TX-power setting represents the maximum power the wireless card can transmit, as defined in the card’s EEPROM. This default value is the recommended starting point for most deployments.

Danger

Setting TX-power values higher than the default is possible but carries significant risk. Excessive power can damage the wireless card over time due to overheating of the power amplifier. Only reduce TX-power from the default setting.

Increasing TX-power beyond the rated specifications can cause several problems including overheating of the power amplifier chip, degradation of range and throughput due to amplifier non-linearity, increased power consumption potentially overloading the board’s power supply, and voltage drops that may cause system instability.

What TX-Power-Mode Is the Best?

The tx-power-mode setting controls how the wireless card selects transmit power for different data rates. The default setting is “default”.

default: The card uses TX-power values from its EEPROM and ignores any user-specified TX-power setting. This mode provides the most consistent performance and is recommended for most deployments.

card-rates: TX-power is calculated for each data rate based on the card’s transmit power algorithm from EEPROM, using the user-specified TX-power value as an argument. This mode allows more granular power control while maintaining hardware-protected operation.

all-rates-fixed: The card uses a single TX-power value for all data rates, as specified by the user. This mode is not recommended for most situations because higher data rates require lower TX-power for proper operation, and forcing uniform power across all rates can cause problems.

Caution

For AR9300 and newer Atheros wireless chipsets, only “all-rates-fixed” mode is available. The “card-rates” option does not function on these chipsets. In general, use tx-power-mode=card-rates when adjusting power, and prefer lowering power over increasing it.

Signal Quality and Performance Metrics

What Is CCQ and How Are Values Determined?

Client Connection Quality (CCQ) is a percentage value representing how effectively the available bandwidth is being used compared to the theoretical maximum. CCQ is calculated as a weighted average of Tmin/Treal ratios for each transmitted frame, where Tmin represents the time required to transmit a frame at the highest rate with no retries, and Treal represents the actual transmission time including retries and rate adaptation.

A CCQ value of 100% indicates that all frames are transmitted at the maximum possible rate with no retransmissions. Lower CCQ values indicate either rate adaptation to lower speeds or the presence of retransmissions. CCQ provides a quick indicator of link quality and efficiency.

What Is hw-retries Setting?

The hw-retries setting controls how many times the wireless card attempts to transmit a frame before considering the transmission a failure. When a transmission fails, the data rate is decreased and the frame is retried. After three sequential failures at the lowest supported rate, transmission to that destination is suspended for the duration specified by on-fail-retry-time.

If no successful transmission occurs during disconnect-timeout, the connection is closed with an “extensive data loss” message. Frame transmission continues until either success occurs, the disconnect-timeout expires, or frame-lifetime is exceeded.

Note

In Nstreme mode, the on-fail-retry-time, disconnect-timeout, and frame-lifetime settings are not used. After three sequential failures at the lowest rate, the wireless link is immediately disconnected.

What Is disconnect-timeout Setting?

The disconnect-timeout interval begins after the third sending failure at the lowest data rate. At this point, 3 multiplied by (hw-retries plus 1) frame transmissions at the lowest rate have failed. During the disconnect-timeout period, packet transmission continues with retry attempts at intervals specified by on-fail-retry-time.

If no frame is successfully transmitted during the disconnect-timeout period, the connection is closed and logged as “extensive data loss”. Successful frame transmission during this period resets the timer. This setting is particularly important for maintaining backbone links that must remain operational despite temporary signal degradation.

What Is adaptive-noise-immunity Setting?

Adaptive Noise Immunity (ANI) is a feature available on Atheros AR5212 and newer chipset cards that dynamically adjusts receiver parameters to minimize the effects of interference and noise on signal quality. ANI continuously monitors the RF environment and adapts receiver thresholds and parameters to optimize performance in varying conditions.

Signal Strength Measurement

How Does Wireless Device Measure Signal Strength with Access Lists?

When access lists or connect lists filter clients based on signal strength, the reported signal level is calculated as an exponentially weighted moving average with a 50% smoothing factor. This averaging provides a stable reading that doesn’t fluctuate wildly with each received frame, making it more useful for decision-making purposes.

Error Correction

What Error Correction Methods Are Supported?

RouterOS supports Forward Error Correction (FEC) using convolutional coding with coding rates of 1/2, 2/3, or 3/4. These coding rates determine the ratio of data bits to parity bits, with higher rates providing more error correction capability at the cost of reduced data throughput.

ARQ (Automatic Repeat Request) is supported in Nstreme protocols. Standard 802.11 does not include ARQ; instead, frame retransmission is based on the acknowledgment protocol. FEC provides inherent error correction without requiring retransmission, while ARQ requests retransmission of frames that fail checksum validation.

160MHz Configuration

Configuring RouterOS Device for 160MHz Channel Width

For RouterOS devices supporting 4x4 transmission, enabling 160MHz channel width requires additional configuration. Set rate-set=default on the wireless interface to make all spatial streams available:

/interface wireless set wlan1 rate-set=default

If clients do not support Extended NSS and can only perform 2x2 transmission, limit the VHT MCS set to match client capabilities:

/interface wireless set wlan1 vht-supported-mcs=mcs0-9,mcs0-9,none

Wireless Setup Troubleshooting

Amplifiers and Signal Boosting

Will an Amplifier Improve the Speed on My Link?

The effectiveness of signal amplification depends on the specific RF environment. Amplifiers increase both transmitted and received signal power, but they also amplify noise. In quiet RF environments with minimal competing signals, amplification may improve performance. However, in congested areas with many competing wireless signals, amplification increases received noise along with the desired signal, potentially degrading performance.

Better alternatives to amplification include using higher-gain antennas, optimizing antenna positioning, reducing output power to minimum necessary levels, and selecting optimal operating frequencies. A good antenna with appropriate gain is almost always more effective than an amplifier for improving wireless link performance.

Fine-Tuning with hw-retries

How to Fine-Tune Wireless Link with hw-retries

Understanding the retry mechanism helps optimize wireless performance. 802.11 devices have limited feedback from the environment to tune their operation. The primary feedback mechanism is success or failure of frame transmission, indicated by whether acknowledgments are received.

RouterOS implements a sophisticated algorithm using this limited feedback to optimize medium utilization. The hw-retries setting controls how many retry attempts occur before the device concludes that a particular data rate is not suitable. Higher hw-retries values provide more feedback about link quality at each rate, enabling more accurate rate selection at the cost of increased latency during failed transmissions.

Higher hw-retries (values above the default) are recommended for point-to-point backbone links where link stability is critical. The additional feedback helps maintain optimal rates and provides the algorithm with more data about channel characteristics.

Lower hw-retries (values below the default) make rate selection respond more quickly to changing conditions. This is suitable for point-to-multipoint networks where stations frequently connect and disconnect, and lower latency is more important than precise rate optimization.

Values below 2 are generally not recommended as they don’t provide sufficient feedback for meaningful rate adaptation.

The on-fail-retry-time and disconnect-timeout settings control how aggressively the device attempts to maintain connections during periods of packet loss. Larger disconnect-timeout values keep weak links established longer, which is useful for known-critical backbone links. In point-to-multipoint networks, large timeout values increase latency when attempting to transmit to disconnected clients.

The frame-lifetime setting controls how long the AP attempts to deliver frames before discarding them. For real-time traffic like VoIP where some packet loss is acceptable but latency is critical, limiting frame-lifetime prevents excessive buffering delays. Disabled frame-lifetime ensures in-order delivery of all frames regardless of how long transmission takes.

Repeater Configurations

Is It Possible to Use Wireless Repeater with One Radio Interface?

Wireless repeater functionality can be achieved using WDS on an interface configured in ap-bridge mode. In newer RouterOS versions, wireless repeater mode can be configured directly:

/interface wireless set wlan1 mode=station-bridge

This configuration allows the device to connect to an upstream access point while simultaneously providing access point services to downstream clients, effectively extending the wireless network coverage.

Nv2 Protocol Issues

Nv2 Wireless Link Disconnects Very Often

When Nv2 links experience frequent disconnections with “control frame timeout” messages in the logs, the issue is often related to signal quality at the modulation boundaries. Try reducing the transmit output power to achieve a cleaner signal:

/interface wireless set wlan1 tx-power-mode=card-rates
/interface wireless set wlan1 tx-power=10

Reducing power slightly often improves stability by avoiding the modulation error floor. If the problem persists, try operating on a different frequency with less interference. If all troubleshooting attempts fail, contact MikroTik support with support output files from both the AP and station made after the disconnections occur.

Related Topics

• Wireless Interface for general wireless interface configuration
• Wireless Case Studies for practical deployment examples
• Spectral Scan for interference detection and analysis
• Registration Table for client connection monitoring
• Scan for discovering available access points
• W60G for 60GHz wireless documentation
• CAPsMAN for centralized wireless management
• Nstreme for proprietary high-performance wireless protocol
• NV2 for TDMA wireless protocol documentation
• Interface Stats for wireless interface statistics