• 状态 Resolved
  • 已锁定 已锁定
  • 回复 5 回复
  • 订户 0 订户
  • 视图 386 视图
  • 用户 0 会员在此处
选项
选项
相关

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.

[参考译文] CC2538：ZStack 3.0.1中的 ZCL API 问题

admin
Guru**** 2531860 points
Other Parts Discussed in Thread: CC2538, Z-STACK

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

https://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/925404/cc2538-issues-with-zcl-apis-in-zstack-3-0-1

器件型号：CC2538
Thread 中讨论的其他器件： Z-stack

您好！

我是一名博士生、目前正在学习 Z-Stack 实施。 最近、我发现一些 ZCL API 调用可能会因随机数据而崩溃。 我使用 Z-Stack 3.0.1、CC2538和 IAR Workbench 进行调试。 我要使用的项目是示例项目 GenericApp。

首先、我使用一些模糊工具根据其规格生成 ZCL 命令消息、包括其有效载荷中的一些随机数据。 ZCL 接头完全符合规范。 对于属性值、我使用一些随机数据。 我在 CC2538中验证它们。 我发现问题的函数是 zclParseInWrite 和 zcl_HandleExternal。

我已附加更多详细信息、包括源代码、日志文件和监听数据。 我认为 Z-Stack 可以处理随机有效负载/格式错误的数据、例如返回错误代码、因为攻击者可能会操纵数据包。 能否帮助我验证 API 调用是否有问题？

非常感谢！

