[参考译文] CC2530：Z-Stack 监视和测试 API.pdf 在 ZStack 3.0.2中不是最新的？

您好、Mario、

感谢您提供此反馈、我已更改 了监控器和测试 API 、该 API 每季度在 SIMPLELINK-CC13X2-26X2-SDK 中进行更新。   我不知道此处所列内容之外的任何未记录的更改。

此致、
Ryan

好的、2020版本没有提到我的观察结果、我发现了另一个观察结果、在代码中也可能导致错误。**

Linux 网关发送(带有解码信息)：

****下一行有效载荷中有60个字节
[2020-11-20 14：27：17.329430]<[SYS/SREQ]** OSAL_NV_IT_PROMOTIVE_TABLE [0x00][65]、[0...254]= (sys：1/type：20/CMD：07)(70)：：FE 41 21 07 10 03 41 00 ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff (SYS：1/TYPE：20/CMD FF ff ff ff_ff 00 ff ff ff ff ff_ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff FF ff_ff ff ff ff ff ff ff ff ff ff FF ff_ff 00 00 00 00 00 00 00_00 00 00 00 00 00 00 00_00 00 00 00 00 00 00 00_00 00 00 ca
[2020-11-20 14：27：17.362263]>[SYS/SRSP]** OSAL_NV_item_init** 好的 (sys：1/type：60/CMD：07)(6)：Fe 01 61 07 00 67
[2020-11-20 14：27：17.368203]<[SYS/SREQ]** OSAL_NV_READ** 代理表[0x00][0..] (sys:1/type:20/CMD：08)(8)：：fe 03 21 08 10 03 00 39
**读回在有效载荷中有65个字节(项目的长度)，因此包括一些不在写操作中的字节：
[2020-11-20 14：27：17.391529]>(48)：：：fe 43 61 08 00 41
ff ff ff ff ff ff ff ff FF ff ff ff ff ff ff ff 00 ff ff ff ff ff ff ff ff ff ff ff ff ff ff FF ff ff ff ff ff ff ff ff ff (FF 关闭 FF ff ff ff ff ff ff ff ff ff (FF 关闭 FF ff ff ff ff ff ff ff ff ff (FF 关闭 FF ff_ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00_00 00 00 22 00 ff 00 00 B6

这与代理表中的第二项类似。
[2020-11-20 14：27：17.400446]<[SYS/SREQ]** OSAL_NV_IT_INIT** proxy_table[0x01][65]、[0...254]= (sys：1/type：20/CMD：07)(70)：：FE 41 21 07 11 03 41 00 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff (SYS：1/TYPE：20/CMD FF ff ff ff ff ff ff ff ff ff ff 00 ff ff ff ff ff ff ff ff ff ff ff ff ff FF ff ff ff ff ff ff ff ff ff (FF 关闭 FF ff ff ff ff ff ff ff ff ff (FF 关闭 FF ff ff ff ff ff ff ff ff ff (FF 关闭 FF ff ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 CB
[2020-11-20 14：27：17.431626]>[SYS/SRSP]** OSAL_NV_item_init** 好的 (sys：1/type：60/CMD：07)(6)：Fe 01 61 07 00 67
[2020-11-20 14：27：17.481542]<[SYS/SREQ]** OSAL_NV_READ** 代理表[0x01][0..] (sys：1/type：20/CMD：08)(8)：：Fe 03 21 08 11 03 00 38
[2020-11-20 14：27：17.504771]>(48)：：Fe 43 61 08 00 41 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff FF ff ff ff ff ff ff ff 00 ff ff ff ff ff ff ff ff ff ff ff ff ff ff FF ff ff ff ff ff ff ff ff ff (FF 关闭 FF ff ff ff ff ff ff ff ff ff (FF 关闭 FF ff ff ff ff ff ff ff ff ff (FF 关闭 FF ff ff 00 00 00 00 00 00 00 00 00
[2020-11-20 14：27：17.507325]>(24)：00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 22 00 ff 00 00 B6

相应的代码有一个错误、其执行方式与文档中的略有不同：

/* NV 项目 ID */
nvId = osal_build_uint16 (pBuf)；
/* NV 项目长度*/
nvLen = osal_build_uint16 (pBuf+2)；
/*初始化数据长度*/
idLen = pBuf[4]；
pBuf += 5；

#if defined (ZNV_LD16)
= nLDCO_NOT_POLL (nLDCD_16)

/*此项目不应再存在。 读取和写入将进行转换
*添加到新的 NV 项目、因此返回成功。
*
RET = ZSuccessess；
｝
否则
#endif
｛
如果(idLen < nvLen)
｛
/*尝试创建新的 NV 项目*/
RET = osal_nv_item_init (nvId、nvLen、NULL)；
if ((ret =nv_item_UNINIT)&&(idLen >0))
｛
/*将初始化数据写入新项目的第一部分*/
(void) osal_nv_write( nvId、0、(uint16)idLen、pBuf )；
}
｝
其他
｛
/*尝试创建/初始化新的 NV 项目*/
RET = osal_nv_item_init (nvId、nvLen、pBuf)；
｝
｝

我意外地确认了实际跟踪中的错误。

1) 1) 如果 InitLen 大于项目大小、则接受该值并进行裁剪。  该文档指出、如果 InitLen 不为零、则使用 InitData 中的值。  不用说 InitLen 等于 InitData 使用的字节数。

2) 2)如果 InitLen 大于 InitData 中的字节数、则存在缓冲区溢出。  在实际捕获中、InitData 只有60个字节、因此在数据包分配的存储器之外读取5个字节。

3) 3)规范规定 InitData 中只能有245个字节、但代码接受255的 initLen。

差异3：

关于 AF_register、API 文档建议群集列表始终为32个字节、而实际上它们的大小仅为实际的群集数量乘以2。

意见4：

IEEE_ADDR_RSP 与 API 文档不对应。

在下面的答复中，startIndex 为0，NumAssocDev 为0。 所以 AssocDevList 应该为空、但它显示0x00C0。

[2020-11-21 20：20：04.267541]>[ZDO/AREQ]** IEEE_ADDR_RSP** ZSuccessess <0000-00124b0010228277>(SYS：5/TYPE：40/CMD：81)(18)：：Fe 0d 45 81 00 77 82 22 10 00 4b 12 00 00 00 c97 

函数 ZDO_ParseAddrRsp 指示：

// startIndex 字段仅在 NumAssocDev 字段为非零时出现。 

如果文档正确，那么 startIndex 将出现在 NumAssocDev 字段之前，这会有点复杂。

幸运的是、代码决定：

typedef 结构
｛
uint8 status；
uint16 nwkAddr；
uint8 extAddr[Z_EXTADDR_LEN]；
uint8 numAssocDevs；
uint8 startIndex；
uint16 devList[]；
｝ZDO_NWKIEEEAddrResp_t； 

因此、这似乎是此数据包在文档方面的第一个区别。

但是由于 numAssocDevs 为0，那么3个字节0x00 0xC0和0x00是什么？

这些字节实际上在标头中、并在长度中进行计数。 startIndex 不会 disspPEAR、而 uint16 devList[]占用2个字节。  数据包的实际长度不会指示给调用方。

但等待、还有更多！

主叫方依靠  MT_ZdoAddrRspCB 发送数据包。  该方法实际上会重新构造数据包、复制 extAddr 和 nwkAddr、然后首先放置"startIndex"、然后是"listLen"。   因此"startIndex"可以是任何值、因为当列表的长度为0时、存储器未初始化。

因此、字段的顺序如文档中所示、但 StartIdx 可能不会初始化、即使列表长度为0、也至少有两个额外的字节。

Observatino #5.

逻辑通道的字段大小为1，而 不是 EXT_NWK_INFO 中的2。

意见6.

ZDO_EXT_SEC_APS_REMOVE_REQ 的条目按该顺序指定以下有效载荷字段：

NWK 地址2器件的网络地址
扩展地址8器件
父地址2父地址的 IEEE 地址 

当解码数据包时、这是不正确的：

[2020-11-21 15：50：21.403490][NWK_MGR/LSTN] PKTTYPE：[ Z_STACK< 父级：70B3 (SYS：5/TYPE：20/CMD：51)(17)：：：Fe 0c 25 51 24 94 24 94 1e 01 30 B1 D5 B3 70 F1 

我们可以看到 IEEE 地址与来自 NWK_Mgr 的请求不对应。

实际上、执行的顺序是：

父地址2父地址
NWK 地址2设备的网络地址
扩展地址8设备的 IEEE 地址 

ZStack 3.0.2会忽略 IEEE 地址、这可能会在删除器件时造成错误的安全感。  使用 IEEE 地址而不是父级/NWK 用户认为更适用。

您好、Mario、

#2：开发人员有责任不通过发送比 initLen 中所述更少的数据来导致溢出

#3：进行了更改以阐明这一点(用法显示 App[IN/OUT]群集列表长度可以是0到32)。

#4：更正了 ZDO_IEEE_ADDR_RSP 说明、以便 NumAssocDev 位于 startIndex 之前。  如果 NumAssocDev 为零、则应忽略来自缓冲区的其他填充字节数。

#5：已修复此问题

#6：请在以下 E2E 主题中查看 Toby 对此问题的分析。

此致、
Ryan

您好、Ryan

#6 -我为此创建了一个线程  - Toby 的分析似乎不完整。

这个问题只有在审查文件时才会得到解决-在此阶段、我不会花太多的精力来找出这些差异、因此我确信还有更多的差异。

关于#2、这不仅是开发人员的责任。  在没有此类检查的情况下、系统也更容易出现通信错误。

7号

 未  指定 MT_UTIL_GET_DEV_NWK_INFO 和 MT_UTIL_SET_DEV_NWK_INFO -它们可能不是公开的、但在网关代码中引用。

8一些进一步的观察结果：

• 除了最新文档中的第一页之外、页脚仍表示2016年的最后一次更新、而版本1.18的日期为2020年。 这在阅读文档时令人不安、对打印页面的人不有帮助(我不是其中之一)。
• 2.1.1：该映像表明 MT_CMD 最多可为255字节、而最多可为253字节。 在2.1.2中是正确的
• 为了响应“JAMMER_parameters”(fe0721159600c46400000005)，ZNP 回复“invalid CMDID”fe03600002211555。
  但子系统0被保留、并且 CMDID 0未被指定。
  有效负载使主机能够将响应与正确的请求相匹配(这允许更新网关以更好地处理 SRSP)。
• CMDID 被认为限制在250 (0xFA)、但子系统0x0F/CMDID 0xFF 映射到 SET_NWK_FRAME_COUNTER、子系统0x0F/CMDID 0xFF 映射到 MSG_CB_INcoming

7：  相应地添加了 MT_UTIL_GET_DEV_NWK_INFO 和 MT_UTIL_SET_DEV_NWK_INFO 是 SIMPLELINK-CC13X2-26X2-SDK 中弃用的 MT 命令、因此未添加。

8：

• 2016年更新为2020年
• 按描述进行了修订
• MT_SYS_JAMMOR_FEATURE 已被弃用、因此任何 MT_SYS_JAMMOR*函数都不会包含在 MT API 中
• 修改了第2.1.2节 MT CMD 的命令 ID 范围

感谢您帮助改进本文档。

此致、
Ryan

Ryan Brown1. 

这个问题还不能解决、因为我确信还有更多项目需要报告。

原则上、TI 团队应仔细审查本文档、以确保其完整且正确。