本页说明如何通过启用并分析详细的调试日志，来排查 MikroTik RouterOS 中的无线连接问题，包括客户端连接、断开连接以及 MIC 失败或雷达检测等安全事件。

无线故障排除

无线调试日志

使用日志调试无线问题。

默认情况下，RouterOS 无线日志将客户端的连接和断开显示为简单的条目：

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

对于普通用户来说，知道 MAC 地址为 "00:80:48:41:AF:2A" 的无线客户端连接到了无线接口 "wlan1" 就足够了。但实际上，可用的日志条目比标准日志记录中显示的更多。它们被称为 'debug' 日志，可提供更详细的信息。在下面的 Debug Log 示例中，你将看到同一个客户端连接到 AP 的详细信息，比典型日志记录中的内容更丰富：

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 Log 将为你提供关于客户端无线连接和断开每一步的更具体信息。第一行显示无线客户端尝试连接到 AP。第二行中，AP 检查该客户端是否被允许连接到 AP，并显示结果操作。只有第三行你才会看到客户端已连接。这只是 debug 日志消息的一个示例。所有 debug 条目的说明如下。

要启用无线 debug 日志，你应该执行以下命令：

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

这将帮助你轻松理解并修复无线问题，减少与支持团队的沟通。

STATION MODE

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

Station 由于 <REASON> 而失去了与 AP 的连接。

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

Station 尝试连接到 AP，但由于 <REASON> 而失败。

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

Station 尝试连接并成功连接到 SSID 为 <SSID>、频率为 <FREQ> 的 AP。

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

TKIP 消息完整性检查失败，一定有人在试图闯入或对网络进行 DOS 攻击。如果在 60 秒期间遇到超过 1 次 MIC 失败，就会进入 "TKIP countermeasures" 状态。

<MAC>@<DEV>: enter TKIP countermeasures

进入了 TKIP countermeasures 状态，这意味着 Station 将与 AP 断开连接并保持静默 60 秒。

AP MODE

<DEV>: radar detected on <FREQ>

在频率 <FREQ> 上检测到雷达，AP 将寻找另一个信道。

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

收到了来自未知设备（即未注册到此 AP 的设备）、MAC 地址为 <MAC> 的数据帧，AP 向其发送了一个解除认证帧（根据 802.11）。XXX 是未记录的事件数量，以免日志变得过大（在前 5 条条目之后，日志被限制为每 5 秒 1 条）；YYY 是本应发送但未发送的解除认证帧数量，以免浪费资源发送过多的解除认证帧（每秒只允许发送 10 个 deauth 帧）。

此类消息的可能原因是：Station 之前连接到了该 AP，而该 AP 尚不知道该 Station 已从 AP 注册表中被移除，Station 仍在向 AP 发送数据。解除认证消息告诉 Station 它已不再连接。

<DEV>: denying assoc to <MAC>, failed to setup compression

AP 上压缩初始化失败，很可能是因为有太多客户端尝试连接并使用压缩。

<DEV>: <MAC> is new WDS master

WDS slave 已与 WDS master 建立连接，这意味着 WDS slave 开始接受客户端并作为 AP 工作。

<DEV>: <MAC> was WDS master

此消息在与 <MAC> 的连接丢失后出现，这意味着 WDS slave 将断开所有客户端，并开始扫描以寻找新的 WDS master。

<MAC>@<DEV>: connected [, is AP][, wants WDS]

地址为 <MAC> 的 Station 已连接。如果存在 "is AP"，则远端设备是 AP；如果存在 "wants WDS"，则远端设备想要建立 WDS 链路。

<MAC>@<DEV>: disconnected, <REASON>

与地址为 <MAC> 的 Station 的连接由于 <REASON> 而终止。

<DEV>: TKIP countermeasures over, resuming

TKIP countermeasures（60 秒静默期）已结束，AP 恢复作为 AP 工作。

<DEV>: starting TKIP countermeasures

进入 TKIP countermeasures 状态（60 秒静默期），所有客户端都将断开。

