Repository navigation
Conversation
WalkthroughOn ESP32, ChangesmDNS and Wi-Fi reconnection
Estimated code review effort: 2 (Simple) | ~8 minutes Change: Bug fix Possibly related issues
Possibly related PRs
Suggested labels: Suggested reviewers: Merge Risk:
|
|
thanks, the change looks reasonable. Needs testing on a real -C5 (and on -S3 for regression tests) before merging. |
|
@coderabbitai are there other protocol handlers that should be stopped before Wi-Fi teardown, for example asyncWebserver? |
|
Tip For best results, initiate chat on the files or code changes. Analysis chain
The best candidate for further investigation is E1.31 multicast. Other services worth checking are the UDP receivers, MQTT, and the captive-portal DNS server. Before merging, I recommend the requested real ESP32-C5 and ESP32-S3 tests. Exercise repeated reconnects with active HTTP/WebSocket traffic and E1.31 multicast, then verify service recovery, including AP fallback. I have not run those tests. Learnings used
You are interacting with an AI system. |
Hello and thank you for taking a look at it, currently i do not have an ESP32-C5 or an s3 to test it on which is why i went for an emulator testing .so i was wondering if someone with an actual board could possibly test it ?ill update the pr according to the result. |
What it does
The issue was that when an ESP32-C5 switches the Wi-Fi band and reconnects, the board could crash, and a reboot fixes it. So what we did is stop mDNS before the Wi-Fi interface is destroyed. It is started again once the board has reconnected.
Additional references and context
How it works
We updated
initConnection()inwled00/wled.cpp. BeforeWiFi.disconnect(true)it callsMDNS.end(), only ifinterfacesInited && strlen(cmDNS) > 0, meaning mDNS is actually running. It is inside#ifdef ARDUINO_ARCH_ESP32, so ESP8266 is unchanged. No restart code was added, becauseinitInterfaces()already callsMDNS.end()andMDNS.begin()once the board is connected.AI assistance: yes
Testing and Validation
Emulator: first we tested the unchanged code to recreate the error. It panicked on cycle 2 of 10 (backtrace:
join_groupin mDNS). With the change, there were no errors in three runs of 10 cycles. The emulator has one band, so there was no real 5 GHz connection. A temporary test harness triggered the band change and is not part of this PR.Checklist
Summary by CodeRabbit