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

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

Re: Captive portals ignore some URLs

Show all headers | View raw

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

> On 30 Sep 2017 00:42:12 GMT, in the Usenet newsgroup comp.os.linux.networking,
> in article <oqmp940rd6@news6.newsguy.com>, Charlie Gibbs wrote:
>
>> Moe Trin <ibuprofin@painkiller.example.tld.invalid> wrote:
>
>>> cat /etc/resolv.conf
>>>   does your system have an address of a name server?
>
>> Oops, forgot to do that one.
>
> NORMALLY, the wireless setup is using a DHCP mechanism to obtain the
> local network parameters (client IP, netmask, default gateway, DNS,
> and possibly some others). The check was to see that this was the
> case.
>
>> Instead of www.google.com, I tried http://duckduckgo.com.
>
> which is spamazon, rather than alphabet - but what-ever
>
>> The browser (Seamonkey under Debian) turned this into
>> https://duckduckgo.com (perhaps because that's what's in my history),
>> and hung.
>
> I don't know Seamonkey (I've never gotten into all-in-one tools), but
> are you ALSO running NoScript with that?    I know that will try to
> replace the http callout with https.

Although I run NoScript on my desktop machine at home, I'm not running
it on the laptop.  As for Seamonkey, I strictly use it as a web browser.
I used to use Firefox, but as of release 29 they changed the user interface
in ways I don't like.  Seamonkey preserves the original interface.

>> 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
>
> OK - it tried to make a connection to the https port - but got no
> ACK/SYN in reply.  Usual reason is either some router in between you
> and them is dropping the packet(s) and not sending an ICMP error to
> you (or the remote site is down or having a hissy-fit).
>
>>> /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.
>
> How?

* * *
* * *
* * *
... 30 times, after which it gave up.  Didn't look for a -T option.

> Basic traceroute uses UDP packets to ports around 33434 and up,
> with TTLs starting with 1 (which should cause the first router to
> return an ICMP Type 11 Code 0 per RFC0792). and incrementing the TTL
> to identify subsequent hops.   Two problems - UDP _may_ be treated
> differently from TCP (which is why tcptraceroute or 'traceroute -T'
> is a better tool), and the routers may drop/ignore ICMP.   A possible
> third problem is that the TCP trace defaults to going for port 80, and
> the local proxy-server (or router) may intercept that.
>
>>> 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.
>
> Meaning?  Redirected it where?

To the hot spot's login page.

>> While sitting at the login page, host resolved anything I threw at it:
>
> As above with 'traceroute'.  DNS queries are UDP, and are probably
> answered locally (the DNS server is local, and you already showed that
> it's working/answering queries).  My normal TCP test is to see if I
> can get a "Login:" prompt from one of a few dozen FTP servers "out
> there".  Used to try to see if we could get to an SSH login prompt,
> but the company security auditors got all bent out of shape over that.
>
>> So it seem that my problem arises because most of the sites I try to
>> go to are HTTPS, not HTTP.
>
> Yes, that can be a major factor.
>
>> For them, a captive portal would redirect immediately, which is why
>> they stare at me blankly when I start ranting about my troubles.
>
> What is this "man in the middle" concept???    ;-)
>
>> 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.
>
> I liked ibiblio.org (which was the old 'sunsite.unc.edu' that was so
> familiar to Linux users in the 1990s) because it was usually very fast
> to start.  I notice that the site IS still giving a 301 to a http
> request
>
> [cassini ~]$ lynx http://www.ibiblio.org
> Looking up www.ibiblio.org
> Making connection to www.ibiblio.org
> Sending HTTP request
> HTTP request sent; waiting for response.
> HTTP/1.1 301 Moved Permanently
> Data transfer complete
> Using https://www.ibiblio.org
>
> but when it attempts an HTTPS (or FTP) request, the site is refusing
> connection.  As the site has been virtually unmaintained for a while,
> I'm guessing they're finally pitching it.
>
>> 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.
>
> Well, it's not as if we're still using v.22 analog modems (1200 bps),
> so the delay shouldn't be THAT great - but that's why I usually will
> try to pull up the hotspot's home page before doing anything else.

Still, there are times when network traffic is slow - and adding one more
unnecessary delay just doesn't make sense.  I got data/Wifi working on my
wife's phone yesterday, and set up bookmarks for her commonly-used sites
so she doesn't have to waste her (minimal) data allotment (plus time and
effort) going through a search engine to get where she really wants to go.

> I ran into this problem about a year ago when I upgraded and installed
> a browser with a 'NoScript' add-in, and the hot-spot at the local
> library stopped working for me.   Took a few hours of packet sniffing
> to understand the problem.  Problem went away the moment I realized I
> had to call up the library's (local) home page, which was hosted on
> their authentication server (which NoScript tolerated a redirect on).

That'll be my technique from now on: make an initial access to the
hot spot's home page.  Things should sort themselves out from there.

-- 
/~\  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