<REASON>

"joining failed" - 只会在 station 模式下的 Prism 网卡上发生，由于某种原因未能连接到 AP。

"join timeout" - 发生在 Station 上，未能与 AP 同步（接收第一个信标帧）。很可能是信号弱、远端关闭、强干扰，或其他使通信无法进行的 RF 相关问题。

"no beacons" - 未从 WDS 链路的远端收到任何信标。很可能是信号弱、远端关闭、强干扰，或其他使通信无法进行的 RF 相关问题。

"extensive data loss" - 本地接口决定断开与远端设备的连接，因为在以最低可能速率多次失败后仍无法向远端发送数据。可能的原因 - 信号太弱、远端设备关闭、强干扰，或其他使通信无法进行的 RF 相关问题。

"decided to deauth, <802.11 reason>" - 本地接口决定使用 802.11 原因 <802.11 reason> 对远端设备解除认证。

"inactivity" - 远端设备处于非活动状态太长时间。

"device disabled" - 本地接口被禁用。

"got deauth, <802.11 reason>" - 收到来自远端设备的解除认证帧，802.11 原因码在 <802.11 reason> 中报告。

"got disassoc, <802.11 reason>" - 收到来自远端设备的解除关联帧，802.11 原因码在 <802.11 reason> 中报告。

"auth frame from AP" - 来自已知为 AP 的远端设备的认证帧，很可能是远端设备的模式从 AP 变为 Station。

"bad ssid" - WDS 链路的 ssid 错误。

"beacon from non AP" - 收到来自已知为非 AP 节点的远端设备的信标帧，很可能是远端设备的模式从 Station 变为 AP。

"no WDS support" - 未报告 WDS 支持。

"failed to confirm SSID" - 未能确认 WDS 链路另一端的 SSID。

"hardware failure" - 某些硬件故障或意外行为。不太可能出现。

"lost connection" - 只会在 station 模式下的 Prism 网卡上发生，由于某种原因失去了与 AP 的连接。

"auth failed <802.11 status>" - 发生在 Station 上，AP 拒绝认证，802.11 状态码在 <802.11 status> 中报告。

"assoc failed <802.11 status>" - 发生在 Station 上，AP 拒绝关联，802.11 状态码在 <802.11 status> 中报告。

"auth timeout" - 发生在 Station 上，Station 未收到对认证帧的响应，要么是链路质量差，要么是 AP 由于某种原因忽略此 Station。

"assoc timeout" - 发生在 Station 上，Station 未收到对关联帧的响应，要么是链路质量差，要么是 AP 由于某种原因忽略此 Station。

"reassociating" - 发生在 AP 上，假定连接已丢失，因为被认为已关联的 Station 尝试再次关联。所有与连接相关的信息都必须删除，因为在关联过程中会协商连接参数（因此是 "disconnected"）。Station 重新关联的原因必须在 Station 上查找（最可能的原因是 Station 由于某种原因在未告知 AP 的情况下断开了连接 - 例如数据丢失、配置更改）。

"compression setup failure" - 无法建立连接，因为没有足够的资源进行压缩（已经有太多想要使用压缩的 station 连接）。

"control frame timeout" - AP 无法向客户端发送数据（类似于你在 802.11 协议中看到的错误消息 - extensive data loss）。

<802.11 reason> and <802.11 status>

这些是编码到 802.11 管理消息中的数字原因/状态码。日志消息包含数字代码以及来自 802.11 标准中相应标准的文本描述。尽管这些描述力求尽可能详尽，但必须考虑到：管理帧中出现的实际原因/状态码完全取决于设备或软件制造商 - 一台设备可能发送包含针对导致该帧情况的适当原因/状态码的 802.11 管理帧，而另一台设备可能发送带有 "unspecified" 原因/状态码的帧。因此，原因/状态码只应被视为参考信息。

随着 802.11 标准的发展，RouterOS 可能会缺少某些设备使用的 reason/status 码的文本描述。在这种情况下，应使用数字值来在 802.11 标准中查找其含义。