e2e.ti.com/.../crash.zip 

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

    您好！

    感谢您分享您对此事的调查结果。

    您是否已经在 https://e2e.ti.com/support/wireless-connectivity/zigbee-and-thread/f/158/t/902631上查看过已知问题

    如果可能、我建议移至 Z-Stack 3.0.2。



    此致、
    Toby

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

    尊敬的 Toby：

    感谢您的快速响应。 我已查看"已知问题"页面。 实际上、我发现的不是该页面中提到的函数。 特别是 zcl_HandleExternal()问题，因为我没有定义宏 BDB_REPORTING。 因此、我想知道我发现的是新的、或者我设置了可能导致此类错误的错误。

    此外、我将这些代码与 Z-Stack 3.0.2进行比较。 它们对于我找到的 API 是相同的。 如果您也能验证它们、我将不胜感激。

    谢谢、

    Mengfei

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

    感谢您的确认。

    浏览完您所附的内容后、我认为正在发生以下情况：

    • 当 ZED 接收到"写入属性无响应"和 zclParseCmd (即  zclCmdTable 中定义的 ZCL_CMD_WRITE_NO_RSP 的 zclParseInWriteCmd)时：
      • 看起来您已经这样做了、这样、ZED 将接收所有命令、然后将基础命令传递给 zcl_TaskID (在 zclGenericApp_event_loop 中)。
      • 请注意，稍后 ，zclGenericApp_EVENT_LOOP 实际上会释放分配的内存(osal_msg_desocate ((uint8 *)MSGpkt))。
      • 因此，为了正确解析，zcl_event_loop (zcl_taskID)似乎不会有这样的结果(zclParseInWriteCmd)。
      • 此处的修复方法可能是：在 zclGenericApp_EVENT_LOOP 中、分配内存(例如 pcpy)、然后将 MSGpktt 复制到该 pcpy、最后是 osal_msg_send (zcl_taskID、(uint8 *) pcpy)。
    • 当 ZED 收到"读取报告配置响应"时、它似乎挂起：
      • zclGenericApp_EVENT_LOOP 将其传递给 zcl_TaskID (zcl_EVENT_LOOP)
      • 但是 、ZCL_CMD_READ_REPORT_CFG_RSP 的处理程序是 zcl_HandleExternal (如 zclCmdTable 中定义的)。
      • 似乎 zcl_HandleExternal 会将此传递给此端点的注册处理程序(可能最终会将其传递给 zclGenericApp_TaskID/zclGenericApp_EVENT_LOOP)。
      • 这会导致两个任务来回传递消息、从而产生无限的排序循环。
      • 这里的修复方法是为这个命令定义一个不同的处理程序(或者为一个不同的端点/任务寄存器)。

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

    感谢您的确认和修复解决方案。 但我仍然有一些困惑。

    1.对于解析写入命令，根本原因是 zclGenericApp_event_loop 中的内存解分配不正确。 这实际上是由不同用户定制的用户软件应用程序。 那么、这不是 ZCL 库中的实现故障、对吧？

    我想知道为什么在 ZCL 完成处理之前不取消分配存储器。 因为消息处理在 不同的事件循环之间异步？

    因此 zcl_HandleExternal 实际上不会处理某些特定命令、例如 ZCL_CMD_READ_REPORT_CFG_RSP、它只会将消息传递到高级应用程序、对吧？ 根本原因是上层应用程序配置错误、对吧？  

    如果用户想要启用与此类命令相关的报告功能、最好定义自己的处理程序、而不是使用 zcl_HandleExternal、对吧？ 我想知道为什么不在尝试后丢弃此类消息、或者将错误发送回用户以使处理失败。

    3.我注意到，在示例项目中，有一个函数 zclGenericApp_ProcessIncomingMsg()来处理应用程序级中的 ZCL 基础消息。 如果 ZCL 库已经提供了相应的 API、那么用户为什么需要处理它们而不是让 ZCL 处理、就像我向 ZCL 转发消息时所做的那样？ 此外、对于命令 ZCL_CMD_READ_REPORT_CFG_RSP、可以由该函数中的 BDB 进行处理。 这是否意味着 zclCmdTable 中的设置无用或被覆盖？

    总之、您的解释为我提供了许多帮助我了解 Zigbee 协议的想法。 再次感谢 Toby！  

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

    [引用 user="Mengfei Ren"]1. 对于解析写入命令、根本原因是 zclGenericApp_event_loop 中的内存解分配不正确。 这实际上是由不同用户定制的用户软件应用程序。 因此、这不是 ZCL 库中的实现错误、对吧？

    不、我不认为这是 ZCL 库中的实现错误。

    [引用 USER="Mengfei Rena">我想知道为什么在 ZCL 完成处理之前不取消分配内存。 因为消息处理在不同的事件循环之间异步？

    是的、这将传递给 osal 调度程序、该调度程序保存特定任务的消息(假设消息正文指向分配的存储器)。

    [引用 user="Mengfei Ren"]2. 因此、zcl_HandleExternal 实际上不会处理某些特定命令、例如 ZCL_CMD_READ_REPORT_CFG_RSP、它只会将消息传递到高级应用程序、对吧？ 根本原因是上层应用程序配置错误、对吧？ [/报价]

    正确、一些命令与应用范围有关。

    [引用 user="Mengfei Rena">如果用户要启用与此类命令相关的报告功能，最好定义自己的处理程序，而不是使用 zcl_HandleExternal，对吧？ 我想知道为什么不在尝试后放弃此类消息、或者将错误发送回用户以进行不成功的处理。

    是的、他们应该根据自己的应用来处理它。
    通常、ZCL 会将相关消息传递给要处理的应用程序(例如 zcl_HandleExternal)、而不是另一种方式。 应用程序将主要启动 ZCL 命令。

    [引用 user="Mengfei Ren"]3. 我注意到，在示例项目中，有一个函数 zclGenericApp_ProcessIncomingMsg()来处理应用程序级中的 ZCL 基础消息。 如果 ZCL 库已经提供了相应的 API、那么用户为什么需要处理它们而不是让 ZCL 处理、就像我向 ZCL 转发消息时所做的那样？ 此外、对于命令 ZCL_CMD_READ_REPORT_CFG_RSP、可以由该函数中的 BDB 进行处理。 这是否意味着 zclCmdTable 中的设置无效或被覆盖？

    传入的 ZCL 命令可能用于该器件上的不同端点、因此 ZCL 模块将向该端点的已注册处理程序发送此消息。 ZCL 模块将执行任何强制操作(例如、请参阅 zclProcessInWriteCmd for Write Attributes 命令、它将相应地写入属性)。 例如、响应命令的处理由每个端点/任务处理、由应用程序决定。