This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
我尝试加入mac验证，但是当多个路由/终端同时开启的时候，只要有一个路由器的MAC地址在白名单里面，协调器就会加入全部的设备。
而单次间隔一小段时间后上电就可以区分。有什么办法可以在同时上电的情况下区分白名单吗？
@xx,
没太明白你的意思，能再描述下么，谢谢！
那个函数里面加了一个extendpanid验证，如果不合适，返回失败值
我现在已经把白名单机制做得很完美了，不知道你们是什么问题？
1，你们在ZDO_JoinIndicationCB上面加入MAC地址验证，是正确的做法，不过这个函数会在所有FFD设备上发生，所以路由器的代码中，也必须加入这个验证机制。
2，ZDO_JoinIndicationCB能识别三种加入网络模式，MAC Associate，NWK Rejoin，NWK Secure Rejoin，你需要针对这三种模式做判断，通常做法是指针对MAC Associate进行判断。
3，如果节点是通过路由器来加入网络，那么路由器还应该通知其它设备，其实白名单的数据库可以不设置在协调器上，比如ZLL那种模式，可以把白名单数据库分布存储在各个FFD节点上。
一语点醒梦中人，我知道问题出现在哪了，就是2这种情况
我在另一个帖子中分享了白名单的完美解决方案
http://www.deyisupport.com/question_answer/wireless_connectivity/zigbee/f/104/t/80933.aspx
ZDO_JoinIndicationCB函数始终返回Zfailure，但是抓包工具显示子节点有发送Data Request 和NWK Rejoin，可以解释下这个过程吗
前辈你好
我是刚入门的新手，我想解决白名单入网问题，我看了你发的那个关于白名单的解决方法，但是看不太懂，能否发给我一份源代码，或详细的文档资料
还有你在文章中提到的.lib库在在哪里下载啊，能一同发给我一份呢？感激不尽
我的qq邮箱是2840824715@qq.com
可以参考这个：http://www.kaleidscope.cn:1020/archives/2678
节点的Mac地址就是节点的身份证，认证过的才能通过ZDO_JoinIndicationCB函数加入网络层实现数据的传输。其实白名单就这么简单.
谢谢你回答我的问题，但是你只讲了思路，且没有详细讲怎么操作程序，我是刚接触zigbee的，可以详细讲讲你的实现流程么，可以看看你的源程序么，感激不尽了，
小伙子太狠了，上来就要白名单源代码，你出20W人家估计考虑给你。
什么20W，我自己实现了，很难么？
没看懂怎么实现？页没看懂你那篇白名单怎么实现？
我想实现的是当有子节点加入时，父节点能都知道，并能知道他的MAC地址和短地址，当它离网时父节点也能知道，怎么实现呢，希望前辈指教
https://e2e.ti.com/support/wireless_connectivity/zigbee_6lowpan_802-15-4_mac/f/158/t/17280
1.一般默认的配置都是网关给协调器发送允许入网指令。然后协调器广播所有的路由设备都处于允许入网状态。
那么白名单那么大，如何让所有的路由节点都知道呢？因为设备也可能从路由设备入网啊，协调器的白名单是可以很方便的又串口发送，但如何网络中路由几点很多，如何让路由也有白名单呢？
2.难道只让协调器自己处于允许入网状态吗？协调器的关联表有限啊，如果组建的网络很大，白名单也放不下啊？
3.如果只在协调器设置白名单，并且只有协调器允许入网，那么入网后的设备可能自己根据网络情况改变到其他的父节点吗？
帅哥，密码是多少呢
我现在也已经把白名单做的很完美了，对于你说的问题我可以解答下：
首先肯定不能使用广播的形式，设备入网的时候，并不是一个一个线性入网，而是并发的，如果使用广播，首先这就是不合理的。如果要让路由有白名单，我现在是分布式的，每个路由上的白名单都不一样。
现在我做的基本是这样的：
1、所有的有路由能力的设备，都可以对申请入网的设备通过MAC地址进行鉴别。
2、路由会缓存白名单，但并不是所有允许入网的白名单，并且具有超时机制，以免浪费内存。
3、设备rejoin的时候可以直接加入，设备掉网后，如果是rejoin，是可以直接加入的。
具体的话可以看看我的这篇帖子深入了解：http://www.kaleidscope.cn:1020/archives/2678
