[参考译文] CC3301：WiFi 固件偶尔会丢弃数据包、导致 TCP 传输速度降至 0（R6 版本）

尊敬的 Yuan：

您能解释一下这里的设置吗？ 您使用的是哪种 CC33xx SDK？ CC33xx 是 iperf3 服务器还是客户端？ 它处于 AP 模式还是连接到外部 AP？

版本 6 SDK。  CC33xx 处于工作站模式。 我们的客户报告了此问题、然后他们在 CC33xx 中作为服务器运行 iperf3。  

在我的测试中、我以客户端身份在 CC33xx 中运行 iperf3、有时我也会重现此问题。

尊敬的 Yuan：

好的。 仅出于我的理解、您是在 R6 SDK 之上实现了 iperf、还是使用了任何特定的示例？ 您能提供我们重现的示例方法吗？

你好、Sabeeh

我们没有直接使用 R6 SDK 来测试此问题。 相反、我们将 Wi-Fi 驱动程序从 R6 SDK 移植到使用 SDIO 接口的 RTOS 平台。 我们使用 R6 SDK 中的 Wi-Fi 驱动程序在我们的平台上运行 iperf3 来测试此问题。 也许您可以在使用 R6 SDK 的平台上重现此问题、或者我们可以向您提供测试数据。

尊敬的 Yuan：

我们的固件中有许多修复程序可以解决此类问题。 但是、它们尚未在 ThickMAC 解决方案中进行更新。 让我看看我能做些什么,我很快就会报告。  

你好、Sabeeh

是否有任何更新？  我们的客户对此问题非常焦虑。

你好、Sabeeh

我们发现了一种似乎可以解决 此问题的方法。  方法是更改 WiFi 芯片的节能模式。 最初设置为“auto"，“，将、将其更改为“active"会“会使问题消失。 因此、节能模式是否是导致该问题的根本原因？ “自动“模式是否会对 TCP 流量产生如此大的影响？ 切换到“活动“模式可能会出现哪些潜在问题？

尊敬的 Yuan：

我们没有在 R6 SDK 上实现 iperf3、因此无法重现此问题。 您是否愿意提供 iperf3 的实现、以便我可以在硬件上运行？ 我可以更好地重现这个问题。

使用有功功率模式没有问题、器件可能具有更高的功耗。 该问题可能与使用省电模式有关、但我们需要进一步调查此问题以确认。  

你好、Sabeeh

iperf3 不是必需的、iperf 也可以执行此测试。
 在我们的进一步测试中、将省电模式设置为活动状态只能缓解该问题。 如果器件 保持 连接 且一段时间内没有数据传输、则下次开始数据传输时、速率仍将降至 0。 另一个问题是 WLAN_SET_POWER_SAVE 和 WLAN_SET_POWER_MANAGEMENT 都用于配置省电模式。 这两个参数之间的区别是什么？应如何设置它们以确保 Wi-Fi 持续处于活动模式？

尊敬的 Yuan：

WLAN_SET_POWER_SAVE 是您感兴趣的命令。 启用 802.11 省电模式、这意味着 CC33xx 器件通知 AP 正在进入和退出省电模式。 您可以认为这种节能仅限于射频系统。

WLAN_SET_POWER_MANAGEMENT 控制整个 CC33xx 器件的电源活动、与与与与 AP 的链路无关。  

根据您提供的有关此问题的信息、我认为您需要将“WLAN_SET_POWER_SAVE"设置“设置为“WLAN_STATION_ACTIVE_MODE"。“。  

你好、Sabeeh

关于参数“WLAN_set_POWER_management"，“，建议、建议使用哪种设置？

尊敬的 Yuan：

我不建议更改此参数、因为固件应使用 ELP 模式的默认参数启动。 仅更改“WLAN_SET_POWER_SAVE"。“。  

WLAN_SET_POWER_SAVE 设置为自动时、会发生此问题。 这是否表明自动模式存在错误？ 固件是否需要解决此问题？

尊敬的 Yuan：

是的、听起来像是一个错误、但我们解决了固件中的许多问题、我们需要在 SDK 版本中更新固件、然后再次进行测试。

但是,我们可以尝试理解错误。 您是否能够从 LOGGER 引脚收集固件日志？ 然后、我可以与团队一起查看此问题是否已在内部得到解决。  

Yuan、

只要您能向我们提供 Sabeeh 要求的信息。

此外、我已向您和您的团队发送了一个工程固件、该固件应能改善或修复行为。

如果我们想要了解并解决问题、获取日志至关重要。

您好、  
此固件日志文件、plee2e.ti.com/.../tcp_5F00_throughput.pcapng.txtasecheck it.e2e.ti.com/.../tcp_5F00_throughput_5F00_log.txt

尊敬的 Yuan：

看起来此 iperf3 日志与原始问题有所不同、原始问题的吞吐量达到 0Mbps。 但是、在此日志中、始终会报告一些吞吐量。 您能澄清一下吗？ 这是来自 R6 发行版的原始固件还是与您共享的 Andres 固件？

