求助：关于zstack加密通讯的验证问题
协议栈版本：Z-Stack Mesh 1.0.0
有关加密的编译选项：
-DSECURE=1
-DZG_SECURE_DYNAMIC=0
uint8 zgPreConfigKeys = TRUE;
拿一终端和一协调器进行实验，当双方的DEFAULT_KEY相同时，终端可成功入网并且双方可正常通讯，抓包可看到通讯过程与程序运行流程一致，内容也进行了加密处理；
当双方的DEFAULT_KEY不相同时，终端入网后并未因验证失败而进行自动复位，抓包时发现终端成功入网且分配到网络地址，也能向协调器发送数据并得到ACK应答，但协调器却不会向终端发送回应的数据包（自己设定的回应数据包），估计原因为双方DEFAULT_KEY不同，协调器只在MAC层接收到了数据包然后进行了过滤；
打断点调试终端，发现终端在入网成功后，并未进入“devState = DEV_END_DEVICE_UNAUTH;”的状态，原因为函数ZDApp_ProcessNetworkJoin( void )中的条件判断语句if ( ZG_SECURE_ENABLED && ( ZDApp_RestoreNwkKey() == false ) )中的ZDApp_RestoreNwkKey()结果为true，因此跳过了devState = DEV_END_DEVICE_UNAUTH;和ZDApp_ResetTimerStart( MAX_DEVICE_UNAUTH_TIMEOUT );语句，导致在双方DEFAULT_KEY不相同时终端也没办法进行自动复位；
按照我对加密通讯的理解，在使能了加密通讯后，终端成功入网后应该会有个验证，验证不正确或超时会有自动复位的功能，但跟踪了终端的整个入网流程后并未发现应该如何触发这个验证机制，还是我的编译选项有误或是不足？希望能得到大家的帮助，谢谢！
本问题比较急，希望能尽快得到大家的帮助，能给出一点思路和建议，谢谢！
麻烦把整个过程的抓包文件保存下来，用附件上传下。
正常情况下，如果配置了 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的时候却不能重启，请问这是什么问题呢
请问一下你的有关加密的预编译选项以及配置是怎样的？能发出来看一下吗？我的情况是即使-DSECURE=1了，密钥不一致并不会重启，所以有疑问。你的如果是-DSECURE=0的话是不会重启的，因为在此情况并没有开启加密验证机制。
就是按照你的这个步骤啊
-DSECURE=1
-DZG_SECURE_DYNAMIC=0
uint8 zgPreConfigKeys = TRUE;//FALSE;
然后秘钥一致，协议栈版本2.5.1a，其他并没有什么特殊处理
@guozi,
好的，谢谢，第一种方法我尝试过是可以的，只是对终端编译了加密选项后密钥不一致也不会自动重启感到疑惑，按照网上的一些说法，在终端编译了加密选项后若密钥不一致是可以自动重启的，我比较想知道的是如何触发这个机制
@LoveLee,
有没算过大概多长时间后自动重启？设备是终端吗？有设置低功耗吗？能上传一下设备入网到自动重启的这个过程的抓包文件给我观察一下吗？谢谢
我这边没有抓包的工具和设备。。 时间的话大概5s多重启吧 、 设备类型是路由，并没有低功耗
好的，谢谢，我再重新实验过
秘钥不一致 总要有两个 主动秘钥做比较， 无论你使用 有TC分发的方式 还是预配置方式，设备上只有一个nwkKey没办法做比较，网上那种说法不适用上述过程；
设备重启 动作 是入网设备在等待是 在TC分发key时超时触发的，设备特定时间没有拿到key 会 循环上述入网过程；
预配置方式 没有触发 超时等待的过程，不会有上述原因导致的重启过程；
好的，谢谢，我想请教下采用TC分发key的方式相比预配置的加密方式的优势在哪？仅仅只是多了个验证比较过程吗？安全性会高一点吗？
TC分发： 可以共用TCLK ， newkey由协调器分发 给 各个厂家的 入网设备，主要用在设备兼容组网的场景；
预配置key： 没有key分发的过程，相对安全性要高，如果使用预配置key基本构建私有网络场景多；
好的，谢谢，我还想请教一下TC分发key的流程是怎样的？是终端入网后等待协调器发来key，如果等待超时仍未收到key就自动复位这样子吗？如果是这样子的话那协调器是如何验证入网的设备是否是正确的设备呢？如果环境中同时有几个协调器，终端如何验证入的网就是正确的呢？还是说终端会对协调器发来的key进行验证，如果不正确仍会自动复位，同时协调器端也会对入网的设备进行验证，只有设备通过了验证协调器才会发送key过去?
@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。
十分感谢各位的耐心解答，帮助我了解了加密验证的整个流程方法