joseph_ji wrote: ↑

Fri Jun 09, 2023 9:05 am

我测试用的demo是由station例程修改而来的，这边也附上来：

请问你们是否有复现现象？

我测试用的demo是由station例程修改而来的，这边也附上来：

场景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；

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

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

从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) 正确执行fast_dhcp.PNG 然后我多...

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

对你的应用来说，打开配置项 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），而...

环境相关 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左右的时间；在论坛上 https://www.esp32.com/viewtopic.php?f=25&t=27252&hilit=%E5%BF%AB%E9%80%9F%E5%88%87%E6%8D%A2ap 该帖子下，有...

请问有复现现象了吗？是否是接收广播包所致呢？这个功耗指标对我们的低功耗的项目比较重要，麻烦回复一下，感谢.