无线调试日志

使用日志调试无线问题。

缺省情况下，RouterOS的无线日志以简单的表项显示客户端连接和断开:

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

对于普通用户来说，知道MAC地址为“00:80:48:41:AF:2A”的无线客户端连接到无线接口“wlan1”就足够了。但实际上，可用的日志条目比标准日志记录中显示的要多。它们被称为“调试”日志，提供更详细的信息。在下面的调试日志示例中，您将看到连接到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

调试日志将为您提供有关客户端无线连接和断开连接的每个步骤的更具体的信息。第一行显示无线客户端试图连接到AP。在第二行中，AP检查是否允许该客户端连接到AP以及由此产生的操作。只有在第三行才能看到客户端已连接。这仅仅是调试日志消息的一个示例。所有调试项的描述如下所示。

要启用无线调试日志，应该执行以下命令:

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

这帮助您轻松地理解和解决无线问题，并减少与支持团队的交互。

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报文完整性检查失败，一定是有人试图闯入或DOS网络，如果60秒内遇到1个以上的MIC失败，则进入“TKIP对抗”状态。

<MAC>@<DEV>: enter TKIP countermeasures

进入TKIP对抗状态，即站将断开与AP的连接，并保持60秒的沉默。

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

从mac地址<mac>的未知设备(已读-未注册到本AP)收到数据帧，AP向其发送去认证帧(根据802.11)。XXX是不记录的事件数，这样日志就不会变得太大(前5条日志限制为每5秒1条)，YYY是应该发送但没有发送的去认证帧数，这样就不会浪费资源发送太多的去认证帧(每秒只允许发送10个死亡帧)。

这种消息的可能原因是先前连接到AP的站点还不知道它已经从AP注册表中删除，因此向AP发送数据。去认证消息告诉站点它不再连接。

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

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

<DEV>: <MAC> is new WDS master

WDS从服务器已经与WDS主服务器建立了连接，这意味着WDS从服务器开始接受客户端并充当AP。

<DEV>: <MAC> was WDS master

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

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

地址<MAC>已连接的站点。如果“is AP”存在-远端设备是AP，如果“is WDS”存在，远端设备要建立WDS链路。

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

Connection with Station with address <MAC> terminated due to <REASON>

<DEV>: TKIP countermeasures over, resuming

TKIP对抗(60s沉默期)结束，AP恢复AP身份。

<DEV>: starting TKIP countermeasures

进入TKIP对抗状态(60s沉默期)，所有客户端丢失。

<REASON>

joining failed -只能发生在站模式的Prism卡上，由于某种原因无法连接AP

join timeout -发生在站点上，未能同步到AP(接收第一个信标帧)。最有可能的是信号弱，远程关闭，强干扰，其他一些射频相关的问题，使通信无法进行。

no beacons -没有从WDS链路的远端收到信标。最有可能的是信号弱，远程关闭，强干扰，其他一些射频相关的问题，使通信无法进行。

extensive data loss -本地接口决定放弃与远程设备的连接，因为无法以尽可能低的速率在多次失败后向远程发送数据。可能的原因-信号太弱，远程设备关闭，强干扰，其他一些射频相关问题，使通信无法进行。

decided to deauthenticate， <802.11 reason> -本地接口决定使用802.11 reason <802.11 reason>去认证远端设备。

inactivity -远程设备不活动的时间太长

device disabled -本地接口被禁用

got deauth, <802.11 reason> - 收到来自远程设备的deauthentication帧，802.11原因代码在<802.11原因>中报告。

got disassoc, <802.11 reason> - 收到来自远程设备的disassociation帧，802.11原因代码在<802.11原因>中报告。

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

bad ssid - WDS链路的ssid不好。

beacon from non AP - 收到来自已知为非AP节点的远程设备的信标帧，最可能是远程设备从站到AP的模式改变。

no WDS support - 没有报告WDS支持。

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

hardware failure - 一些硬件故障或意外行为。不太可能被看到。

lost connection -只能发生在站台模式的棱镜卡上，由于某种原因失去与AP的连接。

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

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

auth timeout - 发生在站台上，站台没有收到对认证帧的响应，要么是链接不良，要么是AP由于某种原因忽略了这个站台。

assoc timeout -发生在站上，站没有收到对关联帧的响应，要么是链路坏了，要么是AP出于某种原因忽略了这个站。

