This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

[参考译文] CC1352P:通过路由器的终端设备配对问题

Guru**** 3001220 points

Other Parts Discussed in Thread: Z-STACK, CC2530

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

https://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1024945/cc1352p-end-device-pairing-issue-through-router

器件型号:CC1352P
Thread 中讨论的其他器件:Z-stack、 CC2530

大家好、

在 Z-Stack Linux 服务器和堆栈版本 5.10.00.48上运行的系统以及基于 CC2530且带有未知 Z-Stack 的路由器上、我们遇到了问题。

有两台路由器、设备类型和固件相同、所有设备之间的距离均为1-5米。

首先、终端设备尝试通过路由器4583加入网络:
#7 - 4583重复的管理许可加入请求
#157/167 -来自器件的信标请求
#171 -路由器应答信标
#174 -设备向路由器发送关联请求
181-路由器向设备发送关联响应
#188/189/191/193 -路由器将更新设备发送给协调器
(笑声) 协调员确认但未提供密钥,配对失败...

第二次尝试时、终端设备通过路由器881D 加入(网络仍处于打开状态):
#454/459 -来自器件的信标请求
#455/462 -路由器应答信标
#465 -设备向路由器发送关联请求
#469 -路由器向设备发送关联响应
#477/479 -路由器将更新设备发送给协调器
481 协调器 将传输密钥发送到路由器
#493,494,497路由器向设备发送传输密钥
配对成功

我看不到两台路由器发送的设备更新消息有什么区别,协调员确认两台路由器的消息。 为什么它会向第二台路由器发送密钥,而不是向第一台路由器发送密钥?

在重新启动插头之前、该行为保持稳定。

由于这是一个客户系统、我们很幸运拥有监听器日志、但遗憾的是没有扩展的 ZNP 日志。

此致
Peter

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

    出于某种原因、附加文件不起作用。 您可以在此处找到监听器日志:
    https://1drv.ms/u/s!AuGD3z8N0GWFsq589zARbJjW8h51HA?e=2SbaxC

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

    您好、Peter、

    感谢您提供监听器日志。  我可以看到、ZC 已启用允许加入、并且在加入失败时没有与0x4583保持良好的链接。  ZC 中缺少 MAC 序列号(83)、这很可能是通道:有问题的传输密钥、但我无法确定监听器/路由器是否错过了此数据包、或者由于 CSMA/CA 冲突等内部故障、它从未从 ZC 无线传输。  这两种情况都不太可能、但如果不直接进一步调试 ZC、就无法了解更多信息。  另一个令人担忧的问题是、只有一条链路状态消息(应每15秒发送一次)在35秒的窗口中从 ZC 发出。 工作和功能不正常的加入流程之间没有特殊的区别。 请让客户进一步监控其系统是否存在任何其他不稳定行为、如果可复制、则调试将更容易。

    此致、
    Ryan

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

    您好、Ryan、

    我现在能够在办公室重现此问题、我注意到了一些有趣的事情。 提醒一下、问题是通过路由器加入的终端设备在某些情况下不会接收到"删除"。

    这是协调器在14:35:33处以超时60秒打开网络的消息:

    这是将允许新设备进入的插头的信标(关联许可:是):

    这是我们协调员说"不"的信标:

    正好在60秒后、协调器将关闭网络、就像没有发生任何事情一样:

    我们已经多次查看了监听器日志、我们找不到任何原因可以让协调员在60秒的超时之前关闭网络、实际上、通过查看最后的屏幕截图、网络似乎一直处于打开状态。

    有什么想法吗? 我们认为、5倍堆栈经常会发生这种情况、而4倍版本不会出现这种问题。 但这也可能是因为越来越多的客户在使用它。

    请在附件中找到 Linux 服务器的调试日志和完整的监听器日志。

    此致
    Peter

    e2e.ti.com/.../8132.zigbee.log

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

    它不允许我添加文件、因此下面是指向 CubX 的链接:
    https://1drv.ms/u/s!AuGD3z8N0GWFsrBUBHWWnojal1IeTg?e=UZvfbA

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

    您是否已记录发送 到 ZNP 的网关 ZdoMgmtPermitJoiniq 命令?  能否调试 ZNP 以确定 如何   处理 MT_ZdoMgmtPermitJoinRequest -> ZDP_MgmtPermitJoiniq -> ZDO_ProcessMgmtPermitJoinq -> ZDSecMgrPermitJoining?   允许加入请求可能会在网络上广播,但不 会在本地应用。

    此致、
    Ryan

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

    您好、Ryan、  

    我们可以,但我们必须等待局势再次恢复。  

    同时,我认为你认为许可证是广播但不适用的,你是否曾遇到过这样的问题,如果是,你做了什么?

    您可能会回答、确切地查看您告诉我们要调试的代码、但至少我想尝试加快速度。  

    晚上好

    Peter  

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

    尊敬的 Peter:

    对于 Ryan 提到的情况、我的客户遇到了类似的问题。 如果在 ZNP 不执行出厂复位的情况下从网关侧删除了 ZDO 端点、则会广播允许加入、但不会应用于信标中的关联许可位。

    通过从网关主机中删除与 ZDO 端点删除相关的代码来解决此问题、请检查其是否符合您的要求。

    此致、

    水阳

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

    您好、Shuyang。

    这听起来非常有趣、我们将会了解一下!

    此致
    Peter

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

    感谢水阳的反馈!

    Peter、

    请进一步监控 afDelete 的使用情况、以确保端点0永远不会被应用程序删除。

    此致、
    Ryan

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

    您好 、

    我们一直在寻找必须消除的代码来避免此错误、但我们仍然找不到它。 请、您是否记得必须删除的代码?

    非常感谢您的参与

    BR、

    Randy

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

    您好、Randy、

    您是否从 zstackpb.c 中的 case type = Server_disconnect 下的 afDelete (PEP -> epDesc.endpoint)开始?

    此致、
    Ryan

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

    您好、Ryan、

    我们已经找到了您评论的此器件。 我们添加了防止端点0被删除的条件。 我们已经过测试、到目前为止一切都正常。 希望它继续如此。 非常感谢您的帮助。

    BR、

    Randy