另外、固件日志似乎也有问题。 您能否只分享从 Wireshark 输出的 pcap 文件？ 我还看到有很多次报告“ropped bytes“。 您能否验证是否使用了正确的 logger.bin 来解析记录器输出？

你好、Sabeeh

我上传了 3 个日志文件、这次我们使用了 FW Andres 共享、并且 logger.bin 也是 Andres 共享。  我无法重现 0Mbps 的吞吐量问题、 但其他人在使用自动省电模式时仍然会重现此问题。 我已有的日志表明问题出在 PC 端、在那里它停止发送数据 1 秒钟。 根本原因是固件端未能及时发送 ACK 数据包达 1 秒。 这种情况经常发生、因此我希望您可以调查此问题。

尊敬的 Sabeeh：

以下是包含 wifi 嗅探器文件的日志文件。 该日志显示了 1 秒数据传输间隔的许多实例。

尊敬的 Sabeeh：

在`test3.7z`中、有一种`为全零的情况、`iperf3`的端口号为`57755`和`57756。 您可以在日志中搜索`57756`以查看相关详细信息。

------------------------------------------------------------------------
服务器[192.168.1.104]正在侦听[5201]
------------------------------------------------------------------------
已从 192.168.1.101 端口 57755 接受连接
[5]本地 192.168.1.104 端口 5201 连接到 192.168.1.101 端口 57756
[ ID]间隔传输带宽
[5] 0.00-1.00 秒 0.00 字节 0.00 位/秒
[5] 1.00-2.00 秒 0.00 字节 0.00 位/秒
[5] 2.00-3.00 秒 0.00 字节 0.00 位/秒
[5] 3.00-4.00 秒 0.00 字节 0.00 位/秒
[5] 4.00-5.00 秒 0.00 字节 0.00 位/秒
[5] 5.00-6.00 秒 0.00 字节 0.00 位/秒
[5] 6.00-7.00 秒 0.00 字节 0.00 位/秒
[5] 7.00-8.00 秒 0.00 字节 0.00 位/秒
[5] 8.00-9.00 秒 0.00 字节 0.00 位/秒
[5] 9.00-10.00 秒 0.00 字节 0.00 位/秒
[5] 10.00-10.67 秒 81.3KB 1.00MB/秒
----- ----- ----- ----- -----
[ ID]间隔传输带宽
[5] 0.00-10.67 秒 0.00 字节 0.00 位/秒发送方
[5] 0.00-10.67 秒 81.3 KB 62.4 千比特/秒接收器
PRT = 4003cccc、原因= 1

尊敬的 Yuan：

在这种情况下、省电模式是否设置为活动状态？

您是否还能指定在您的系统上使用的以下信息？

1. RTOS 名称或类型？  

2.网络堆栈？  

3. MCU 主机器件？

4. mbedTLS 版本？

省电模式为自动模式。

RTOS：ertos

网络堆栈：lwip

MCU：oa8100

mbedTlS： 3.6.0

尊敬的 Yuan：

我懂了。 我来尝试通过将 TCP 数据包从 CC33xx 转储到另一台计算机来重现该场景、以便 CC33xx 正在传输数据包。 这是否也符合您的案例？

尊敬的 Yuan：

此外、您能解释一下 iperf3 设置吗？ cc33xx 是否在运行 iperf3 服务器、而其它设备是否正在连接该服务器？ 什么设备是 192.168.1.104 的 IP 地址、什么是 192.168.1.101 的 IP 地址？ TCP 日志是在什么时间点获取的？

你好、Sabeeh

CC33XX 器件运行 IP 地址为 192.168.1.104 的 iperf3 服务器。 通过以太网 (IP：192.168.1.101) 连接到同一 AP 的 PC 运行 iperf3 客户端。 名为“PC_tcp_..."的“的日志文件 是在 PC 端捕获的、而另一个日志来自 CC33XX 端。

尊敬的 Yuan：

您之前提到、TCP 堆栈缺少 ACK、但我在这些日志中看不到。 您能否分享屏幕截图或片段、说明您看到的 ACK 被错过了？

你好、Sabeeh

我认为数据包 17、19 ... 29 丢失或被阻止,这使得包含数字“2"的“的后续数据包无法传输,从而导致无法启动流量流。

尊敬的 Yuan：

只是提供有关这个问题的更新。 我们认为、我们在这一问题上取得了一些进展。 我正在尝试获取一个应该解决该问题的构建、我会尽快将其提供给您。  

你好、Sabeeh

真是个好消息。 详细的日程安排会很棒！

期待您的更新。

尊敬的 Yuan：

虽然我们认为我们看到我们一方的问题,但我们希望绝对肯定,这是你一方的同一个问题 这只能通过无线监听器捕获接入点和 CC33xx 器件之间的 WiFi 流量来确认。 你能收集这样的无线监听器捕获吗?

您是否还能提供您正在使用的 AP 的品牌和型号？

你好、Sabeeh

您可以从此处下载无线监听器文件：

AP 的型号是 Redmi AX5 路由器

尊敬的 Yuan：

