zstack加密通讯验证不正确或超时会有自动复位的功能但跟踪了终端的整个入网流程后并未发现应该如何触发这个验证机制

本问题比较急，希望能尽快得到大家的帮助，能给出一点思路和建议，谢谢！

麻烦把整个过程的抓包文件保存下来，用附件上传下。
正常情况下，如果配置了 zgPreConfigKeys=TRUE的话，两边Key不一样的话，是无法通信的，很奇怪你说的“也能向协调器发送数据并得到ACK应答”
如果zgPreConfigKeys=FALSE的话，两边Key不一样，也没关系，可以正常工作，

为做对比，先上传双方密钥相同时的通讯过程：
RX37: 终端搜索网络
RX39: 终端发出入网请求
RX43: 终端请求分配网络地址
RX45: 网络地址分配成功
RX47: 终端将自己的地址发给父设备让其帮自己进行广播
RX49: 协调器帮终端广播地址
RX50: 终端发送心跳包给父设备（自定义的）
RX52: 终端轮询是否有数据要接收
RX54: 协调器发送回应包给终端（自定义的）
RX58: 终端上传采集数据给协调器
RX90: 下一个通讯环节的开始（重复RX50至RX58的流程）

下面是双方密钥不同时的通讯过程，已再次确认过编译选项如上所示
RX33: 终端搜索网络
RX37: 终端发送入网请求
RX39: 终端请求分配网络地址
RX41: 终端网络地址分配成功
RX43: 终端请求父设备帮其广播自己的地址
RX45: 终端发送心跳包给父设备
RX47，49，54: 终端轮询是否有数据包需要接收（自己设定终端发送心跳包后以200ms的时间间隔进行轮询）
RX51: 不知道是什么数据包，但一定不是回应包，否则在RX47后终端就会收到回应包，而不会出现RX49和RX54的轮询（自己设定终端收到回应包后就停止轮询，没停止轮询说明没收到回应包）
RX56: 终端上传所采集到的数据发给协调器（自己设定该事件在终端发送心跳包后的800ms时被触发并停止轮询，因此前面所出现的三次轮询符合代码运行流程）
RX90: 终端发送心跳包给父设备（重复RX45至RX56的流程，但再未出现过RX51这种数据包了）

抓包是正常的，虽然终端设备获得了协调器分配的短地址，但是因为Key不同，所以没办法通过认证，
所以后续有从新开始搜索网络了

你如果需要配置uint8 zgPreConfigKeys = TRUE;
那么两边的default key必须一样

终端并没有重新开始搜索网络了啊？那些LQI为0的beacon request貌似是干扰信号，时有时无的，可以确定不是我的终端发出的信号（终端没上电前就会出现）。
我比较想知道的是编译了上述加密选项后，终端入网后的具体验证流程是怎样的？为什么我的终端仍能定时发送数据给协调器而不会自动复位？还有我上述问题中所提到的终端在入网后无法进入DEV_END_DEVICE_UNAUTH是什么原因导致的呢？协议栈中我只在这里找到了加密验证中有关复位的函数，但是无法进入。还是说我的加密编译选项有遗漏的部分，导致无法正常启动加密验证过程？
希望您能为我解答，帮助我解除困惑，谢谢！

我原本的设想是，终端节点加入密钥加密验证机制，只有加入到密钥相同的网络时才开始运行相关功能，若加入到密钥不同或不需要加密验证的网络后，会自动复位退出并将该网络添加到自定义的黑名单中，直到加入到密钥相同的网络，将当前网络添加到黑名单这步骤我可以在复位函数中自行设定，我主要想解决的问题是如何使得终端在加入到密钥不同的网络后能自行发现并自动复位。
网上的一些说法说，节点编译了相关的加密选项，在加入到密钥不同的网络后，会因为无法通过验证而自动复位，但通过抓包以及上述分析发现终端并没有进行自动复位（等了好久也不会复位），在协议栈的相关函数中我只找到了问题中所描述的位置有与验证和复位相关的函数 devState = DEV_END_DEVICE_UNAUTH;和ZDApp_ResetTimerStart( MAX_DEVICE_UNAUTH_TIMEOUT );，但经调试发现并不能成功触发该复位函数，原因为 if ( ZG_SECURE_ENABLED && ( ZDApp_RestoreNwkKey() == false ) )中的ZDApp_RestoreNwkKey()为true，因此该条件语句中的代码也就是上述两条代码并不被执行。
如果说加密验证的流程不在这里触发，那是在哪里触发呢？如果说加密验证的流程在这里触发，那应该如何使得其触发呢？
希望您能为我解答，帮我解除困惑，谢谢！

问题比较紧急，大家能帮忙给出点建议吗？谢谢了！

预配置key方式， 各个设备的key是各自独立的，设备相互之间是不知道对方key的；

key不一致，只能通讯才会发现, 可以在终端入网后  启动私有的一个 同步消息（重传确保该信息能送达协调器）， 终端设备 特定时间内没有收到 协调器的rsp信息，则说明key不一致；

另外的思路可以对 if ( ZG_SECURE_ENABLED && ( ZDApp_RestoreNwkKey() == false ) ) 做修改
#ifdef 预配置方式
      if ( ZG_SECURE_ENABLED)[
     ZDApp_RestoreNwkKey() ;
#else
      if ( ZG_SECURE_ENABLED && ( ZDApp_RestoreNwkKey() == false ) )[
#endif

你好  我的问题也是类似，请问你的解决了吗
-DSECURE=1时候，如果秘钥不一致会重启；
但是DSECURE=0的时候却不能重启，请问这是什么问题呢
 

@yun gao, 
TC分key的流程你可以参考下Z-Stack Developer's Guide.pdf中关于security的介绍，另外你也可以参考Zigbee Specification中关于ZIgBee网络加密的说明。
http://www.deyisupport.com/question_answer/wireless_connectivity/zigbee/f/104/t/81385.aspx 
这个等待的过程称为等到认证的过程，在节点加网成功以后ZDApp_ProcessNetworkJoin( void )，如果在使能Security的情况下，会等待Trust Center认证的过程。
并且认证的超时时间是10s MAX_DEVICE_UNAUTH_TIMEOUT，
在这个时间段内，如果收到付设备发来的Transport Key Ind，并且Key正确的话，那么就会调用处理函数
// handle next step in authentication process
ZDSecMgrAuthNwkKey();
_______________
if ( events & ZDO_DEVICE_AUTH )
[
ZDApp_DeviceAuthEvt();
// Return unprocessed events
return (events ^ ZDO_DEVICE_AUTH);
]
________________
认证的状态就从DEV_END_DEVICE_UNAUTH改成了DEV_END_DEVICE，如果是Router就开始启动Router建立过程。
——————————————————
如果MAX_DEVICE_UNAUTH_TIMEOUT还没有收到Transport Key或者Key不正确的话，那么就启动Reset过程
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 );
// The device has been in the UNAUTH state, so reset
// Note: there will be no return from this call
SystemResetSoft();
]
]
——————————————————
关于zgPreConfigKeys = TRUE和FALSE的区别，
zgPreConfigKeys = TRUE代表，设备中事先存储了Network Key，所以Trust Center并不会分发Key.
zgPreConfigKeys = FALSE代表，设备中没有事先存储Network Key，所以需要Trust Center来分发Key。

十分感谢各位的耐心解答，帮助我了解了加密验证的整个流程方法