Workaround for some captive portal issues -
Craig Carl last edited by
I did a lot of traveling in the last month (6 hotels). I ran into two hotel WiFi networks I couldn't authenticate to via the Teleport's WiFi network. I had time to do some troubleshooting, this workaround was effective for both of them. The captive portal behavior (302 redirects) that surfaced the issue was also the same in both. Neither hotel I saw this in was one of the major chains but I expect this isn't uncommon.
The Teleport is setup and working properly absent this issue. Both the Amplifi Hub and Teleport device are running the latest versions of FW as of August 21st.
The issue I'm seeing is with authenticating via some, but not all, captive portals. I've been able to reproduce the issue on several. I think it's a bug in the Teleport device. Specifically, if the captive portal process includes a 302 redirect to a different domain name the DNS lookup on that second domain name fails. This results in a "ERR_NAME_NOT_RESOLVED" error in Chrome or "curl: (6) Could not resolve host: <target of redirect>" error via bash/curl.
I think the bug is -
The Teleport device, while in "Authenticate via the captive portal" mode is only resolving the first DNS request, additional requests fail. The requests hang before they fail, this indicates that the DNS server service on the Teleport hasn't crashed entirely, there is something else going on.
- I connect my laptop directly to the Wifi network with the captive portal.
- Open the Chrome developer tools and record the network traffic while completing the captive portal process. Stop recording when complete.
- Identify the target of any 302 redirect(s).
- Use nslookup to resolve the IP address(es) of the 302 targets.
- Edit the hosts file on the laptop (/etc/hosts on macOS) to include those domain names and IPs.
- By default Chrome ignores /etc/hosts. Turn off "Protect you and your device from dangerous sites" in Chrome's Advanced Preferences to change this behavior. Alternatively I think (haven't tested) that Safari will work without any changes.
- Flush the DNS cache -
sudo killall -HUP mDNSResponder.
- Clear browsing data for the last hour.
- Connect to the Teleport's WiFi network.
- Complete the captive portal process again.
I no longer have access to the captive portals I was using to test this, they were in hotels. You should be able to repro this behavior -
- Setup a 802.11 network that includes a captive portal at <domain name A>.
- The web page at <domain name A> the captive portal uses should be a 302 redirect to a page at <domain name B>.
Mike Gregory last edited by
i have the same issue in a holiday inn here in eindhoven, but i dont have the minerals to jump through the hoops as you have done.
This stuff is meant to be simple!
Joshua Newton last edited by
This worked for me for my office. Using Safari I did not have to make any changes once I added the information into my hosts file.
This should be address by Amplifi to help with captive portals if possible.