> On 8 Mar 2021, at 14:08, Steve Litt <sl...@troubleshooters.com> wrote:
> 
> Rick Moen said:
> 
>> The above is a vexing problem for travelers w/laptops who prefer to
>> specify their own choice of nameserver and still use hotel/motel WiFi
>> (and wired ethernet, actually).  Best case, you have to disable your
>> nameserver IP override long enough to navigate the captive portal, and
>> then can put the override back.  But, no, you cannot just leave your
>> choice of nameserver IPs in place (without disappointment).
> 
> This is good information. I've sometimes wondered why I couldn't log in
> at the library or Macdonalds.

And the other thing they screw up is that by redirecting you, nothing presents 
the right certificate ! I hate using such public connections because it's so 
much hassle remembering to put every bit of software into offline mode first - 
if you don't then I get a flurry of certificate warnings and it can mean 
quitting and re-opening software for it to pick up the now correct IP address. 
But if it's a choice between that or nothing then ...

The process is simple enough. When you are not an authorised user, the captive 
system responds to every DNS request with the IP of it's captive portal. For 
HTTP requests that's simple enough - you get their portal page instead of what 
you were asking for. Once you've signed in (and possibly had to pay for it !), 
then you get the right IP addresses returned.
But of course, your system has cached the wrong address and may or may not 
flush it in a timely manner. Your browser has cached the portal page instead of 
the real page (assuming it was an HTTP request). And everything using secure 
connections, gives you certificate errors.
That latter point means that you go to https://myfavouritewebsite.com and no 
you don't get the portal page - you get a certificate warning. Given that most 
people these days will have https URLs cached in their browser, you have to 
manually and explicitly try and connect to a site (doesn't matter what, any 
random URL will do) over HTTP.

Simon

_______________________________________________
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Reply via email to