[参考译文] CC3351：WoWLAN 意外唤醒系统

您好：

您是否能够使用监听器捕获并查看哪些数据包正在打开您的系统？

是的、我能够捕获 WiFi 数据包。 我将尝试捕获触发唤醒的数据包。

您好：

您是否使用专用的 GPIO IRQ 唤醒 MPU？

您分别尝试了哪些滤波器？ 您可以尝试“iw phy0 WoWLAN Enable any“、然后向器件发送 ping 吗？ 这样可以吗？

不同应用  HOST_IRQ_WL  来唤醒系统。 我尝试使用 iw phy0 wowlan enable any、当我向设备发送 ping 时、系统确实唤醒了。 同样的事情发生的时候 iw phy0 wowlan enable patterns 00:44:44:44:44:44:-:-:-:-:-:-:08:00:45:-:-:-:-:-:-:-:-:06:-:-:-:-:-:-:c0:a8:01:04:13:89,我设置.

我捕获了寻址到器件 MAC 地址的数据包、这就是我找到的数据包：

00：25：92：33：44：55（广州：33：44：55）是设备的 MAC 地址。 请参阅随附的 details.e2e.ti.com/.../Capture-2.csv Excel 文件  

您好：

我也在我的系统上提出了 WoWLAN、也注意到一些问题。 对我来说,系统在几 秒钟后恢复联机,即使没有唤醒或魔术包。 这对您来说是同样的行为吗？

是的、这也正是我看到的。

好的、明白。 让我在内部进行调试并向团队报告。 我将在下周前提供最新情况。  

好极了。

只需跟进、看看是否有任何进展。

你好 Sabeh Khan1. 

我使用最新的 SDK 测试发现、当 WiFi 进入睡眠状态时、它会在 8 秒后自动开始扫描测试 SSID、然后系统将恢复。 如上图所示。
请确认此行为是否合理。 期待您的答复

你好 Sabeh Khan1. 

我抓取了 wifi 固件的日志、截获了异常唤醒的日志、并帮助分析了导致异常唤醒的原因。  我期待着你的答复。
Log 如下：

尊敬的 Jihu：

感谢您提供的所有详细信息。 似乎我们肯定有 WoWLAN 行为的错误。 让我们在内部进行调查、我会在我们计划和开发修复程序时返回报告。

尊敬的 Jihu：

我提供了一个固件、应该包含一些修复。 请在执行 WoWLAN 测试时使用此固件。 请注意、这严格用于 WoWLAN 的测试目的、不得用于任何生产目的。

e2e.ti.com/.../SW_5F00_ver_5F00_1.7.96.323_5F00_wowlan.zip

尊敬的  Sabeeh：

我在我这边测试固件、 系统在暂停几秒钟后意外唤醒

它由其他一些数据包唤醒  

 但 局域网唤醒 (WoL) 数据包可立即唤醒系统、我多次测试它。

您好：

很高兴听到 WoL 数据包对您有用。

从监听器中、实际上预计会出现意外数据包。 在突出显示数据包之前、有一个来自 AP 的操作帧数据包。 对于操作帧、MPU 必须唤醒以保持稳定的连接。 wpa_supplicant 需要这些操作帧、因此无法滤除这些帧。  

大多数情况下、AP 会使用操作帧来设置块会话以及与站点之间的长度。 通过在 wpa_supplicant.conf 文件中将“disable_max_amsdu"设置“设置为“1"，“，您、您可能可以减少块 ack 会话的数量。 我建议您将其用于测试目的。  

您使用的 AP 的品牌和型号是什么？

AP 型号：TP LINK Archer AX55

你好 Sabeh Khan1. 

我们使用 ASUS RT-AX86U 路由器完成了最新固件的进一步测试。 以下是我们的调查结果和对替代配置的请求：

1、观察:睡眠期间系统唤醒

场景：器件通过命令 echo mem >/sys/power/state.成功进入睡眠模式

问题：在短暂睡眠后、ASUS RT-AX86U 路由器发送 ADDBA 请求（操作帧）。

结果：此特定操作帧会触发 Wi-Fi 芯片过早唤醒主机系统。

2.关于 disable_max_amsdu 的反馈

我们尝试了实施您的建议、在配置中设置 DISABLE_max_AMSDU=1、但遇到了以下问题：

错误：我们当前的 wpa_supplicant 构建无法识别 disable_max_amsdu 字段、返回一个“未知网络字段“错误。

分析：在交叉编译 wpa_supplicant 期间、似乎没有启用此特定功能。

3.关于协议卸载的问题和请求,由于我们目前无法通过 wpa_supplicant 禁用 AMSDU,您能否澄清以下固件功能:

