dnsServer objects are not freed correctly; captive portal will fail a second time on demand.

[mattbradford83]

Hi @alanswx,

I recently worked on another library which was a fork of yours, and noticed that calling wifiManager.startConfigPortal(...) twice within a script without a reboot will not bring up a captive portal a second time. I traced this to the way that DNSServer was being disposed of in your AsyncWiFiManager::startConfigPortal function. Within the DNSServer object, there is a stop() function which will correctly stop the WiFiUdp server that it uses. If this server is not stopped correctly, the chip OS will hold on to port 53 and will not allow it to be used a second time.

Additionally, the call to dnsServer->start(...) does return a boolean indicating whether or not it was able to begin listening on the correct port; adding a debug message based on the result will at least help in troubleshooting the issue. Without calling stop(), the dnsServer->start(...) function does indeed return false the second time around.

Platform: ESP8266 Environment: PlatformIO on Windows 10 Mobile Device used for testing Captive Portal: iPhone XR, IOS 14.4.2.

The snippet required to demonstrate this is attached. Compile and run on an ESP8266. It will start a captive portal, use as expected and join the WiFi. The captive portal will eventually close; the code will initialize a second captive portal instance after 7 seconds. The mobile device can join the WiFi, but the captive portal never appears. Implementing the fix attached corrects this behaviour.

main.zip

[alanswx]

Can you do another PR and increase the version number. Thanks