Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.linux.networking > #4091

Re: Captive portals ignore some URLs

Show all headers | View raw

On 2017-09-27, Moe Trin <ibuprofin@painkiller.example.tld.invalid> wrote:

> On 24 Sep 2017 22:52:45 GMT, in the Usenet newsgroup comp.os.linux.networking,
> in article <oq9cvt02pcf@news4.newsguy.com>, Charlie Gibbs wrote:
>
>> Many captive portals seem to be picky about which URL you initially
>> try to access.  If it isn't a well-known site like Google, many
>> portals will silently ignore any attempts to access the site, and
>> the browser will hang.
>
> Not enough information.    Find a command line and run

I just went to a location that has a captive portal I've used in the past,
and ran some experiments.  At first I just opened my laptop and didn't try
to access anything:

> /sbin/ifconfig wlan0  (or what-ever)
>   does your system have AN IP address on the wireless interface?

Yes.

> /sbin/route -n
>   does your system have a "route to the world" (0.0.0.0/0) using some
> locally reachable host as a router?

Yes.

> cat /etc/resolv.conf
>   does your system have an address of a name server?

Oops, forgot to do that one.  No matter, because...

> host www.ibiblio.org           or similar
>   does your system resolve that to an IP (here, 152.19.134.40)

Yes - the same IP address, in fact.

> Point your browser (what-ever that is) at www.google.com, AND THEN
> look at the output of  /bin/netstat -atn
>   does a connection exist?   If so, does the IP on the far end
>   resolve to some host in google.com land?  Or it is some proxy
>   trying to fake it?  Note that an over-advertised site like google
>   will also have eleventyseven other links to content/ad servers.

Instead of www.google.com, I tried http://duckduckgo.com.  The browser
(Seamonkey under Debian) turned this into https://duckduckgo.com
(perhaps because that's what's in my history), and hung.  The relevent
lines from netstat at this point were:

Proto Recv-Q Send-Q Local Address           Foreign Address         State      
tcp        0      1 192.168.3.212:46416     50.18.192.250:443       SYN_SENT   
tcp        0      1 192.168.3.212:46415     50.18.192.250:443       SYN_SENT   

> /usr/sbin/traceroute -n 152.19.134.40
>   do you eventually get there?  (tcptraceroute is better, but maybe
>   your 'traceroute' program has a -T option)

traceroute failed.

> now, point your browser at www.ibiblio.org. Does
>   "/bin/netstat -atn | grep 152.19"  show a connection attempt/made?

The captive portal immediately redirected it.  While sitting at the
login page, host resolved anything I threw at it:

duckduckgo.com has address 50.18.192.251
duckduckgo.com has address 50.18.192.250
duckduckgo.com has address 52.9.194.80
duckduckgo.com mail is handled by 10 in1-smtp.messagingengine.com.
duckduckgo.com mail is handled by 40 mx1.dnsmadeeasy.com.
duckduckgo.com mail is handled by 20 in2-smtp.messagingengine.com.
duckduckgo.com mail is handled by 60 mx2.dnsmadeeasy.com.
duckduckgo.com mail is handled by 50 mx3.dnsmadeeasy.com.

So it seem that my problem arises because most of the sites I try to
go to are HTTPS, not HTTP.  Presumably J. Random Luser doesn't have
this problem because most computers come with the web browser defaulting
to go directly to a common HTTP site (e.g. www.google.com) on startup.
For them, a captive portal would redirect immediately, which is why they
stare at me blankly when I start ranting about my troubles.

Incidentally, I learned a while back that when using the site I ran
these tests on, I could get a redirect by going to its own home page,
which is HTTP rather than HTTPS.

It's all starting to make sense now.  When connecting to a hot spot
on a site with a captive portal, if the first place I want to go is
HTTPS, I must first visit a site - any site - with an HTTP connection,
to get the captive portal to redirect.

So why don't I just let my browser go to a specific site on startup?
(It could be something like www.ibiblio.org if I want to maintain my
boycott of Google.)  Well, look at it this way: what if every time
you got into your car, it immediately took you to the mall across
town, even if you only wanted to go to the corner store?  That would
be a pain in the ass - especially if traffic is heavy.

Thanks, everyone, for your help in this.

-- 
/~\  cgibbs@kltpzyxm.invalid (Charlie Gibbs)
\ /  I'm really at ac.dekanfrus if you read it the right way.
 X   Top-posted messages will probably be ignored.  See RFC1855.
/ \  HTML will DEFINITELY be ignored.  Join the ASCII ribbon campaign!

Back to comp.os.linux.networking | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Captive portals ignore some URLs Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2017-09-24 22:52 +0000
  Re: Captive portals ignore some URLs not@telling.you.invalid (Computer Nerd Kev) - 2017-09-24 23:08 +0000
  Re: Captive portals ignore some URLs not@telling.you.invalid (Computer Nerd Kev) - 2017-09-26 23:08 +0000
    Re: Captive portals ignore some URLs Moe Trin <ibuprofin@painkiller.example.tld.invalid> - 2017-09-27 03:53 +0000
      Re: Captive portals ignore some URLs Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2017-09-27 15:38 +0000
        Re: Captive portals ignore some URLs Moe Trin <ibuprofin@painkiller.example.tld.invalid> - 2017-09-27 19:11 +0000
  Re: Captive portals ignore some URLs Moe Trin <ibuprofin@painkiller.example.tld.invalid> - 2017-09-27 19:10 +0000
    Re: Captive portals ignore some URLs Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2017-09-30 00:42 +0000
      Re: Captive portals ignore some URLs Moe Trin <ibuprofin@painkiller.example.tld.invalid> - 2017-09-30 23:19 +0000
        Re: Captive portals ignore some URLs Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2017-10-02 15:33 +0000
          Re: Captive portals ignore some URLs Moe Trin <ibuprofin@painkiller.example.tld.invalid> - 2017-10-04 03:14 +0000

csiph-web