固件卸载：Wi-Fi 固件是否可以在睡眠模式下自主处理（卸载）ARP 和 ADDBA 数据包？ 我们希望确保这些常规协议交互由固件管理、以避免 Linux 内核出现不必要的唤醒中断。

WoWLAN 配置：您是否有建议的设置来启用 ARP 卸载和 ADDBA 代理、特别是在暂挂状态期间用于此芯片组？

由于意外唤醒会影响我们在试生产中进行的功耗验证、因此请优先考虑此调查。

您好：

固件卸载：Wi-Fi 固件是否可以在睡眠模式下自主处理（卸载）ARP 和 ADDBA 数据包？ 我们希望确保这些常规协议交互由固件管理、以避免对 Linux 内核产生不必要的唤醒中断。

不,这是不可能的。 这些数据包必须由网络协议栈处理、网络协议栈是 Linux 内核的一部分。 这就是我们必须唤醒主机 MPU 才能向其发送 ARP 和 ADDBA 数据包的原因。

WoWLAN 配置：是否有建议的设置来启用 ARP 卸载和 ADDBA 代理、这些设置专门用于此芯片组的暂停状态？

我们没有任何配置来实现这些数据包的卸载。 目前、我的最佳建议是 在 wpa_supplicant 中启用 disable_max_amsdu、这应该禁用带有 AP 的 ADDBA 会话。

你好 Sabeh Khan1. 

我尝试了实施您的建议在配置中设置 DISABLE_max_AMSDU=1、但遇到了以下问题：

错误：我们当前的 wpa_supplicant 构建无法识别 disable_max_amsdu 字段、
第 3 行：未知全局字段“disable_max_amsdu=1"。“。
第 3 行：配置行“disable_max_amsdu=1"无效“无效。

这是因为 wpa_supplicant 的某些配置选项未打开吗？

你好 Sabeh Khan1. 
是否有任何方法可以完全关闭 wifi6(11ax)？

您好：

是的、我们确实能够关闭 WiFi 6。 可以通过 INI Composer 工具对其进行设置、并创建一个新的 cc33xx-conf.bin。 我们有一个名为“disable_wifi6"的“的参数。  

请注意、块 ACK 会话和操作帧是 802.11n 的一部分、因此即使禁用 WiFi 6、您仍会收到操作帧。 但您可以尝试一下。

你好 Sabeh Khan1. 

我们已按照建议（配置）禁用 WiFi 6mac.he_enable = 0x01、但不幸的是、频繁的内核唤醒问题仍然存在。

在分析监听器日志后、我们观察到导致唤醒的以下序列：

1. 进入睡眠模式：当内核进入睡眠模式时、WiFi 固件发送一个 DELBA（删除操作）帧、电源管理 (PWR Mgr) 位设置为 1。 这将告知路由器删除先前的块 ACK (BA) 链路、并指示设备将进入休眠状态。

2. 不必要的唤醒：大约 10 秒后、路由器发送 ADDBA 请求。 由于 WiFi 固件在低功耗状态下无法处理此数据包、因此强制唤醒内核以处理 ADDBA 请求。

进一步测试：我们通过设置disable_ht = 1wpa_supplicant（禁用 AMPDU）来执行测试。 禁用 HT/AMPDU 后、频繁的内核唤醒情况显著改善。

我的问题:为什么 WiFi 固件DELBA在进入睡眠前会发送一个帧来切断 BA 链路? 固件能否简单地发送 QoS 空数据包PM=1以通知路由器它正在休眠、而不删除 BA 会话？ 中断会话似乎会触发路由器尝试重新建立会话（通过 ADDBA 请求）、从而导致唤醒。

期待您的反馈。

AP 型号：ASUS AX68U pro

我们已按照建议（配置）禁用 WiFi 6mac.he_enable = 0x01、但不幸的是、频繁的内核唤醒问题仍然存在。

同样、这是预期结果。 禁用 WIFI 6 不会对行为产生影响、因为 BA 会话是 WiFi 4 的一项功能。

我的问题：为什么 WiFi 固件会DELBA在进入睡眠状态之前发送一个帧来断开 BA 链路？ 固件能否简单地发送 QoS 空数据包PM=1以通知路由器它正在休眠、而不删除 BA 会话？ 似乎拆开会话会触发路由器尝试（通过 ADDBA 请求）重新建立会话、从而导致唤醒。

我不认为这是 Wi-Fi 固件、但是 Linux 内核在内核/MPU 进入睡眠状态之前结束连接。 是的、路由器会重试连接。

你好 Sabeh Khan1. 

感谢您的反馈。

