Comment 9 for bug 1727237
Revision history for this message
| Mathieu Trudel-Lapierre (cyphermox) wrote | #9 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
0e1f616
(Get the code!)
So I managed to reproduce this in a way that looks correct (Starbucks WiFi here uses Datavalet but fails in a way that looks the same: it thinks you're logged in once you clicked the "Login" button on the captive portal page once, but then updates DNS, but still attempts to look up secure.datavalet.io (but this is no longer resolving because we're in the public side now); and once you try to hit another site, you did not get to the "landing" page on the public side so it thinks you're still unauthenticated.
One one hand, this looks like just really terrible behavior of the captive portal, and it "worked" only because we were pretty slow to deal with the changing settings; or because we were caching the DNS responses for just long enough.
I got logs from my reproducer as well as packet captures, and I will have to comb through them to figure out if there's anything really obscure and wrong, but my initial guess is that this is an issue related to DNS caching. Probably the cache is invalidated when the IP changes as we get to the public side, but ought to retain the resolution address for the portal.
It needs a little more investigation and testing, but I think this qualifies as "Triaged" now; and should have some fix or workaround to deal with Aruba and Datavalet, both are reasonably common hotspot infrastructure.