我用的是官方库的  DHCP，然而官方的DHCP每次都是从DICOVER 报文开始，也就是说服务器重新给  芯片分配一个IP地址（不会优先使用原地址），在实际使用中由于网络的异常，芯片会多次请求DHCP，于是服务器会将剩余的IP地址耗尽，最终造成 芯片正常获取IP。当然原因可能   与DHCP服务器  也相关，但是我不能保证 客户在实际使用时连接的都是“DHCP服务器处理非常好的设备”。对于DHCP客户端来说，也有解决方法，例如 当芯片已获取过IP时，再次DHCP时，优先发送REQUSET报文，当接收服务器的NACK报文时，重新从DICOVER报文开始，若接收ACK报文时，就使用原IP，对于大多数常用设备确实是这样处理的（我补获过报文，我的客户也测试过）。然而 官方库是不提供源码的，与DHCP相关的就3个函数。我相信在未来会有很多人遇到跟我一样的问题（使用官方库）。目前咨询 微信群的官方技术，给的回答是  让我自己去实现，也就是说让我自己去重写DHCP请求（搞的我一脸懵逼），对于我这样只会使用 官方库函数的人来说 无疑是相当困难的。最后希望 官方能去优化一下这个DHCP获取流程。

您好，您的需求我们已经了解了，正在测试，其次并不是让您实现DHCP请求，而是能否在应用层通过主动关闭DHCP的方式或其他方式来避免服务器分配IP枯竭的情况，因为我们修改或添加功能需要较长时间测试，因此耗费时间相对来说会比较长，如果您比较着急的话可以尝试上述方法看能否临时解决，目前我们也在抓紧时间测试和解决您所说的问题。