某次编译烧写后，路由节点不能接收协调器发出的心跳包

路由节点不能接收协调器发出的心跳包，在组网成功几秒钟后，自动重新组网

這是你自己應用程序加上的邏輯嗎？

不是，我用的是2.5.1a版本里面sampleApp程序；组网过程和心跳包部分没有做代码修改；
从上面抓包截图中的最后一条数据可以看到，路由节点重新发送组网广播请求了

不是，我用的是2.5.1a版本里面sampleApp程序；组网过程和心跳包部分没有做代码修改；
从上面抓包截图中的最后一条数据可以看到，路由节点重新发送组网广播请求了

抓包截圖看不出什麼，請附上你的抓包檔

Ehoo_zigbee_data.psd

你協調器用的協議棧版本跟例程是哪個？

协调器用的也是zstack2.5.1a，例程也是SampleApp；

你用原始的SampleApp會有這個現象嗎？

是的！

刚刚烧录代码验证了一下，采用原始的SampleApp代码，现象是一样的；

原始代码上自定义配置内容：

协调器PANID固定为0xABCD；路由器默认为0xFFFF；

开启AES加密；

信道号设置为0x1A；

其他配置内容未做修改；

zstack2.5.1a版本比较老了，是否可以用zstack home 1.2.2测试一下

1，我们需要与第三方zigbee设备通讯兼容，第三方版本是2.5.1a；
2，目前我这边IAR版本只有8.10.1，好像不能兼容stack home 1.2.2；

我剛剛測試了一下2.5.1a沒有這個問題啊，你要不要重裝一次2.5.1a在測試一次

我怀疑是你的第三方设备有一个逻辑或者你自己加了一个逻辑进去，建议你只用demo去试一下。

重新安装后，此问题不再出现，我一步步排查问题吧！
非常感谢您的帮助！

非常感谢！
重新安装zstack后回复正常，正在一步步排查问题！

應該是你有改到協議棧的源碼造成的，你可以比對一下原始的源碼跟你修改過的源碼應該很容易找到問題

原因确认了，在开启AES加密后导致的该问题。

我在2.5.1a的原始代码中做了如下修改：

1，在f8wConfig.cfg中，-DSECURE=0 修改为 -DSECURE=1；

2，在f8wConfig.cfg中，修改DDEFAULT_KEY的值为

          -DDEFAULT_KEY="{0x01, 0x03, 0x05, 0x07, 0x09, 0x0B, 0x0D, 0xFF, 0x00, 0x02, 0x04, 0x06, 0x08, 0x0A, 0x0C, 0x0D}"

3，在ZGlobals.c中，修改zgPreConfigKeys的值为TRUE;

调试结果：

1，在第1，2部完成后，并且zgPreConfigKeys的值为FALSE的时候，协调器和路由器能够正常通讯；

2，在第1，2部完成后，将zgPreConfigKeys的值修改为TRUE的时候，协调器和路由器的通讯出现上面描述的问题；

也就是说你两个设备的AES加密不一致导致的。

可是我再三确认过协调器和路由器的f8wConfig.cfg文件中的DDEFAULT_KEY值是一样的啊；
而且在SampleApp的例程中，协调器和路由器不是共用一个f8wConfig.cfg文件吗？

如果没有使能uint8 zgPreConfigKeys = FALSE;的话，那么节点在入网的时候，Key是有父设备发送给子设备的。

#if defined ( DEFAULT_KEY )
CONST uint8 defaultKey[SEC_KEY_LEN] = DEFAULT_KEY;
#else
CONST uint8 defaultKey[SEC_KEY_LEN] =
{
#if defined ( APP_TP ) || defined ( APP_TP2 )
// Key for ZigBee Conformance Testing
0xbb, 0xbb, 0xbb, 0xbb, 0xbb, 0xbb, 0xbb, 0xbb,
0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa
#else
// Key for In-House Testing
0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07,
0x08, 0x09, 0x0A, 0x0B, 0x0C, 0x0D, 0x0E, 0x0F
#endif
};
#endif

代码里面有个宏定义DEFAULT_KEY，如果已经定义了这个的话，那么就不在使用下面的数组了。

DEFAULT_KEY定义在f8wconfig.cfg文档里面

/* Default security key. */
-DDEFAULT_KEY="{0x01, 0x03, 0x05, 0x07, 0x09, 0x0B, 0x0D, 0x0F, 0x00, 0x02, 0x04, 0x06, 0x08, 0x0A, 0x0C, 0x0D}"

good idea，有可能是NV的原因。

1，在f8wConfig.cfg中，-DSECURE=0 修改为 -DSECURE=1；

2，在f8wConfig.cfg中，修改DDEFAULT_KEY的值为

-DDEFAULT_KEY="{0x01, 0x03, 0x05, 0x07, 0x09, 0x0B, 0x0D, 0xFF, 0x00, 0x02, 0x04, 0x06, 0x08, 0x0A, 0x0C, 0x0D}"

3，在ZGlobals.c中，修改zgPreConfigKeys的值为TRUE;

以上三个步骤，我在父设备和子设备中都有设置的，在这种情况下，
zgPreConfigKeys的值为FALSE是可以正常通讯，如果把值改为TRUE，则不能正常通讯；

zgPreConfigKeys的值为FALSE时，key是通过父设备下发，此时可以正常通讯，这一点也已经验证过了；

我现在比较头疼的是，如果zgPreConfigKeys的值为TRUE，父设备和子设备都将采用本身设置的DDEFAULT_KEY；
而我将父节点和子节点的DDEFAULT_KEY值设置为一样的时候则不能正常通讯，不知道是哪里出的问题

，采用原始的SampleApp代码，现象是一样的；

原始代码上自定义配置内容：

协调器PANID固定为0xABCD；路由器默认为0xFFFF；

user5905923 你的問題是？