[参考译文] CCS/CC3220SF：WiFi 省电模式 IOP FIX /UDP

Paavo、

您是否能够捕获此 UDP 问题的监听器捕获？ 我不希望这种修复会在这里引起问题、但在作出任何假设之前、我们需要了解丢包的原因。

在问题的第二部分，是的，这是正确的。 您可以更改 NWP 中的持久性设置以减少闪存写入的数量： http://www.ti.com/lit/ug/swru455j/swru455j.pdf?&ts=1589297011435 第3.12节

BR、

Vince  

Vince、

关于我的问题的第二部分：  

=>我现在对代码进行了更改、在开始 UDP 通信之前清除了系统持久性(将其值设置为零)、并在之后保持这种状态。 因此，如果我正确的话-当我将其值设置为0 (false) 之后，我所做的任何系统持久性设置(如 sl_WLAN_XXXXXXX_policy)都不再是系统持久性的，即不会写入串行闪存，对吧？

=>系统持久性设置本身是否持久，也就是说，如果我清除，它在复位后也会关闭？

=>我能否以某种方式读取系统持久性设置，或者查看其当前值的最佳方法是什么？

问题的第一部分。 遗憾的是、我无法嗅探基于3220SF 的物联网设备和 AP 之间的流量、因为这些接入点专门具有这些 WiFi 节电 IOP 问题、导致这些数据包丢失。

但是、我在一些 UDP 帧的上方附加了 Wireshark 屏幕截图、这些 UDP 帧通过接入点成功发送、但3220SF 没有节能模式问题(使用 sp_3.12.0/1)。 这些相同的 UDP 消息在与故障 AP 通信时使用、因此它们可能会提供一些信息。

在我看来、使用来自物联网设备的 UDP 通信、与 AP 的 WiFi 连接不会从省电模式中"唤醒"、而是通过来自物联网设备的 TCP 通信。 了解 sp_3.12.0.1 IOP 修复程序("一些 AP 供应商从发送到 AP 的管理帧中了解 CC32xx 的节电模式") 在实践中的作用会让人感到很有趣、具体而言、是什么会触发将这些管理帧发送到 AP 以及何时？ 这可能会进一步粘结到那里发生的情况。

此致

Paavo

Paavo、

您对持久性的假设是正确的。

我不确定您如何声称 AP 在没有任何监听器捕获的情况下不会通过 UDP 传输从省电模式唤醒。 您能给我一个出现错误的接入点的名称吗？

在 Wi-Fi 级别、您应该将 UDP 数据包从我们的器件中传出、并且它们应该被监听器中的 AP 攻击、如果发生这种情况、则数据将到达 AP。 AP 可能无法正确向外路由该数据、数据包也会在这条路上丢弃。 这是 UDP 的负面影响、没有 TCP 之类的确认和排序。

BR、

Vince  

Vince、

感谢您对系统持久性的建议和说明。 我现在已经准备好了权变措施、并为我们的客户提供了 OTA 包。 因此、我的直接问题就是通过这种方法解决的。

是的、我知道 UDP 是如何工作的、而且由于其性质、数据包可以在途中丢弃到任何位置。

是的、很抱歉嗅探器。 但是、我坚信这与物联网设备和接入点之间的 WIFI 连接/WIFI 节电相关的原因如下：

每次-就在 UDP 封包开始之前-我都可以从 AP 的基于 Web 的管理视图中看到、它会将物联网设备从其已连接的 WiFi 客户端列表中删除。 我不会从客户端断开连接、DHCP 租用时间甚至也不会接近到期、这让我认为断开连接可能与正在使用的 WiFi 省电模式有关。

之后、当我从物联网设备发送 TCP 数据包时、AP 立即报告物联网设备再次作为 WiFi 客户端连接、一切都重新正常工作(UDP 封装也通过)。

-如果我将物联网设备 wifi 配置为 sl_WLAN_Aways_on_policy、此问题就会消失。 此配置参数仅影响本地 WiFi 连接的电源策略、不影响 AP 和远程网络之间的连接、也不影响 AP 中的路由设置。

因此、我觉得这与本地 WiFi 上的 wifi 节电以及它如何从节电中唤醒有关。

这就是为什么我很想了解 有关 sp_3.12.0.1中提到的 IOP 修复在实践中的作用的更多详细信息。

可以看到问题的两个示例接入点是 ZTE MF286和 TP-LINK Archer 400。

BR

Paavo

感谢您提供信息 Paavo。

这看起来像 AP 试图断开我们的连接、因为没有活动。 您能否尝试禁用 PS 轮询并查看它是否有用？ 以下是执行该操作的代码：