CC2530 Z-Stack 3.0.0 终端不能入网

请教一下大家， 

在KEY_CHANGE事件中， 通过下面代码， 已经使协调器组网成功了。

bdb_StartCommissioning(BDB_COMMISSIONING_MODE_NWK_FORMATION);
NLME_PermitJoiningRequest(0xFF);

终端在KEY_CHANGE事件中， 通过下面的代码，缺不能入网成功。(ZDO_STATE_CHANGE事件中， 最后的状态是 DEV_HOLD)

bdb_StartCommissioning(BDB_COMMISSIONING_MODE_NWK_STEERING);

NLME_PermitJoiningRequest(0xFF);

大家知道问题在那里吗？

我总结的一篇文章，在附件，希望能帮助到你。

协调器 组网， 终端入网 都是调用下面的代码吗?

bdb_StartCommissioning(BDB_COMMISSIONING_MODE_NWK_FORMATION | BDB_COMMISSIONING_MODE_NWK_STEERING | BDB_COMMISSIONING_MODE_FINDING_BINDING | BDB_COMMISSIONING_MODE_INITIATOR_TL);

我这边终端入网，ZDO_STATE_CHANGE事件中 最终的状态  devStates_t 是 DEV_HOLD， 请问这是什么原因？

我是先干掉了HAL_KEY=FALSE，不要任何按键，然后是在GenericApp示例程序基础上开发的，没有问题，协调器和路由器之间的TCLK和network key保持一直，刷完就自动入网了，或者恢复出厂设置以后，重新启动，也会自动入网，NV_RESTORE之类的Z-Stack 3.0都是默认开启的。

在Ztack 3.0.1的general app的示例中为啥我去掉LCD和KEY之后，其他什么都没有改，为啥一直捉取不到报文，这个还需要什么注意的地方吗？

新的协议栈里面信道有第一类信道和第二类信道，看是不是一直扫描第二类信道上去了。

请问你的问题解决了吗？我也遇到了同样的情况

3.0协议栈是会有这类问题，有时候一次入不了网，多试几次，就能入了，分析ubiqua抓包数据，发现Transport key过去以后没有任何反应，然后又Transport key了一次，还是没反应，多试几次反而就成功了，profile交换都正常了，不知道是什么原因。

按理说附近只有一个coordinator开放网络，不至于错误加入到别的网络中，就是很奇怪的了。

你好 hold li  请问你的这个问题后面解决了吗 是怎么解决的呢?我现在也也碰到这个问题了,求帮助,

wei shi5

你好 hold li  请问你的这个问题后面解决了吗 是怎么解决的呢?我现在也也碰到这个问题了,求帮助,

@wei shi5 请将你的测试数据包发送给我下，谢谢！

VV

wei shi5

你好 hold li  请问你的这个问题后面解决了吗 是怎么解决的呢?我现在也也碰到这个问题了,求帮助,

@wei shi5 请将你的测试数据包发送给我下，谢谢！

抓包文件在附件里@VV 

@wei shi5,

这个问题我们这里也有复现，目前正在解决中。

1、我分析了你的ubiqua包，发现刚开始0x0000给0x3A38 Transport Key过去以后，0x3A38节点也没Verify Key，就直接Device Announce了，可能是之前已经入过网，重复入网就是这样，话说Device Announce不就是入网成功的标志吗？ 后面接着又有Match Descriptor Request/Response，不就是进行了profile交换，看起来都正常啊

2、后面怎么0x3A38又被Leave掉了呢，莫非是router和coordinator的预编译network key不一致吗，这种情况我测试过，即使之前入过网，但是后面key修改后，两边交换确认不对，也是会被Leave掉的。

3、协议栈自带的network key默认都是0x00，宏DEFAULT_KEY在f8wConfig.cfg中定义的，后面入网后会重新生成network key，用于后面network数据通讯。我看你们的key是00:C8:B5:50:C7:FC:E5:12:C1:56:94:0B:80:08:55:40，应该是自己修改了network key对不？ 

4、我实际测试过，两边的TCLK和network key都要保持一致，才能入网，否则就会被踢掉。