reassociating - 发生在AP上：连接被认为是丢失的，因为被认为已经关联的站试图再次关联。所有与连接有关的信息必须被删除，因为在关联过程中，连接参数被协商（因此 "断开"）。站台重新关联的原因必须在站台上寻找（最可能的原因是站台由于某种原因在没有告诉AP的情况下放弃了连接–例如数据丢失，配置改变）。

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

control frame timeout - AP无法向客户端传输（类似于你在802.11协议中看到的错误信息–大量数据丢失）。

<802.11 reason>和<802.11 status>

这些是编码到802.11管理消息中的数字原因/状态码。日志消息包括来自802.11标准组中适当标准的数字代码和文本描述。虽然这些都是为了尽可能地描述，但必须考虑到管理帧中出现的实际原因/状态码仅取决于设备或软件制造商-其中一台设备发送的802.11管理帧包括导致该帧的情况的适当原因/状态码，其他设备可能发送带有“未指定”原因/状态码的帧。因此，原因/状态代码只应被视为信息。

随着802.11标准的发展，RouterOS可能会错过某些设备使用的原因/状态码的文本描述。在这种情况下，应该使用数值来查找802.11标准中的含义。

为了正确地解释原因/状态码，有必要对802.11组标准有很好的理解。大部分的文字描述都是不言自明的。下面是一些最常见的原因/状态码的解释。

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

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

Wireless FAQ

设置

为什么我不能用苹果Mac设备连接到microtik 802.11n AP ?

这个问题只出现在基于Broadcom无线芯片组的Mac设备上。为了将这种无线设备连接到microtik 802.11n AP，请确保您不使用“短”前导模式。使用“long”或“both”前导模式，Mac无线设备就可以连接。

通过更改一些无线设置，无线链路工作不稳定

有时，当你改变一些无线设置来调整链接时，到目前为止，你得到的链接不再建立或工作不稳定，你不记得你一开始有什么设置。在这种情况下，您可以使用无线菜单中的reset-configuration命令-它将重置特定无线接口的所有无线设置，并且您将能够从头配置接口。注意，执行此命令也会禁用接口，所以如果您正在使用想要重置配置的无线链路远程配置路由器，请小心不要执行此命令。

什么是无线重传，在哪里检查?

无线重传发生在接口发送帧而没有收到确认(ACK)时，导致它再次尝试发送帧，直到收到确认或达到数据包允许的最大重传计数。无线重传增加了延迟，降低了无线链路的吞吐量。重传的数量可以通过从注册表中给定条目的hw-frames 参数中减去frames参数的值来确定。预计会有一些重传次数，但如果 frames 的值超过 frames 的值多次，则说明无线链路存在问题，需要进行故障排除

我可以在nstream链接中比较帧与hw帧?

帧只计算包含实际数据的帧。在nstream的情况下，如果没有其他数据要发送，只有ACK可以在单个帧中传输。这些ACK帧不会被添加到帧数中，但它们会出现在帧数中。如果两个方向上都有以最高速度行驶的车辆(例如。不会有只ack帧)，那么你就不能像在普通无线链路的情况下那样比较帧和hw帧。

我可以使用哪些tx功率值?

x-power默认设置是卡可以使用的最大x-power，并从卡的eeprom中获取。如果你想使用更大的x功率值，你可以设置它们，但这样做你自己承担风险，因为它最终可能会损坏你的卡!通常情况下，使用该参数只是为了减少x-power。

一般来说，x-power控制属性应该保持默认设置。在某些情况下，更改默认设置可能对某些卡有所帮助，但如果不进行测试，最常见的结果是范围和吞吐量的降低。可能出现的一些问题是:

-功放芯片和卡过热，导致效率降低和数据错误增多; 放大器过度驱动会导致更多的数据错误 -卡的电力使用过多，这可能会导致卡所在板的3.3V电源过载，导致电压下降和重新启动或板温度过高。

哪种tx -power模式是最好的?

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

  • default 表示卡将使用卡eeprom中的tx-power值，并且将忽略用户在_tx-power_字段中指定的设置。

  • card-rates 表示对于不同的数据速率，x功率根据卡的传输功率算法从卡的eeprom计算，并采用用户指定的tx-power值作为参数。

  • all-rates-fixed 表示该卡将使用一个tx-power值为所有数据速率，由用户在tx-power字段中指定。

