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.
** Changed in: systemd (Ubuntu)
Status: Confirmed => Triaged
** Changed in: systemd (Ubuntu)
Importance: Undecided => High
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1727237
Title:
systemd-resolved is not finding a domain
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1727237/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