为了正确解释 reason/status 码，有必要对 802.11 系列标准有良好的理解。大多数文本描述本身已不言自明。以下是一些最常见 reason/status 码的解释：

• class 2 frame received (6) - 设备在完成 802.11 认证过程之前收到了 "class 2" 帧（关联/重新关联管理帧）；

• class 3 frame received (7) - 设备在完成关联过程之前收到了 "class 3" 帧（数据帧）。

无线常见问题

设置

为什么我无法用 Apple Mac 设备连接到 MikroTik 802.11n AP？

此问题只在基于 Broadcom 无线芯片组的 Mac 设备上出现。为了用此类无线设备连接到 MikroTik 802.11n AP，请确保不要使用 'short' preamble-mode。使用 'long' 或 'both' preamble-mode，Mac 无线设备就能连接。

更改某些无线设置后，无线链路变得不稳定。

有时当你更改某些无线设置来调优链路时，会弄到链路不再建立或工作不稳定，而你也记不清最初的设置是什么。在这种情况下，你可以使用无线菜单中的 reset-configuration 命令 - 它将重置特定无线接口的所有无线设置，你将能够从头开始配置该接口。注意，执行此命令还会禁用该接口，因此如果你正在通过想要重置其配置的那条无线链路远程配置路由器，请务必小心不要执行此命令。

什么是无线重传，在哪里查看？

无线重传发生在接口发出一个帧但未收到确认（ACK）时，导致它再次尝试发送该帧，直到收到确认或达到数据包允许的最大重传次数。无线重传会增加延迟并降低无线链路的吞吐量。发生的重传次数可以通过用注册表中给定条目的 hw-frames 参数值减去 frames 参数值来确定。发生一定数量的重传是正常的，但如果 hw-frames 的值多次超过 frames 的值，则说明无线链路存在问题，需要排查。

在 Nstreme 链路上我也可以比较 frames 与 hw-frames 吗？

frames 只统计包含实际数据的帧。在 Nstreme 的情况下，如果没有其他数据要发送，单个帧中可以只传输 ACK。这些 ACK 帧不会被计入 frames 计数，但它们会出现在 hw-frames 中。如果两个方向都以最高速度有流量（例如不会有仅 ACK 的帧），那么你就不能像在常规无线链路中那样比较 frames 与 hw-frames。

我可以使用哪些 TX-power 值？

tx-power 默认设置是网卡可以使用的最大 tx-power，取自网卡的 eeprom。如果你想使用更大的 tx-power 值，你可以设置它们，但风险自负，因为这最终很可能会损坏你的网卡！通常，此参数只应用于降低 tx-power。

一般来说，tx-power 控制属性应保留为默认设置。更改默认设置在某些情况下可能对某些网卡有帮助，但在未经测试的情况下，最常见的结果是范围和吞吐量下降。可能发生的一些问题有：

• 功率放大器芯片过热，网卡会导致效率降低和更多数据错误；
• 过驱动放大器会导致更多数据错误；
• 网卡功率消耗过大可能会使网卡所在主板的 3.3V 电源过载，导致电压下降并重启，或主板温度过高。

哪种 TX-power-mode 最好？

TX-power-mode 告诉无线网卡应使用哪些 tx-power 值。默认情况下，此设置被设为 default。

• default 表示网卡将使用网卡 eeprom 中的 tx-power 值，并忽略用户在 tx-power 字段中指定的设置。
• card-rates 表示对于不同的数据速率，tx-power 根据网卡 eeprom 中的发射功率算法计算，并以用户指定的 tx-power 值作为参数。
• all-rates-fixed 表示网卡将对所有数据速率使用用户在 tx-power 字段中指定的同一个 tx-power 值。