我在嗅探器捕获中看到了一些奇怪的东西。 您能否建议您使用的 TI WiFi 器件的 MAC 地址是多少？ 此外、您能描述这些日志是如何获取的吗？ 是否正在运行完整的 iperf 应用程序？

您好 Yuan、

我们能否获得 Sabeh 要求的其他信息？

这些日志似乎包含不完整的数据、我们无法处理它们、我们确实需要了解您的问题、并确保它与我们在最终看到的相同

此致、
AB

你好、Sabeeh

以下是有关该测试的相关信息。

TI wifi 器件：192.168.31.130、Mac 54：42：67：46：df：C9

测试 PC：192.168.31.93、Mac 00：1c：23：03：8e：2f

启动 iperf 测试后、使用 OmniPeek 开始捕获数据包。 使用的 iperf 版本是完整的应用程序。

你好、Sabeeh

下面是新的嗅探器文件 、其中包括身份验证/通信过程、您可以阅读 readme.txt 中的更多信息。

谢谢。

尊敬的 Yuan：

我在监听器捕获中看到了一个帧、其中 CC33xx 提示它将进入睡眠状态。 您能否确认此测试是使用 WLAN_STATION_ACTIVE_MODE 还是 AUTO 进行的？

尊敬的 Yuan：

此嗅探器的可读性要高得多、因此感谢您提供。 但是、我们正在尝试跟踪吞吐量在数秒内降至 0 的问题。  在 iperf 日志中、我看到吞吐量瞬间降至 0。 您是否能够收集一个监听器捕获、其中吞吐量下降了很长时间、如之前报告的那样？

还有一个问题、两个监听器捕获结果 (wifi_sniffer_test5.pkt 和 pc_tcp_iperf3_test5.pcapng) 似乎都不对齐。 这意味着、我们在两个日志中看到的 TCP 数据包不是相同的、因为 TCP 序列号不包含相同的值。 这两次捕获是否同时进行？

你好、Sabeeh

cmd “get_ps"显示“显示它是活动模式。

数据包捕获确实是同时进行的、端口号匹配。 器件侧的序列号可以相关联。

 在我尝试重现吞吐量的任何地方、吞吐量数秒下降到 0 的问题都很难重现。

尊敬的 Yuan：

您能建议如何关联日志吗？ 因为我们从 TCP 序列号中看到它们不匹配。

例如、请参阅以下两幅捕获图像。 每个 TCP 数据包内的 Sequence（序列）值不会相互对齐。

实际上、PC 在两个文件中发送的 TCP 数据包的序列号不匹配、这可能是由于路由器篡改造成的。 但是、要在两个文件中识别相同的 TCP 数据包、我们仍然可以根据 TCP 有效负载匹配它们。

现在、我们发现**PC_tcp_payload_test5**文件中的 244 个数据包对应于**WIFI_sniffer_test5**文件中的第一个数据包。 通过这种对齐、我们可以使用这两个数据包作为参考、以关联所有后续的 TCP 数据包。

我不确定您的意思、能否提供屏幕截图？ 这是我看到的、但它们不匹配。 TCP 数据包也不对齐。

无论如何、最好是捕获吞吐量完全下降的时间。 这将有助于我们了解是否存在驱动程序或基础 WiFi FW 问题。

你好、Sabeeh

我通过删除前 243 个数据包对 PC_tcp_iperf3_test5 文件进行了一些修改、以便 TCP 序列号可以与 wifi sniffer_test5 文件保持一致。

尊敬的 Yuan：

谢谢您的提问。 现在我看到数据包最初是保持一致的。 它们由于 TCP [PSH、ACK]数据包而不同步、看起来 AP 发送的数据包较小、这可能会导致 Wireshark 解释也关闭。

无论如何、我们在监听器日志中看到的是通信始终处于活动状态。 WIFI 监听器中的 TCP 数据包不会真正减慢以匹配串行控制台日志中看到的吞吐量值。

同样有趣的是、这种监听器捕获的 IP 地址与您大约一个月前发送的图像不同、监听器在这里看到 TCP 保持活动数据包。 您是否在其他 AP 上进行测试？ 您能否在我们看到 TCP 保持活动数据包的情况下重新测试和收集监听器数据？

你好、Sabeeh

您提到的问题很难重现、可能只是一个孤立的情况。 之前、您提到该问题可能会在您的最后重现 您能描述一下什么是可重现的问题吗？ 此问题是否已解决？ 此外、是否可以提供新固件供我们测试？

尊敬的 Yuan：

我们认为我遇到的问题是 AP 行为不当。 AP 将在 2.4GHz 时发送 MCS 8 的 CC33xx 数据速率、IEEE 规范不支持该速率。 然后、AP 不会以较低的速率重试相同的数据包、从而导致 TCP 会话卡住。 如果我强制同一 AP 使用 11b 或 11g 速率、则我没有遇到相同的问题。  

我们将就新固件事宜与您联系。  

尊敬的 Yuan：

您是否也能确认您的产品使用的是 CC3301 还是 CC3351？

我们使用 CC3301。