davesteele
commented
4 years ago That code uses a DNS server that returns the same IP address for all queries. Comitup does that, and also sets a DHCP option that defines the captive portal URL.
The other wrinkle is defining some magic pages on the captive portal web site. The Arduino code returns special content for the following (otherwise sends a default redirect message):
- /
- /generate_204
- /fwlink
In each case, the special content is a 302 redirect, unless the server is not in "captive portal" mode, in which case it returns a simple page. Comitup shuts down the web site i once connected.
There are headers to discourage page caching, which Comitup does not do.
In short, there is nothing there to suggest a method to make the initial captive portal page come up more reliably. They might hint at how to exit captive portal mode more cleanly, should that be necessary.
As far as Comitup goes...
After calling up the webpage on Comitup with Android and IOS, I see 302 responses to:
- /generate_204
- /hotspot_detect.html
- /success.txt
There is a bug causing favicon calls to return a 500. That's unlikely to cause a problem here
Sometimes the Captive Portal doesn't come up automatically and I have to go to 10.41.0.1 manually. I fiddled around with an ESP8266 the last few days for another project and came across this little gem: https://github.com/esp8266/Arduino/blob/master/libraries/DNSServer/examples/CaptivePortalAdvanced/CaptivePortalAdvanced.ino And that Captive portal shows up every time on all devices. So maybe they use a different technique and it's worth copying it?
cheers