注意，不建议使用 'all-rates-fixed' 模式，因为无线网卡对较高数据速率的 tx-power 较低，对较高数据速率强制使用固定的 tx-power 速率可能会导致与上一个关于 tx-power 设置的问题中相同的问题。对于 MikroTik Radio 设备，功率不会高于 EEPROM 中写入的功率。在大多数情况下，如果你想更改 tx-power 设置，建议使用 tx-power-mode=card-rates，并且建议降低而非提高 tx-power。对于 AR9300 及更新的 Atheros 无线芯片组，"tx-power-mode=all-rates-fixed" 是唯一选项，因为 "card-rates" 选项在这些芯片组上无法工作。

什么是 CCQ，这些值是如何确定的？

Client Connection Quality（客户端连接质量，CCQ）是一个以百分比表示的值，显示相对于理论最大可用带宽，带宽被有效利用的程度。CCQ 是对每个已发送帧计算出的 Tmin/Treal 值的加权平均值，其中 Tmin 是以最高速率、无重传发送给定帧所需的时间，Treal 是实际发送该帧所花费的时间（考虑到发送该帧所需的必要重传和发送速率）。

什么是 hw-retries 设置？

在不算作传输失败的情况下重试发送一个帧的次数。失败时数据速率会降低，并再次发送该帧。在最低支持速率上连续三次失败后，会在 on-fail-retry-time 期间暂停向该目标发送。之后，再次发送该帧。该帧会一直被重传，直到传输成功，或者直到客户端在 disconnect-timeout 之后断开连接。在此期间，如果超过 frame-lifetime，该帧可能被丢弃。在 Nstreme 的情况下，不使用 "on-fail-retry-time"、"disconnect-timeout" 和 "frame-lifetime" 设置。因此，在最低支持速率上连续三次失败后，无线链路会断开并显示 "extensive data loss" 消息。

什么是 disconnect-timeout 设置？

此间隔从最低数据速率上的第三次发送失败开始计算。此时，最低数据速率上已有 3 * (hw-retries + 1) 次帧传输失败。在 disconnect-timeout 期间，将以 on-fail-retry-time 间隔重试数据包传输。如果在 disconnect-timeout 期间没有任何帧能成功传输，则连接被关闭，此事件被记录为 "extensive data loss"。成功传输帧会重置此计时器。

什么是 adaptive-noise-immunity 设置？

Adaptive Noise Immunity（自适应抗噪，ANI）动态调整各种接收器参数，以尽量减少干扰和噪声对信号质量的影响。此设置被添加到针对 Atheros AR5212 及更新芯片组网卡的无线驱动中。

当使用 access-list 或 connect-list 时，无线设备如何测量信号强度？

报告的信号电平是指数加权的移动平均值，平滑因子为 50%。

RouterOS 无线支持哪些纠错方法？

nstreme 协议支持 ARQ 方法。常规 802.11 标准不包括 ARQ - 损坏帧的重传基于确认协议。RouterOS 支持前向纠错编码（卷积编码），编码率为：1/2、2/3 或 3/4。

为 160MHz 使用配置 RouterOS 设备。

如果 RouterOS 设备支持 4x4 传输，除了设置 160MHz 信道宽度外，还请确保在无线接口上设置 "rate-set=default"，以便所有流都可用

如果客户端不支持 Extended NSS 并且只能进行 2x2 传输，请设置 "vht-supported-mcs=mcs0-9,mcs0-9,none"。

配置方案

放大器能提高我链路的速率吗？

这取决于你的信号质量和噪声。请记住，使用低输出功率设置和良好的天线，你很可能获得更好的链路。放大器会增加噪声，只会给链路带来问题。

放大器会同时放大发射和接收的信号。因此，在"安静"区域，即你独自一人或只有很少"噪声"或"竞争"的地方，你可能会获得极好的结果。另一方面，在拥挤的区域，存在大量无线活动时，你也会放大从其他每个竞争者或噪声源接收到的信号，这可能会大幅降低链路的整体质量。另外，还要考虑 EIRP，以确认你的链路保持在合法范围内。

你还可以在 "11b only" 无线电上获得更好的信号，这些无线电将大部分 802.11g 视为"噪声"，从而更好地过滤可用信号。