请注意，不建议使用“全速率固定”模式，因为较高数据速率的无线网卡功率较低，并且强制对较高数据速率也使用固定功率速率可能会导致与前面关于功率设置的问题相同的问题。在microtik Radio设备的情况下，功率不会高于写入EEPROM的功率。在大多数情况下，如果您想要更改tx-power设置，建议使用tx-power-mode=card-rates，并且建议降低而不是提高tx-power。在AR9300和更新的Atheros无线芯片组的情况下，“tx-power-mode=all-rate-fixed”是唯一的选项，因为“卡速率”选项在这些芯片组上不起作用。

什么是CCQ ?如何确定CCQ的值?

客户端连接质量(CCQ)是一个以百分比为单位的值，它显示了相对于理论上最大可用带宽，带宽的使用效率。CCQ是对每个传输帧计算的Tmin/Treal值的加权平均值，其中Tmin是以最高速率传输给定帧而不重试所需的时间，而Treal是在实际生活中传输帧所需的时间(考虑到传输帧和传输速率所需的必要重试)。

hw-retries设置是什么?

重试发送帧而不认为传输失败的次数。失败时降低数据速率，重新发送帧。以最低支持速率连续发生三次故障，将暂停到该目的地的传输，持续时间为on-fail-retry-time。之后，再次发送帧。帧被重传，直到传输成功，或者直到客户端在disconnect-timeout之后断开连接。在此期间，如果超过了frame-lifetime，帧将被丢弃。在nstream“on-fail-retry-time”的情况下，“disconnect-timeout”和“frame-lifetime”设置不会被使用。因此，在最低支持速率连续三次失败后，无线链路将断开，并伴有“大量数据丢失”消息。

什么是断开连接超时设置?

这个时间间隔是从最低数据速率的第三次发送失败开始测量的。此时，以最低数据速率传输的3 * (hw-retries + 1)帧失败。在_disconnect-timeout_期间，将以on-fail-retry-time 间隔重新尝试数据包传输。如果在_disconnect-timeout_期间没有帧可以成功传输，则连接关闭，此事件记录为“大量数据丢失”。成功的帧传输重置该定时器。

什么是自适应抗噪设置?

自适应抗扰度(ANI)是一种动态调节各种接收机参数以减小干扰和噪声对信号质量的影响的技术。此设置添加在Atheros AR5212和更新的芯片组卡的无线驱动程序中

当使用接入列表或连接列表时，无线设备如何测量信号强度？

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

RouterOS无线支持哪些纠错方式?

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

配置160MHz使用的RouterOS设备

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

如果客户端不支持扩展NSS，只能进行2x2传输，则设置“vht-supported-mcs= mc50 -9, mc50 -9,none”。

设置

放大器会提高我的链接速度吗?

这取决于你的信号质量和噪声。记住，你可能会得到一个更好的链接与低输出功率设置，和一个好的天线。放大器增加了噪声，只会引起链路问题。

放大器在发射信号和接收信号上都得到增强。因此，在“安静”的地方，你独自一人或很少有“噪音”或“竞争”，你可能会得到很好的结果。另一方面，在拥挤的地区，有很多无线活动，你也会增加从其他竞争对手或噪声源接收到的信号，这可能会大大降低链路的整体质量。此外，考虑EIRP，看看你的链接是否仍在法律限制之内。

你也可以在“11b”无线电上获得更好的信号，它将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，那么限制帧寿命_是合理的，因为voip比高延迟更能容忍小的损失。

无线中继器是否可以只使用一个无线电接口?

这种设置可以通过在以ap桥接模式运行的无线接口上使用WDS来实现。在较新的RouterOS版本中，可以配置无线中继器模式。

Nv2无线链路经常断开

当Nv2无线链路断开时，在日志部分大部分消息是“控制帧超时”，如果链路信号较强，可以尝试降低无线网卡的发送输出功率。我们建议使用x-power-mode=card-rates来降低无线网卡的x-power。如果问题仍然存在，请尝试使用干扰较少的其他无线频率。如果这也没有帮助，请联系 support@mikrotik.com，并从受影响的AP和工作站获得支持输出文件，这些文件是在断开连接后制作的。