[参考译文] CC1352P：路由设备是具有匹配描述符请求的协调器(&quot；spamming&quot)

尊敬的 Peter：

CC2530包括 OTA 客户端应用程序、因此需要与 OTA 服务器进行绑定。  他们可能要求 OTA 服务器存在、因为它会在协调器的 MAC 地址上识别 TI OUI。  如果无法从中继交换机禁用或删除此功能、最佳解决方案可能是向协调器添加 OTA 服务器功能、以便它响应匹配描述符请求、从而防止器件进一步移动网络。 或者、您可以尝试在 SysConfig 中创建自定义扩展 PAN ID、这可能会阻止中继开关启动 OTA 过程。

此致、
Ryan

您好、Ryan、

我们现在已经在另一个系统上测试了相同的测试。 这两个系统的 ZNP 固件版本相同、Linux 服务器配置也相同。 但是：

现在、该请求实际上有一个自动应答。

此时、模块的硬复位和配置的恢复可能会解决问题、但您是否知道这种情况可能发生的原因？

还附加了 Linux 服务器的日志。

此致
Peter

e2e.ti.com/.../0451.zigbee.log

可能会尝试请求两个系统来查看其中一个是否支持 OTA 集群、另一个是否支持 OTA 集群。

因此、在硬复位和配置恢复后、系统现在将向所有连接的设备发送响应。 但路由设备似乎不满意、因为它们正在继续处理请求。 这是其中一个的筛选视图：

在这里、MD 响应通过0x1357发送到0xDB79。 消息将被确认。

一秒后、0xDB79再次发送请求：

这背后有什么意义、我们可以在网关方面做什么、还是这是路由设备的错误？

最好提供监听器日志来详细说明您的问题、而不是屏幕截图。

网络密钥3C：F7：34：04：06：DA：24：21：8E：2C：77：AA：91：C7：5E：D8

监听器日志： https://1drv.ms/u/s!AuGD3z8N0GWFsrBTCYIaZ97hJJxP2g?e=NuOxOq

确保使用 AF_REGTER 将 OTA 集群添加为 ZNP 协调器上的服务器。 我们在 Ztool 上对其进行测试、并确保其正常工作。

您好、Ryan、

这也是我们今天注意到的。 0xCC39以及我现在忘记了 ID 的另一个问题导致了最大的问题。

我们已删除它们、然后我们注意到 Randy (https://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1028567/cc1352p-remove-old-device-from-the-network)报告的问题、即如果删除的器件无法捕获删除、则不会将其从网络中删除。 我们可以通过捕获未知设备的通知消息并立即向它们发送许可来解决此问题、但可能已经存在一种内置机制、因为这也是一种安全风险。

通常、从监听器日志中看到的内容来看、从您的角度来看、我们还需要在网关侧执行有关这些匹配描述符消息的其他操作、或者其余操作是否一直到终端设备？

此致
Peter

Z-Stack 中没有针对这种情况的内置机制、正确的做法是从协调器向此类器件发送休假请求、以要求未知或不需要的器件离开网络。

您好、Peter、

我已经用更多信息回复了 Randy 的帖子、但 YiKai 正确地说、Z-Stack 中没有内置任何内容来处理这些实例。  您能否进一步扩展此行为带来的安全风险？

我想我们已经确定加入设备是产生不需要的消息的原因、从网关的角度来看、没有什么事情要做。

此致、
Ryan

您好、Ryan、

如果我在另一篇帖子中正确理解了您的答案、那就太棒了。

根据安全风险、我指的是以下情形：
如果设备知道密钥就可以进入网络、并且即使不在模块的数据库中也不会被删除、 用户可以通过监听捕获密钥、然后轻松地将路由设备引入网络、从而修改或筛选值、生成操作等

但是、如果 ZNP 将消除在其数据库中找不到的器件、则不存在风险、我想知道是否存在的机制确实存在。 一切都很好。

谢谢！

此致
Peter

您可以参考另一个线程上的响应。  泄露的 NWK 密钥肯定会给 Zigbee 网络带来风险。

此致、
Ryan