本文介绍了 UniFi 接入点（UAP）间歇性连接问题的一系列提示和故障排除步骤。这可能表现为显示满格 WiFi 信号的笔记本电脑或手机，但无法加载或一直显示正在加载。继续阅读本文查看其他症状。
注意事项及要求:
- 本文仅关注无线问题，而不是有线问题。
- 最新的固件版本解决了绝大多数问题，所以在进一步排查之前，请您先升级您的 UAP 固件。
简介
最常见的间歇性连接症状是笔记本电脑或手机显示满格 WiFi 信号，但在使用网络服务/浏览器时，网页无法加载，网络服务无法使用。浏览器有时会显示无 Internet 连接，或者会一直卡在加载界面。有时，WiFi 栏会出现感叹号，有时客户端设备会为 LAN 上的 IP 地址选择自动分配的 IP（例如 169.254.xx）。
在最新的 UAP 固件版本中已修复了许多此类问题，因此在进一步调查之前，请确保您使用的是设备的最新固件版本。有关如何更新设备固件的信息，请参阅 此文章 。 本文提供了调试和修复这些类型问题的建议，以实现顺畅的网络体验。
有线还是无线？
首先，重要的是确定问题是存在于网络的有线或无线基础设施中。尝试从笔记本电脑上的两个终端同时连续 ping 一个可达的公网地址（例如 *** ）和您的网关。如果两个 IP 都有丢包，那么您可能会遇到无线问题。如果只有 ping 公网丢包，那么您可能遇到有线/互联网问题。本文仅关注解决无线问题，而不是解决有线问题。
请注意，许多笔记本电脑在其 WiFi 接口上启用 WiFi 省电模式，无论笔记本电脑是否正在充电，您可能会看到 ping 响应最多延迟 1.25 秒，尤其是当笔记本电脑处于空闲状态时。这是笔记本电脑制造商为节省电力而设计的，本文将特别关注解决包丢失问题，而不是包延迟问题。
检查您的配置
以下 AP 网络配置（如访问点的属性面板上所示）有三个错误。你能发现它们吗？
- 子网掩码太窄，无法提供到网关的路由。
- 网关本身与静态 IP 地址不在同一子网中。
- 没有配置首选 DNS。
配置错误可能导致无法升级 UAP，NTP 同步失败以及许多其他难以诊断的间歇性问题。为了获得最佳体验，确保所有 UAP 本身能够正常访问互联网，包括 DNS 和 Internet 访问。
靠近 AP
尝试靠近客户端所连接的 UAP，以验证问题是否消失。如果问题得到解决，那么您可能需要重新规划 UAP 部署的位置和数量。
网络环路
通过运行 tcpdump 在相关 UAP 和/或 UniFi 交换机上抓取数据，通过 Wireshark 等工具中查看分析，可以轻松检测网络环路。按照以下步骤执行此操作：
1. SSH 到出现问题的 UAP 上 ，并输入以下命令：
tcpdump -i br0 -n -v -s 0 -w /tmp/capture.pcap
2.然后将生成的 pcap 文件复制到笔记本电脑，以便在 Wireshark 中查看。
scp admin@192.168.1.X:/tmp/capture.pcap /tmp
此操作会将 capture.pcap 复制到计算机上的 /tmp 目录下。如果是 Windows 系统，您可以使用 winscp。
3. 在 Wireshark 中打开文件。
如果某处存在网络环路，您将在捕获文件中看到大量的多播或广播流量。典型网络的组播/广播流量小于 100 kbps，每秒总共只有几十个数据包。如果每秒有数千个多播/广播数据包，那么您可能在某个地方需要解析网络环路。保持断开基础设施设备的连接，直到多播/广播数据包的数量下降到合理的数量。
链路预算
UniFi AP 的高发射功率（TX 功率）适合仅安装单个 AP 的场景，但在多 AP 部署环境中可能存在问题。高发射功率仅能够扩展覆盖范围范围，并不能提高传输效率，因为较高的传输效率是在较低的发射功率下进行的，这对所有厂商的 AP 和终端来说都一样 。在多 AP 部署的情况下，高发射功率会占用更多空口时间，从而减慢整个网络的速率，并可能导致较高的丢包率。
高发射功率还导致移动终端和 UAP 之间的 WiFi 链路预算的不平衡，因为大多数移动终端只有 14 到 18dBm 之间的发射功率。 即使从移动终端到 AP 的信号不够强， 只要在该 AP 的覆盖范围内，移动终端也会一直保持连接在该 AP 上，甚至显示满格 WiFi 信号。
将 UAP 上的发射功率降低到 18 dBm 左右可为大多数终端和部署建立更加对称的链路。这可以在 Controller UI 中轻松完成。
禁用功能
某些功能（如频段引导，最小 RSSI 和连通性监测）如果配置错误或 AP 数量不足，可能会产生不利影响。在调试连接性问题时最好禁用所有这些功能，这样可以在没有任何额外变量的情况下验证基本功能。AirTime 等功能也可以被禁用，以将基本功能降至最低。
DHCP 配置
一些较旧或配置错误的路由器和 DHCP 服务器将 DHCP offer / ack 消息作为广播数据包传输，很可能被丢弃。这可能导致连接时间变慢和间歇性连接。请确保您的 DHCP offer 和 ack 消息是单播数据包，而不是广播（来自终端的 Discovery 数据包仍然可以广播）。
修改 DTIM 周期
默认 DTIM 周期为 1 用于兼容性和遗留原因。然而，许多现代设备（包括最近的 iOS 和 Android 手机）如果周期设置为 3，将表现更好并节省高达 66％ 的 WiFi 电池消耗。对于几乎所有现代设备的网络，建议使用 DTIM 周期 3 代替。
Wireshark – 数据包捕获
可以在 *** 上下载大多数平台的 Wireshark 。建议使用现代（2013+）MacBook，因为它们1）具有监控模式的完全驱动程序支持，以及 2）具有能够听到 3 个 NSS 流量（高达 1300 Mbps 物理速率）的高级 3×3 空间流。Linux 也可以用于某些笔记本电脑，但大多数笔记本电脑仅支持 2×2 空间流，因此它们不太有用。
- 下载/安装 Wireshark。
- 打开 Wireshark。
- 单击顶部的齿轮图标。
- 确保为 en0 接口启用了监控模式：
- 单击“关闭”，然后重新启动 Wireshark。
- 在 en0 上开始捕获。您应该看到散布着数据帧的信标，控制和管理框架。
您可以将此捕获上传到社区或UBNT支持，并确保包含有问题的笔记本电脑或移动设备的MAC地址。
通过网络跟踪数据包
在某些情况下，多播/广播数据包可以成功，而单播数据包则不成功。重要的是要了解 哪种类型 的数据包在网络上走了 多远 。您需要先确定无线客户端连接的“VAP”接口。
您可以搜索有问题的 AP 并发出：
iwconfig
在上面的示例中，您可以看到 ath6 是 5 GHz 无线电上 ubnt-ut-AP-LR 网络的 VAP。
确定广播包是否到达 UAP
1.要查看广播数据包是否正在进入 UAP，请在 UAP 上的 athX 接口上运行 tcpdump（UAP 上的 SSH）：
tcpdump -i athX -n -v -s 0 -w /tmp/broadcast.pcap
2.在笔记本电脑（笔记本电脑上的终端）使用 ping 发送一些广播数据包：
ping 192.168.1.255
3.停止捕获，并启动另一个名为 /tmp/unicast.pcap 的捕获（UAP 上的 ssh）：
tcpdump -i athX -n -v -s 0 -w /tmp/unicast.pcap
4.接下来，尝试将单播数据包发送到路由器（笔记本电脑上的终端）：
ping 192.168.1.1 （替换成您路由器的 IP）
5.如果没有传输或接收广播数据包，那么单播数据包也不会停止（由于操作系统中缺少 ARP 条目），你需要强制静态 ARP 进入你的笔记本电脑（笔记本电脑上的终端）：
sudo arp -s 192.168.1.1 00:00:00:00:00:01 ifscope en0（Mac OS 命令行）arp -s 192.168.1.1 00-00-00-00-00-01（Windows 命令行）
6.再次尝试 ping，查看 00:00:00:00:00:01 单播数据包是否到达 UAP 上的 athX 接口。
确定 UAP 中的数据包是否正发往客户端
在确定从客户端到 UAP 是否有丢包之后，现在是时候确定 UAP 是否有丢包到您的客户端。
1.首先，您需要在笔记本电脑上启动 Wireshark 或 tcpdump，以验证数据包是否到达您的笔记本电脑。
2.然后从 UAP 开始向网络广播 ping（UAP 上的 ssh）：
ping 192.168.1.255
3.在 wireshark/tcpdump 中捕获结果，然后开始 ping 你的笔记本电脑（在 UAP 上 ssh）：
ping 192.168.1.X
4.在编写本文时，UAP 没有办法设置静态 ARP 条目，因此如果无法从 UAP 生成单播流量，您可以尝试通过在有线终端上设置静态 ARP 条目来生成数据包，然后从该单独的设备发送数据包。
您可以将捕获结果提供给社区或 UBNT 员工，以帮助您诊断数据包丢失的位置。
5.最后，仔细检查网桥配置是否正确（UAP 上的 ssh）：
brctl show
输出应该类似于：
AP是否重启
检查 AP 的正常运行时间，确保它们没有重启。可以通过单击 “设备” 部分中的 UAP 并查看“属性”面板的“详细信息”>“概述”部分来检查正常运行时间 。如果“设备”部分位于列表视图中，则在“正常运行时间”列中。如果正常运行时间不断重置，并且与网络故障时间一致，那么您可能已经发现了一个错误，我们很想知道如何在我们的实验室中重现问题。通过我们的 社区 告诉我们。
检查您的硬件
硬件损坏的可能性很小，因为 UAP 从我们的工厂到你的办公桌经手了很多人。对于无法解决重大数据包丢失的情况，无论您尝试使用哪种固件，请继续阅读。
最好将 2GHz 和 5GHz 射频设置在单独的 SSID 上，甚至更好地将它们设置为来自所有其他 UAP 的不同 SSID，以进行测试。例如，如果您的网络名称是“HomeNetwork”，请将 2GHz SSID 设置为“HomeNetwork-test2”，将 5GHz SSID 设置为“HomeNetwork-test5”，以便它们不会相互冲突或与任何其他 SSID 冲突。如果每个射频有多个 SSID，则只需要在每个射频上测试 一个 SSID，因此您只需要修改每个频段的 一个 SSID，而不是所有频段。
1.按顺序获取 SSID 后，请通过 SSH 进入，并在您的 UAP 上发出以下命令：
iwpriv wifi0 get_txchainmask
这将为您提供射频 0 上可用的链数。这是一个掩码，因此 3 表示您有 2 个链，5 表示您有 2 个链，7 表示您有 3 个链，15 表示 4 个链等。
2.再次为 UAP 上的第二个射频运行命令（如果您的 UAP 是双频）：
iwpriv wifi1 get_txchainmask
3.现在我们测试 UAP 上的每个链。测试链 0：
cm=1; for a in 0 1; do for b in tx rx; do iwpriv wifi$a ${b}chainmask $cm; done; done; killall hostapd
4.使用 WiFi 分析仪或其他应用程序查看 2 GHz 和 5 GHz 的 0 链上 UAP 信标的信号强度。你应该站在离 UAP 3 米的范围内，如果信号强度低于 -60 dBm，该链可能有问题。
5.测试其他链：
cm=2; for a in 0 1; do for b in tx rx; do iwpriv wifi$a ${b}chainmask $cm; done; done; killall hostapd
6.查看链 1 上的信号强度。然后：
cm=4; for a in 0 1; do for b in tx rx; do iwpriv wifi$a ${b}chainmask $cm; done; done; killall hostapd
请记住，cm = 1,2 和 4 对应于链 0,1 和 2，如果您的 UAP 没有链 2，那么您将看不到该链上的任何信号（这是正常的！）
7.接下来，重新启动 UAP 以使链恢复正常。在 UAP 3 米范围内连接一台已知良好的笔记本电脑。使用以下命令在有线服务器（Linux，Mac，Windows 皆可）上运行 iperf3：
iperf3 -s
8.然后从 WiFi 连接的笔记本电脑/移动设备上运行 iperf3：
iperf3 -u -c SERVER_IP -b 50M -R
9.在相反方向上再次测试。
iperf3 -u -c SERVER_IP -b 50M
10.硬件损坏通常是在一个方向上的吞吐量远低于另一个方向（即一个方向为 50 Mbit，另一个方向为 0 Mbit）。如果是这种情况，请在论坛中向 UBNT 员工进行确认和后续步骤。
求助社区
如果所有其他方法都失败了，请随时向社区或 UBNT 工程师求助，注意附上您的配置等信息。请确保您已按照本指南中的相关步骤进行操作，并确保包含诸如是否启用了频段引导，最小 RSSI，ATF，VLAN 等的详细信息。如果您的问题得到解决，请确保将主题标记为已解决！
声明：本网页内容旨在传播知识，若有侵权等问题请及时与本网联系，我们将在第一时间删除处理。E-MAIL:dandanxi6@qq.com