5、问题来了，还是Transport key好几次，router节点都没反应，这个问题我之前也遇到过好多次，多试几次反而就成功了，初步推测可能是router收到key了，但是卡在verify那里了，所以一致没反应过来，coordinator认为超时了，所以就会重发几次，如果是这样，显然是协议栈自身的bug，我后面有空会尝试分析一下代码，看看有没有希望找到问题。

hold li

1、我分析了你的ubiqua包，发现刚开始0x0000给0x3A38 Transport Key过去以后，0x3A38节点也没Verify Key，就直接Device Announce了，可能是之前已经入过网，重复入网就是这样，话说Device Announce不就是入网成功的标志吗？ 后面接着又有Match Descriptor Request/Response，不就是进行了profile交换，看起来都正常啊

2、后面怎么0x3A38又被Leave掉了呢，莫非是router和coordinator的预编译network key不一致吗，这种情况我测试过，即使之前入过网，但是后面key修改后，两边交换确认不对，也是会被Leave掉的。

3、协议栈自带的network key默认都是0x00，宏DEFAULT_KEY在f8wConfig.cfg中定义的，后面入网后会重新生成network key，用于后面network数据通讯。我看你们的key是00:C8:B5:50:C7:FC:E5:12:C1:56:94:0B:80:08:55:40，应该是自己修改了network key对不？ 

4、我实际测试过，两边的TCLK和network key都要保持一致，才能入网，否则就会被踢掉。

5、问题来了，还是Transport key好几次，router节点都没反应，这个问题我之前也遇到过好多次，多试几次反而就成功了，初步推测可能是router收到key了，但是卡在verify那里了，所以一致没反应过来，coordinator认为超时了，所以就会重发几次，如果是这样，显然是协议栈自身的bug，我后面有空会尝试分析一下代码，看看有没有希望找到问题。

真的很感谢你这么认真的帮我分析,其实那个leave是我自己触发的,这个抓包的意思是我入网后很快又主动leave 然后再入网就会出问题,上次V神已经过来这边当面分析了一番,发现是发transportKey的时候带的加密密钥有问题,第一次入网和之后的入网密钥一样,但是第二次校验不通过,你可以看最后一个入网成功的信息,发现秘钥又不同了 ,换成了传输密钥就成功了  

UINT16 ZDApp_event_loop( uint8 task_id, UINT16 events ) 
............ 
if ( events & ZDO_DEVICE_RESET )
  {
#ifdef ZBA_FALLBACK_NWKKEY
    if ( devState == DEV_END_DEVICE_UNAUTH )
    {
      ZDSecMgrFallbackNwkKey();
    }
    else
#endif
    {
      // Set the NV startup option to force a "new" join.
      --zgWriteStartupOptions( ZG_STARTUP_SET, ZCD_STARTOPT_DEFAULT_NETWORK_STATE );
      ++zgWriteStartupOptions(ZG_STARTUP_SET, ZCD_STARTOPT_DEFAULT_CONFIG_STATE | ZCD_STARTOPT_DEFAULT_NETWORK_STATE);

      // The device has been in the UNAUTH state, so reset
      // Note: there will be no return from this call
      SystemResetSoft();
    }
  }
.................

请按照上面的代码修改测试下。

看样子VV 给的是个workaround解决方案，我还没测试。

我刚才又重新分析了ubiqua log

1、14:51:14.841129 时间点，0x0000给0x3A38发送了一个Transport Key，传输的是network key，结果没有任何反应

2、14:51:15:055169 时间点，0x3A38又主动请求0x0000 获取TCLK一次，不是第一次入网的时候，TCLK都已经发过去了吗，两边TCLK一致，后面也不会再请求TCLK了

3、后面倒是通过中间人0xF941把TCLK再次传送给0x3A38，结果就验证通过了，最后入网成功

4、看来前面一直是TCLK无法校验通过，才导致无法入网，据我了解，开始入网是beacon以后，0x0000会主动用TCLK加密network key对其进行发送，对方收到以后，可以用相同的TCLK进行解密拿出network key，以后通讯都用network key了。如果是第一步有问题，那不就是后面都没法入网了

出现问题的原因是在设备Leave的时候，没有把APS的Link Key恢复到默认的TC Link Key，仍然再使用重新分配的APS Link Key对数据包进行解密，就会有问题。