CC2530 Z-Stack 3.0.0 终端不能入网

@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对数据包进行解密，就会有问题。