ESP32 Forum

环境相关
1.硬件：esp32-c3-devkitm-1
2.idf版本：v5.0.1 编译环境：linux
3.软件：基于esp-idf\examples\wifi\getting_started\station修改，详见附件；
需求描述：
因为低功耗项目需求，需要设备唤醒后可以快速连接上ap，我用station例程测试，发现wifi断掉后再重新连接，需要1.3s~1.4s左右的时间；在论坛上 viewtopic.php?f=25&t=27252&hilit=%E5%BF ... E6%8D%A2ap 该帖子下，有看到说可以设置ap的信道和bssid可以缩短连接时间(连接同个路由器100ms？)，我这边尝试设置修改，效果并不明显（时间依然1.3s左右）；麻烦指导一下，谢谢。
日志截图如下：

对你的应用来说，打开配置项 component config -> LWIP-> DHCP: Restore last IP obtained from DHCP server 应该帮助比较大，这会省去 DHCP 的过程。另外，这几个打印关掉也会提高一点点速率

yake827 wrote: ↑

Fri May 19, 2023 9:19 am

对你的应用来说，打开配置项 component config -> LWIP-> DHCP: Restore last IP obtained from DHCP server 应该帮助比较大，这会省去 DHCP 的过程。另外，这几个打印关掉也会提高一点点速率

yake827:
感谢回复，我这边按照你的建议开启了DHCP: Restore last IP obtained from DHCP server这个配置，然后设备刚启动确实是有效果的，连接时间达到了300~400ms左右，但是设备长时间运行（期间我有让设备多次断连重连wifi），会在某一刻连接时间忽然又变大（大到秒级1s~2s），而后每次断连重连wifi，时间都没再缩短回几百毫秒；重启设备，连接时间又可以恢复到300~400ms；这个现象你是否知道是怎么回事吗？

设备在此之后连接时间变长了： 重启之后，连接时间又恢复了： 详细日志在附件log.txt

从LOG看，似乎是 DHCP 的流程太长了，最好能够抓个WiFi的包看看这时候发生了什么，抓包如果用MAC可以直接抓（https://zhuanlan.zhihu.com/p/498119076?utm_id=0），如果ubuntu 或者windows，则需要专门的抓包卡才可以

yake827 wrote: ↑

Wed May 31, 2023 9:37 am

从LOG看，似乎是 DHCP 的流程太长了，最好能够抓个WiFi的包看看这时候发生了什么，抓包如果用MAC可以直接抓（https://zhuanlan.zhihu.com/p/498119076?utm_id=0），如果ubuntu 或者windows，则需要专门的抓包卡才可以

你好，我这边做了如下抓包工作：我用电脑发射热点，然后使用esp32c3连接该热点，在电脑上使用wireshark进行抓包；可以看到在设备正常执行fast_dhcp时，只发送request包，这时request报文里带的ip地址是正确的(这里是192.168.137.66) 然后我多次执行light_sleep（休眠时wifi_stop，唤醒后再wifi_start），在执行几次之后，设备fast_dhcp就失效了，这时看到抓到的dhcp request报文里带的ip地址就不对了(这里是192.168.11.122)，设备发送了两次request报文之后，便又重新执行一遍完整的dhcp流程，之后再重连wifi，其dhcp流程就一直如此； wireshark完整抓包数据见附件；

OK，那问题基本上就找到了，跟light sleep没关系，如果我没猜测的话，你们这个局域网段存在一个 192.168.11.xx 的路由器，可能这个路由器是作为 LAN口连到主路由器的，或者它作为更上级的路由器。
这个问题原因在于我们在某一次DHCP request的时候没有收到回复，因此我们重新发送了 DHCP discover报文，但是这个 192.168.11.xx 的路由器DHCP server给我们分配了IP，所以你才会看到这种情况。
你可以试着把网段内这个路由器的 DHCP server给关掉，试试还会不会有这个问题

yake827 wrote: ↑

Tue Jun 06, 2023 8:58 am

OK，那问题基本上就找到了，跟light sleep没关系，如果我没猜测的话，你们这个局域网段存在一个 192.168.11.xx 的路由器，可能这个路由器是作为 LAN口连到主路由器的，或者它作为更上级的路由器。
这个问题原因在于我们在某一次DHCP request的时候没有收到回复，因此我们重新发送了 DHCP discover报文，但是这个 192.168.11.xx 的路由器DHCP server给我们分配了IP，所以你才会看到这种情况。
你可以试着把网段内这个路由器的 DHCP server给关掉，试试还会不会有这个问题

这个是我们的局域网的网络拓扑结构，我们这边的路由器都是平行接入交换机再连接到外网的，路由器1的LAN口ip地址就是192.168.11.1；而我的电脑是通过wifi接到路由器2（192.168.1.1）上的，电脑再发射热点（192.168.137.1），然后设备esp32c3最终是接入电脑的热点的；这种结构按说11.1的路由器1 DHCP Server是不会给设备分配IP的

我这边还做了些测试，然后发现，目前的现象应该分两种情况来描述：
场景1：设备之前没连接过其它ap，即只连接我的电脑热点（192.168.137.1）的情况下(download前先擦除erase确保没存其它wifi信息)，设备dhcp request是不会请求到其他ip去的，但是设备多次重连wifi后，dhcp的过程依然会完整执行(fast dhcp失效)，详见wireshark报文1；

场景2：设备之前连接过其它ap（比如我手机的热点192.168.43.1），然后再重新烧写固件(新固件配置wifi连接到pc热点)，连接到我的电脑热点（192.168.137.1），这种情况，设备多次重连wifi后，会出现dhcp request请求到43.xx网段的ip，也就是跟之前请求到11.xx网段的情况一样；所以我猜测是不是设备有缓存前一个旧的wifi的信息，而且dhcp request报文用了旧的ip地址？同样，一旦出现fast dhcp失效，后续几次连接dhcp一直是完整流程。详见wireshark报文2；