[参考译文] CC2538：ZigBee 协调器和多器件、器件上的链路密钥设置为零。

admin

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/920181/cc2538-zigbee-coordinator-and-multiple-devices-link-keys-on-device-set-to-zero

器件型号：CC2538

我们遇到了同样的问题、并认为、如果 ZED 或 ZR 要求 ZC 离开网络、则会发生这种情况。 ZC 继续删除其网络安全密钥(0是它们-这本身可能是一个错误)、panid 和其他网络信息、然后进行软重置。在我们的案例中、我们认为我们最近开始尝试发送错误数据包的 COTS 传感器。

ZDrapp.c 中的建议修复：

@-3127、6 +3127、13 @@ void ZDO_LeaveCnf (NLME_LeaveCnf_t* cnf)
if (osal_ExtAddrEqual (cnf->extAddr)
NLME_GetExtAddr()=true )
{
// mh：防止其他路由器和 EDS 破坏网络
//要求 ZC 离开。
//如果不执行此检查，ZC 将清除网络密钥、panid 等
if (ZG_DEVICE_Coordinator_type)｛
返回；
｝

//如果注册了回调，则将离开确认传递到更高层
if (((zdoCBFunc[ZDO_LEASE_CNF_CBID]== NULL)||
((*zdoCBFunc[ZDO_leave _CNF_CBID])(cnf)== NULL)

我们仍然需要完全确认此修复。

5 年多前

0 admin 5 年多前

TI__Guru**** 2535150 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

您好、Mathew、

感谢您提醒我们此问题并提供您的解决方案、这似乎是一个有效的解决方案、但请在进一步测试后告诉我它是否可以解决此问题。根据 Zigbee 3.0规范、ZC 器件应忽略来自网络中任何 ZR/ZT 的所有休假请求。

此致、
Ryan

0 admin 5 年多前

TI__Guru**** 2535150 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

感谢您的确认、Ryan。我们在开发团队部署了修复程序、并正在观看。

对于发现这一点并想知道此问题是否会影响他们的任何其他人。我们是如何通过查看 NVRAM 来确定原因的。

"133"：｛
"idName"："ZCD_NV_LEASE_CTRL"、
"值"："01"
｝、

这表示已要求 ZC 离开网络。其余与网络相关的参数为0xff*或0x00*。

0 admin 5 年多前

TI__Guru**** 2535150 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

尊敬的 Mathew：

您是否能够提供对 ZC 代码/设置和复制步骤的更改、以及捕获导致此行为的离开请求的监听器日志？我尝试复制它、但无法在 ZDO_LeaveCnf 中中断或观察 ZR 休假或管理休假请求后描述的 ZC 行为。

此致、
Ryan

Zigbee®︎ 和 Thread（参考译文帖）

Zigbee®︎ 和 Thread（参考译文帖）(Read Only)

[参考译文] CC2538：ZigBee 协调器和多器件、器件上的链路密钥设置为零。