This repository has been archived by the owner on Feb 4, 2023. It is now read-only.
Allow captive portal to run more than once by closing dnsServer cleanly. #49
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hello,
I noticed that if the Config Portal is started more than once by calling
startConfigPortal(...)
without rebooting the device, then only the first instance functions as a captive portal; at least within 10 seconds of each other.This is due to the fact that the
WiFiUdp
object inDNSServer.h
is never told tostop()
, and so the OS holds on to port 53. The result ofdnsServer->start(DNS_PORT, "*", WiFi.softAPIP());
inESPAsync_WiFiManager::setupConfigPortal()
is never checked; this will returntrue
if it can secure the port,false
otherwise. If you check the result ofdnsServer->start(...)
for the second call tosetupConfigPortal()
, you'll see that it returnsfalse
.The easiest way I found to fix this was to replace
*dnsServer = DNSServer();
instartConfigPortal(...)
withdnsServer->stop();
. This will correctly finalise theWiFiUdp
object and free up the port for next time.I'm running this library on a ESP8266 D1 Mini, through PlatformIO.