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

Groups > comp.os.linux.networking > #4084 > unrolled thread

Captive portals ignore some URLs

Back to article view | Back to comp.os.linux.networking

Contents

  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

#4084 — Captive portals ignore some URLs

I've been doing some traveling lately, and as a result have been
connecting to a lot of wi-fi hot spots.  However, it's not as
straightforward as it should be.  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.

I'm trying to eliminate (or at least minimize) my use of Google -
they're becoming way too intrusive for my taste.  My search engine
of choice is now DuckDuckGo - but this is one site that doesn't
work with captivce portals.  I'm trying other URLs (e.g. cnn.com)
to get around this.

Anything I've been able to find on captive portals says that they
will redirect any URL to themselves.  This, I can say from experience,
is not true.  I know about the problems with HTTPS redirects - but
why should ordinary HTTP requests be quietly ignored?

I suspect many people don't notice this problem because their browser
is set to go to Google on startup.  I configure my browsers to display
a blank page on startup - I go many different places, and there's no
reason why I should be first be sent off to Google (or some other site)
if I really want to go somewhere else - especially if network response
is slow.

Does anyone have any suggestions for dealing with this, or should
I just try to find a URL which is recognized by captive portals
that isn't an agent of Big Brother?

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

[toc] | [next] | [standalone]

#4085

Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:
> [snip]
> 
> Anything I've been able to find on captive portals says that they
> will redirect any URL to themselves.  This, I can say from experience,
> is not true.  I know about the problems with HTTPS redirects - but
> why should ordinary HTTP requests be quietly ignored?
> 
> I suspect many people don't notice this problem because their browser
> is set to go to Google on startup.  I configure my browsers to display
> a blank page on startup - I go many different places, and there's no
> reason why I should be first be sent off to Google (or some other site)
> if I really want to go somewhere else - especially if network response
> is slow.
> 
> Does anyone have any suggestions for dealing with this, or should
> I just try to find a URL which is recognized by captive portals
> that isn't an agent of Big Brother?
> 

I'm on mobile broadband and notice that when my account needs to be
recharged Firefox displays a drop-down notice at the top of the page
view (even at about:blank, as I remember it) which, when clicked on,
takes me to the SIM activation/recharge URL (it redirects all HTTP
requests there as well). This still works when the modem is
connected via a router.

Presumably this is a system designed to work around the issues with
redirects, and would seem suited to WiFi access as well. I've long
meant to look into the details, but still haven't got around to it.

The browser where I've seen this is Firefox 52 ESR.

-- 
__          __
#_ < |\| |< _#

[toc] | [prev] | [next] | [standalone]

#4086

Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:
> I've been doing some traveling lately, and as a result have been
> connecting to a lot of wi-fi hot spots.  However, it's not as
> straightforward as it should be.  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.
>
> [snip]
> 
> Does anyone have any suggestions for dealing with this, or should
> I just try to find a URL which is recognized by captive portals
> that isn't an agent of Big Brother?

Another option: You could use "host" command to return the IP address
of the server on the local WiFi network that serves the login page,
then visit that IP directly in your browser.

-- 
__          __
#_ < |\| |< _#

[toc] | [prev] | [next] | [standalone]

#4087

On Tue, 26 Sep 2017, in the Usenet newsgroup comp.os.linux.networking, in
article <oqemlc$1qja$1@gioia.aioe.org>, Computer Nerd Kev wrote:

>Another option: You could use "host" command to return the IP address
>of the server on the local WiFi network that serves the login page,
>then visit that IP directly in your browser.

May or may not work.   Plugging in an IP into the URL will often work
if there is only one virtual host on that IP.    Look at a data-center
with rows of 60 blade hosts in each rack, each server could be
serving dozens of different hosts - i.e.   www.host1.example.com
and www.host15.example.com (and all in-between) may ALL be on host
198.51.100.10.  The web server daemon knows which page to return
because the HTTP "GET" command asks for the appropriate host-NAME
(not an IP) i.e "GET www.host1.example.com/index.html"

        Old guy

[toc] | [prev] | [next] | [standalone]

#4088

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

> On Tue, 26 Sep 2017, in the Usenet newsgroup comp.os.linux.networking, in
> article <oqemlc$1qja$1@gioia.aioe.org>, Computer Nerd Kev wrote:
>
>> Another option: You could use "host" command to return the IP address
>> of the server on the local WiFi network that serves the login page,
>> then visit that IP directly in your browser.
>
> May or may not work.   Plugging in an IP into the URL will often work
> if there is only one virtual host on that IP.    Look at a data-center
> with rows of 60 blade hosts in each rack, each server could be
> serving dozens of different hosts - i.e.   www.host1.example.com
> and www.host15.example.com (and all in-between) may ALL be on host
> 198.51.100.10.  The web server daemon knows which page to return
> because the HTTP "GET" command asks for the appropriate host-NAME
> (not an IP) i.e "GET www.host1.example.com/index.html"

I think we're wandering a bit far from the original intent of my posting.
After searching the web for information on captive portals, I get the
impression that _any_ HTTP request should be redirected, not just requests
for certain URLs.