根据您的建议、我们调查了该mac80211行为并成功应用了内核补丁 (e2e.ti.com/.../0001_2D00_debug_2D00_ampdu_2D00_sleep.txt) 以防止在暂停期间发送 DELBA 帧。 会话现在按预期保持活动状态。

但是、系统仍然异常唤醒。 我们已确定固件处理 IGMP 流量的块 ACK (BA) 会话的根本原因。

场景 A（当前问题）：

• 路由器发送 IGMP 多播数据包（可能由 AP 转换为单播）。

• WiFi 固件以块确认 (BA) 进行回复。

• 结果：此 BA 交互会触发唤醒 Linux 内核的中断。

场景 B（控制测试-工作正常）：

• 我们disable_ht = 1在 wpa_supplicant 中进行了配置（禁用 AMPDU/BA）。

• 路由器发送相同的 IGMP 数据包。

• WiFi 固件以标准 ACK 进行回复。

• 结果：Linux 内核处于休眠状态。

我们的请求：您能否提供固件优化或配置来解决此问题？ 我们需要固件来处理这些 BA 会话（用于 IGMP、ARP 等后台流量） 在睡眠期间以静默方式处理标准 ACK、而不触发 Linux 唤醒。

如果有可用的特定固件标志或更新、请告知我们。

您好：

您能否帮助您澄清一下： 您是否需要使用场景 B 中所述的解决方案进行固件优化？ 或者、您是否说固件必须处理所有操作和管理帧、以便 Linux 内核始终保持睡眠状态、除非提供了唤醒字？

你好 Sabeh Khan1. 

1.关于“方案 B“（块确认处理）方案 B（禁用 HT）的说明不是我们的解决方案。 我们需要启用 HT/AMPDU 以提高性能。 我们的要求是：固件必须以静默方式处理块 ACK (BA) 生成。

逻辑：如果传入的数据包（例如多播 IGMP）与唤醒模式不匹配并由 FW 进行过滤、则 FW 仍应向路由器发送所需的 Block ACK 以维持链路、但不得唤醒 Linux

如果有效载荷本身被忽略、则发送 BA 的行为不应是唤醒事件。

2. ARP 卸载要求除上述要求外、当前固件是否支持 ARP 卸载？

问题：我们注意到 ARP 广播请求也是频繁唤醒的来源。

要求：固件应自动响应 ARP 请求（针对其自己的 IP）、而不唤醒 Linux 内核。

如果这种方法已经受支持、请告知我们正确的配置（INI 参数或功能标志）以启用它。

您好：

感谢您澄清要求。 如前所述、我们的固件不能处理这些数据包、因为我们的固件假定这些数据包需要由 Linux 内核处理。 如果对您的产品有严格的要求、我们需要讨论如何将此功能添加到中。 这不是添加的简单功能、因为我们需要将大部分 Linux TCP/IP 堆栈引入固件中。

您好 Sabeeh,

   回顾此主题、我们已经与客户讨论过、他们 非常关心待机功耗。 如果我们找不到 可行的解决方案、我们的产品就无法发布。

您好：

我们请稍后讨论这一点、因为要启用此类功能、需要大量的开发时间（超过几天）。

尊敬的 Jihu Si Xing Su Wenrong Xue 

我们当前在主机 MPU 处于睡眠状态时处理 BlockACK 会话请求的计划是拒绝这些数据包。  

采用此解决方案时、在 WoWLAN 期间、AP 会重试指数退避的 ADDBA 请求、而不会断开连接。 固件以正确的 ADDBA_RESPONSE 状态拒绝进行响应。

唤醒后、ADDBA 请求很快到达、并立即被主机接受、BA 会话会正常重新建立。 这不会影响数据包筛选器、而且该解决方案还会加快我们的开发速度。

我将与您确认此解决方案是否可用于 BSH 的应用。

你好 Sabeh Khan1. 

是的、我们的应用和安全方法完全可以接受在主机 MPU 睡眠状态期间拒绝 ADDBA 请求的解决方案、即在不断开连接的情况下使主机保持睡眠状态。

我们想在 WoWLAN 期间确认 CC33xx 固件是否同时完全支持它们：

1. ARP 卸载：在主机进入深度睡眠模式之前、我们会将设备的 IP 地址推入固件。 我们期望固件在不唤醒主机的情况下自动捕获 ARP 请求并以 ARP 响应进行响应。

2.组播过滤和省电状态维护:我们希望固件能够自主处理或过滤特定组播流量（如 mDNS、SSDP 或一般组播丢弃）,以防止误唤醒。  

BSH 提供了市场上流行的 AP/路由器型号的详细列表。 您可以获取这些路由器型号、并在开发函数后进行测试、以验证函数的可行性。
Xing su