Af_DateRequest 返回 0xc2 的问题分析及解决

【背景】

        2018年7月份使用z-stack 3.0 + 2530做低功耗设备，碰到调用Af_DateRequest 返回0xc2的问题，在这之前已经用过2530做过几个低功耗设备，从未碰到这个问题。首先怀疑是z-stack 3.0的问题，因为以前用的都不是这个版本，但是在TI的社区中看到其他的帖子出现这个问题的，从较早2.5.1a到较近的z-stack home 1.2.2a版本都有案例，说明不一定是z-stack3.0的问题。并所有这个问题的帖子都是未解决的，也就是TI社区员工也不知道这个问题的原因。

         作者测试出现这个问题都是在设备重加之后，并不是100%复现。从无线数据包看，父节点已经返回rejoin response，状态为success，同时也看到低功耗设备mac层响应。在无线数据看来重加过程已经完成，设备应该能正常功能工作，结果是设备数据发不出来，调试发现返回0xc2错误码。

 

【分析】

        从这个错误码的定义（ZNwkInvalidRequest）看出是无效请求，这个定义面很广，不能却定位问题的位置。在zigbee 规范里的对这个错误码的定义描述为：

                          “当前网络层状态无法处理该请求。”

        再加上浏览TI社区中相关帖子时TI员工询问某楼主_NIB.nwkState的状态，结合猜测是网络层状态异常导致。这类问题也可能是自写代码存在数组越界或指针引用错误导致的，作者这个项目自写代码不多，检查完发现不存在这个可能性。

        某次仿真情况下复现了该问题，在这个情况下查看了mac层变量macPib及网络层变量_NIB的成员。发现信道列表、逻辑信道、网络地址、panid、父节点地址等等字段都是对。唯独_NIB.nwkState异常，_NIB.nwkState的值为NWK_JOINING_ORPHAN，意思是网络层的状态还是孤立状态。结合无线数据包显示已经重加成功及zdo层devState为入网状态，作者判断可能是协议栈的缺陷，实际是重加成功，但是网络层状态没有更新过来。

 

【结论及解决】

         设备实际已经入网、但是网络层的状态字段_NIB.nwkState没有更新过来，可能是协议栈的缺陷。

        解决：返回该错误时判断网络层地址、mac地址是否有效且一致、devState是否入网状态，是则认为出现该问题，并手动将_NIB.nwkState设置为NWK_ENDDEVICE。虽然这个解决方法不太正规，但也是没有办法的办法，目前测试一月来看，没有发现什么后遗症。

 

 

转载请注明出处：https://blog.csdn.net/jason_lm/article/details/82347642