Having said that, I checked my bookmarks and found that many of them make
HTTPS requests, which can be causing some of my problems.  However, I'm
pretty sure that many times I've specifically typed "http://..." on the
address bar and gotten no response.  If this gets redirected to "https://...",
then something is getting in there ahead of the captive portal.

We're back from vacation now, so I won't be using so many public wi-fi
hot spots for a while.  But I'll try local ones when I get the chance
and see whether I'm still having problems on HTTP (vs. HTTPS) requests.

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

[toc] | [prev] | [next] | [standalone]

#4090

On 27 Sep 2017 15:38:02 GMT, in the Usenet newsgroup comp.os.linux.networking,
in article <oqggkq0eq4@news3.newsguy.com>, Charlie Gibbs wrote:

>I think we're wandering a bit far from the original intent of my
>posting.

Sorry 'bout that

>After searching the web for information on captive portals, I get the
>impression that _any_ HTTP request should be redirected, not just
>requests for certain URLs.

In general, yes.  As mentioned up-thread, this may be a firewall
issue where the router simply ignores the WiFi clients.

>Having said that, I checked my bookmarks and found that many of them
>make HTTPS requests, which can be causing some of my problems.
>However, I'm pretty sure that many times I've specifically typed
>"http://..." on the address bar and gotten no response.

ok

>If this gets redirected to "https://...", then something is getting
>in there ahead of the captive portal.

Yes and no - this MIGHT be your browser second-guessing you (and
knowing that HTTP is insecure and trying to save you from those
nasty h4X0rz, changing the request to HTTPS). but it also could be
the target web-site where the HTTP page auto-redirects to the HTTPS
page - only way to spot this is networking tools (packet sniffer or
looking at '/bin/netstat -atn' and looking at the destination port
number).

>We're back from vacation now, so I won't be using so many public
>wi-fi hot spots for a while.  But I'll try local ones when I get the
>chance and see whether I'm still having problems on HTTP (vs. HTTPS)
>requests.

Don't forget that each hot-spot may be set up differently.  What works
here, may not work there, much less at the other place  ;-)

One other thought - when I'm using a /graphic/ browser (rather than
my default 'lynx') it has a 'no-scripts' add-in, and that does
block a lot of stuff, INCLUDING redirects by those helpful proxies.

        Old guy

[toc] | [prev] | [next] | [standalone]

#4089

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

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

/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?

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

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

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.

/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)

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

Some spots want to proxy everything - the only way around that is to
go elsewhere OR have a VPN tunnel.  (Another way - I have a few sites
listed in my /etc/hosts file, to get around some proxy servers.)
Other hot-spots want to block skript kiddieZ by not allowing IP
connections to other than ``approved'' sites and maybe "approved"
destination port numbers (using a firewall).   Go elsewhere.

My local (public) library offers free WiFi, AFTER you are intercepted
by their authentication server and are redirected to a "I'll be nice
and not surf pr0n" page.  I've learned to FIRST attempt to connect to
the library's "home" web-page, get the authentication out of the way
and THEN do what-ever networking activities I wanted to do.

A nearby grocery store offers free WiFi along with a Starbucks in
the same store (you have to choose the correct SSID, and Starbucks
gives you a temporary password - but I don't do yuppie coffee, so
I've never tried them). The grocery proxies EVERYTHING (so they can
deluge you in ads), and their firewall only allows the proxy through.
No DNS, telnet, ftp, ssh or sftp.    As said - go elsewhere.

        Old guy

[toc] | [prev] | [next] | [standalone]

#4091

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!

[toc] | [prev] | [next] | [standalone]

#4092

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.

>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?  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?

>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.  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).

        Old guy

[toc] | [prev] | [next] | [standalone]

#4093

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!

[toc] | [prev] | [next] | [standalone]

#4094

On 2 Oct 2017 15:33:49 GMT, in the Usenet newsgroup comp.os.linux.networking,
in article <oqtm8t01kba@news4.newsguy.com>, Charlie Gibbs wrote:

>Moe Trin <ibuprofin@painkiller.example.tld.invalid> wrote:

>> 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.

I must admit that it helps, but sometimes it is VERY annoying.

>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.

They're always "improving" things.   Drive you nuts!

>>> traceroute failed.

>> How?

>* * *
>* * *
>* * *
>... 30 times, after which it gave up.

OK - this happens all too often with routers configured to "protect"
the user from hackers by dropping those dangerous ICMP errors.  I
usually Ctrl+C out of this if I don't see something by the 7th hop.
You should normally reach the outside world by then, and few places
are more than 20 hops out.

>Didn't look for a -T option.

Probably wouldn't help in this case, but I find it more reliable.
There's also a -I option that emulates the windoze 95 'tracert'
mode (using ICMP pings as the probe).    Equally un-useful.

>>> The captive portal immediately redirected it.

>> Meaning?  Redirected it where?

>To the hot spot's login page.

OK - that's usually desired behavior

>> 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.

Biggest problem I've encountered since then is trying to find out
what the home page is when I go to some new location.   Asking the
staff usually results in the typical "huh" look.

        Old guy

[toc] | [prev] | [standalone]

Back to top | Article view | comp.os.linux.networking

csiph-web