[参考译文] SIMPLELINK-CC13X2-26X2-SDK：当接收到孤立通知/协调器重新调整时、协调器崩溃

大家好、Koen、

感谢您报告此问题。  您能否提供 https://github.com/Koenkk/zigbee2mqtt/discussions 链接(如果适用)和监听器日志？  如何使用 TI 器件复制 Orphan 通知、协调器是否使用默认 ZNP 代码失败？  您是否能够调试协调器以进一步了解应用程序失败的原因？  在没有来自飞利浦设备的协调器重新调整消息的情况下，是否会出现此问题？

此致、
Ryan

您好、Ryan、

> 能否提供 https://github.com/Koenkk/zigbee2mqtt/discussions 链接(如果适用)和监听器日志？

https://github.com/Koenkk/zigbee2mqtt/issues/13039。 下面是监听、网络密钥为"66：B3：AB：99：0C：F1：A8：44：56：22：FE：01：31：43：36：09 04：51"。 协调器的最后一条消息发送为否 82611、82625上的孤立通知。

e2e.ti.com/.../orphan_5F00_notification_5F00_crash.pcapng.zip

> 如何使用 TI 器件复制 Orphan 通知、协调器是否会失败并使用默认 ZNP 代码？

我不知道如何发送它、但"Orphan 通知"实际上是由 TI 终端设备(SONOFF SNZB-03)发送的。 我的 FW 更改极小(NV 页面、表格大小主要)、鉴于"协调器调整"的处理是在 FW 的闭源部分进行 的、我不希望我的更改与此相关。

> 是否能够调试协调器以进一步了解应用程序失败的原因？  

鉴于它发生在 FW 的闭合源代码部分、这听起来很难实现

> 如果没有来自飞利浦设备的协调器重新调整消息，是否会出现此问题？

用户删除了 SNZB-03 (发送"孤立通知"的器件)、之后问题不再出现

感谢 Koen 的详细介绍。  我无法使用 66：B3：AB：99：0C：F1：A8：44：56：22：FE：01：31：43：36：09或 AB：99：0C：F1：A8：44：56：22：FE：01：31：43：36：09：04：51作为网络密钥来解密监听器日志、您能否确认正确 的值？  我将与 IEEE 802.15.4 MAC 团队合作、进一步确定为什么 Orphan 通知会中断 ZNP 操作。

此致、
Ryan

很抱歉、我提供了错误的密钥。 正确答案是： 66：22：AB：99：0C：45：A8：44：56：22：FE：01：45：43：36：09

不幸的是、这个也没有 解密 Zigbee 数据包。  在我们尝试弄清这一点时、您能不能让我深入了解数据包82617/82621 (ZCL 报告属性)和82619 (路由记录)的内容？  我想知道是否在 ZCL 标头帧控制中设置了禁用默认响应位。  我注意到 ZNP 没有响应这些消息、这可能会首先导致 Orphan 通知。  即使在发送 Orphan 通知之前、ZNP 也可能已崩溃、这可能来自属性报告的处理方式。

此致、
Ryan

我确定这是正确的密钥(见下文)

数据包：

这次我发现了 Zigbee 网络密钥故障、现在我可以解密数据包。  ZCL 报告属性数据包实际上会禁用默认响应、因此奇怪的是、在发送 Orphan 通知之前、器件会发送两个具有 ACK 的 ACK。  数据包似乎没有不正确的地方 ，路由记录也同样无关紧要。  同时、我测试了我自己的 SIMPLELINK-CC13XX-26XX-SDK v6.20 ZNP、并且未观察到设备崩溃、同时还从之前加入网络的 ZED 广播了类似的 Orphan 通知。

e2e.ti.com/.../orphan_5F00_notification_5F00_nocrash.cubx

您是否有任何其他发生这种情况的实例、以帮助调查其他可能导致此行为的原因、并是否通过 CCS 调试器监视 ZNP 堆/堆栈以确认没有内存溢出？

此致、
Ryan

因此、"Orphan 通知"似乎不会导致问题。 在您的监听中、我没有看到"协调器重新调整"消息、我希望这是导致崩溃的原因。

在提供的监听器日志中、协调器重新调整消息来自第三方设备(Philips)、并根据 MAC 目标 IEEE 地址直接发送到 ZED。  我不知道如何在可用的 TI 器件上重新创建此消息、也不知道它可能会如何影响它不打算用于的 ZC。  先前的测试评估了移除 Orphan 通知设备(SNZB-03)是否会导致 ZC 失败、但对于协调器重新调整设备、测试结果并不相同。

此致、
Ryan