嗨、社区!
我最适合回答 的人是 Michael Reymond。 因为他已经关注了相关主题。
嗯、我们尚未实施建议的解决方案。 我们只需将租赁时间设置为17天。 我们看到同样的问题(在不到17天的时间内、租赁时间可能不会过去)。
1.您是否看到其他可能发生此行为的情况?
2.您是否有自动刷新 ARP 表的确切时间?
谢谢!
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.
嗨、社区!
我最适合回答 的人是 Michael Reymond。 因为他已经关注了相关主题。
嗯、我们尚未实施建议的解决方案。 我们只需将租赁时间设置为17天。 我们看到同样的问题(在不到17天的时间内、租赁时间可能不会过去)。
1.您是否看到其他可能发生此行为的情况?
2.您是否有自动刷新 ARP 表的确切时间?
谢谢!
您好!
存储在 CC3220 ARP 表中 的 ARP 条目将在14400秒或4小时后过期。 此时、ARP 条目将标记为过时、CC3220将根据需要向该 IP 地址发送另一个 ARP 请求。
假设您已将 DHCP 服务器的租用时间设置为17天、则 CC3220 ARP 条目应过期、然后再重复使用 IP 地址。 因此,我不知道为什么即使在调整 DHCP 服务器后,您仍然会看到同样的问题。
您是否能够执行监听器捕获以查看完整的 UDP 数据包交互流程?
此致、
Michael
您好、Michael、
感谢您的快速回复!
我试图重现,但没有成功。
这对我也没有意义、因为 DHCP 服务器不会提供未过租赁时间的地址。 在特殊的"STA 断开连接"情形中、AP 是否可以释放 IP (而不更新 ARP 表)? 只是猜测一下这里...
如果我可以重现、我将通过一些 NWP 日志和 WiFi 嗅探返回给您。
同时、我们每 10秒调用一次 API sl_NetAppArpFlush()……
此致、
文森特