如何使用 hw-retries 微调无线链路？

你应该明白，对于 802.11 设备，设备可用于调整其行为的信息（或来自环境的"反馈"）非常有限：

• 信号强度，可用于在已知接收器灵敏度的情况下推算出最佳发射速率。但仍然不可靠，因为不同接收器的灵敏度会变化（例如随时间变化）、路径条件不对称（而且设备只能测量它接收到的信号强度）等。
• 通过接收/未接收到已发送帧的确认。

考虑到使用信号强度不可靠，802.11 设备实际上只剩一个"反馈"来调整其操作 - 传输的成功/失败。当传输失败时（未及时收到 ACK），发送方无法推算出失败的原因 - 无论是由于噪声、多径、直接干扰（以及它干扰的是实际数据帧还是 ACK 本身）- 该帧就是没能送达，一般来说"为什么"并不重要。重要的只是数据包错误率。

因此，RouterOS 实现了一种算法，仅利用这些有限的信息，尝试在任何环境中最高效地使用介质，同时让用户能够控制该算法的工作方式并对其加以描述。而且只有少数几条使用准则，而非在特定情况下应使用的一组固定值。

一般来说 - hw-retries 越大，设备获得的关于介质以特定速率传递帧的能力的"反馈"就越好（例如，如果以 54mbps 速率发送帧失败了 16 次，这比失败 2 次重传更能说明问题），也越能推算出最佳发射速率，代价是可能在网络中引入延迟 - 因为在所有这些失败的重传期间，此信道中的其他设备无法发送。因此，对于 ptp 骨干链路（已知链路必须始终在线），可以建议使用更大的 hw-retries。更小的 hw-retries 使速率选择适应得更快，但会牺牲一些准确性（在大多数情况下低于 2 是不合理的），这可以建议用于 ptmp 链路，在这种链路中连接/断开是正常的，并且保持低延迟很重要。

on-fail-retry-time 和 disconnect-timeout 控制设备将多努力地认为对端仍然"已连接"。更大的 disconnect-timeout 将使设备即使以最小可能传输速率存在大量丢失时也不"断开"对端。这同样对已知"必须"建立的"弱"链路（例如骨干链路）最有用。在 ptmp 网络中，较大的 disconnect-timeout 又会增加网络中的延迟，例如在这段时间内 AP 会尝试向某个刚刚被禁用的客户端发送数据（AP 会在整个 disconnect-timeout 期间尝试这样做）。

frame-lifetime 允许调节 AP 在认为某帧不值得投递之前，会尝试用它进行传输多长时间（例如，如果以最低可能速率发送帧失败，则启用 on-fail-retry-time 计时器。如果在此期间 frame-lifetime 到期，该特定帧被丢弃，下一次传输尝试将使用下一个帧。禁用 frame-lifetime 意味着无线将确保"所有"数据帧按序投递，无论需要多长时间，"或者"在一切都失败时断开连接）。这允许针对不同类型的流量进行优化，例如，对于实时流量 - 如果无线网络的主要用途是 voip，那么限制 frame-lifetime 可能是合理的，因为 voip 更能容忍小量丢失，而不能容忍高延迟。

是否可能只用一个无线电接口就使用无线中继器？

通过在以 ap-bridge 模式运行的无线接口上使用 WDS，这种配置是可能的。在较新的 RouterOS 版本中，还可以配置无线中继器模式。

Nv2 无线链路频繁断开连接。

当 Nv2 无线链路频繁出现断开连接，并且日志部分中大部分消息都是 'control frame timeout' 时，如果链路信号很强，你可以尝试降低无线网卡的发射输出功率。我们建议使用 tx-power-mode=card-rates 来降低无线网卡的 tx-power。如果问题持续存在，请尝试使用可能干扰更小的不同无线频率。如果这也没有帮助，请附上受影响 AP 和 Station 在这些断开连接之后生成的支持输出文件，联系 support@mikrotik.com。