TI中文支持网2.5.1a
NWK_MAX_DEVICE_LIST 20
协调器的关联表AssociatedDevList成员21个。其子节点普通终端21个。但实际测试结果是19-21个都有可能。
经测试第21个单独反复入退网，未见异常，串口输出的关联表成员的短地址也正确。
但若退出1个，有2个（1个刚推出的1个新设备）同时入网就会有较大概率失败，抓包看到同时入网的设备都在申请关联Association Request，但就没有后续的announce，并没有入网成功。并且串口输出协调器关联表这1个位置却生成了一个短地址，导致再也无法加入新的设备，同时刚才申请入网的2个设备执行了函数joinconfirmcb，没有入网，即使都删除nv，其中的在协调器关联表生成短地址的设备也不能入网。结果协调器的子节点就只有20个了。我想19个也大概是此情况。
有时候这21个有掉线的，却再也加不回去了，即使清楚nv。
请问NWK_MAX_DEVICE_LIST设置20，协调器的子节点最大多少个呢？不包含路由节点。
是否关联表中有这个终端设备，该设备就是以孤儿方式加入呢？删除nv的设备重新入网时候不是应该用mac地址以关联方式加入网络吗？
协调器的关联表成员并不是路由节点，如何知道他不是正常的离线，而删除那些有问题的节点呢，从而保证有新节点能加入网络呢
总之就是在表满的情况下，其中的掉线的终端不能再次加入网络。即使终端删除自己的nv以新设备的身份也不能加入网络。（需要另外一个空位才能加入）
VV：
你的抓包文件呢
user4381970：
回复 VV:
我用ubiqua抓包的，上面我说的可能不是太清晰，我再补充说明下。
如图，设备入网时候抓包看见先关联申请，而协调器貌似并没有应答ack，（正常我抓包会看见应答transition key），终端入网失败后还会beacon request。但此时协调器关联表已经生成了这个设备的短地址，若此时刚好是最后一个位置则，再也不能有设备能入网了，除非先空出位置来，让该设备入网，此时他会在关联表刚才的位置上。再加入哪个倒出位置的设备才能让协调器的子设备刚好是NWK_MAX_DEVICE_LIST+1的数量。有时候设备掉线后也加不进网络可能也是这个可能。
若上述现象多次发生这个网络中是满设备的（不包含路由），将导致理论最大数量是21个，实际只有20,19（甚至更少）。我也查询过一些帖子说父设备要及时删除离开的子节点的关联表内容。但实际上有些设备可能只是暂时掉线，他会重连，即使重连失败，待用户发现掉线时候，用户手动让该设备去寻找网络。所以父设备不能确定什么样的子节点是真正有问题的节点从而去删除他的关联表内容。
问题就是有设备入网时候关联请求后，父设备不是先看mac地址是否存在吗？存在则占用这个位置，不存在则查看是否还有资源吗？没有资源则不应答，有资源则应答子设备。子设备根据这个应答来决定继续下一步还是重新搜索吗？
user4381970：
回复 VV:
这个更清晰。麻烦VV看看这个吧。这个是我重置的协调器，里面没有任何设备，#define NWK_MAX_DEVICE_LIST 3。所以最大设备4个。
抓包（306行）能看见分别是8f70 c424 e1f3 0581.然后这些设备每3秒poll一次。直到1101行，我退出0581设备。1145行协调器允许入网，1158行该设备申请关联，申请了2次都失败了，（1162行橙色的自字体是什么意思呢？我一直不明白，捎带问问）
下面是串口输入的关联表成员的短地址：
1：8f70c424e1f3ffff。这个是0581退网后，重新入网，协调器允许入网时刻的状态，证明是有一个空位置的，刚才的确退网删除成功了，
2：8f70c424e1f3f817。这个是0581重新入网失败后，协调器关闭允许入网指令时刻的状态，原来的0581已结生成了新的短地址f817，但此时端末并没有入网成功，执行了ZDO_JoinConfirmCB，并且失败。
user4381970：
回复 user4381970:
大神快来帮我看看吧。是否与有些设备掉线后一直重连不上有关系呢
user4381970：
回复 user4381970:
求救
