espressif
ESP32 WiFi driver softAP: DHCP server problems due to loss of UDP broadcast packages (IDFGH-11444)
Answers checklist.
- [X] I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
- [ ] I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
- [X] I have searched the issue tracker for a similar issue and not found a similar issue.
General issue report
Scenario: esp32 as AP Problem: clients have (re)connection problems
For years, developers have reported problems with the esp's DHCP server. Some scenarios can be reproduced and tackled (for instance, when a client holds on to the old lease after the esp has been rebooted), but in many other cases it's difficult or impossible to reproduce a problem as they occur rather randomly.
After days or rather weeks of intensive wireshark sessions, I started seeing a pattern: replies of the DHCP server get lost! The more traffic (other clients) and/or the weaker the WiFi signal, the more likely this occurs.
Quite often the following scenario happens: client sends a DHCP discovery or a request (with old lease's IP) ESP assigns IP (event is fired) but client does not receive the OFFER or the ACK.
Client typically times out and tries again, so (re)connecting can take a long time, or it gives up. Even the NACK after a request with an old IP gets lost sometimes.
I suspect the problem simply in the implementation of the WiFi driver, where "AP only caches unicast data for the stations connect to this AP".
It would be good to give the Wifi driver a higher priority, for years an ESP hasn't been able to reliably send UDP broadcast...
sorry for my late reply. most tests were done with idf 4.4. i went through the changelogs since 4.4 up to the latest version and did not see any DHCP-related changes nor work on caching in the WiFi driver. It is a known problem that UDP broadcast packets can easily get lost for stations that use power-saving modes (which basically all phones/tablets/laptops do) and I have observed that plenty of times.
After days or rather weeks of intensive wireshark sessions, I started seeing a pattern: replies of the DHCP server get lost! The more traffic (other clients) and/or the weaker the WiFi signal, the more likely this occurs.
Quite often the following scenario happens: client sends a DHCP discovery or a request (with old lease's IP) ESP assigns IP (event is fired) but client does not receive the OFFER or the ACK.
@ch-fb Could you share the wireshark log?
haven't saved them as I had wireshark runnig for hours in the background and I just looked at the recent entries whenever some connection problem happened again. But what it shows is that DHCP broadcast packets sometimes don't arrive (OFFER or ACK). It seems the ESP sends them (or at least it fires the according events), but they don't arrive.
Losing UDP broadcast/multicast packets when the ESP is in AP mode isn't a new issue, it has been observed many times also by others. To best reproduce the issue, you should have a busy network (plenty of traffic with other clients).
We actually gave up using the ESP for one of our products because of that issue as our application needs to send high-traffic UDP broadcast (continuous real-time data). Unfortunately, the ESP manages to deliver only a part of that data. I personally noticed the problem also for mDNS packets.
For a softAP that manages 4-10 clients, the proper caching of UDP broadcast/multicast packets isn't a very difficult task. It would be really important to implement that in the WiFi driver soon.
haven't saved them as I had wireshark runnig for hours in the background and I just looked at the recent entries whenever some connection problem happened again. But what it shows is that DHCP broadcast packets sometimes don't arrive (OFFER or ACK). It seems the ESP sends them (or at least it fires the according events), but they don't arrive.
Losing UDP broadcast/multicast packets when the ESP is in AP mode isn't a new issue, it has been observed many times also by others. To best reproduce the issue, you should have a busy network (plenty of traffic with other clients).
@nishanth-radja @Xiehanxin Is above symptom a known issue?
yes, I have seen a a few bug reports. But it is even mentioned in the official ESP documentation for the WiFi driver (regarding WiFi power-saving/sleeping modes): https://docs.espressif.com/projects/esp-idf/en/stable/esp32/api-guides/wifi.html#ap-sleep
@ch-fb sorry for late reply you can try this patch 0001-fix-lwip-Modify-the-DHCP-offer-and-DHCP-ack-from-bro.zip In the original code, DHCP Server uses IP broadcast address to send DHCP OFFER and DHCP ACK. Actually, The DHCP Server need to check the fields in the DHCP BOOTP, and then determines whether to send DHCP OFFER and DHCP ACK by using IP broadcast or IP unicast. This feature is to implement it.
thanks for your work, that should help with some DHCP problems. However, this is more of a workaround than a solution, as the ESP still cannot sent UDP broadcast/multicast reliably, so problems continue to happen in mDNS and other services. Work is needed in the softAP WiFi driver to implement low-level buffering to ensure packets are delivered, this probably also requires a better ARP integration to really know all clients (not just DHCP clients but also those with static IPs or clients that hold on to an IP from an old/previous DHCP lease (happens after ESP reboot).