Browser redirect to wifi login page

[bf]

Hi,
When trying to connect to guest wifi networks which have a login page, I would expect to open the browser, try to access an internet site and be automatically redirected to the login page (or even better if the browser would open automatically when I connect to the wifi network and take me to the login page).

However, this seems to be hit and miss; sometimes I'm taken to the login page while other times the browser just sits there for a while trying to access the page I've selected before finally telling me I'm not connected to the internet. Nothing I can do brings me to the login page.
Does anyone have a suggestion if I'm doing something wrong?
Thanks

[malditobastardo]

Yeah I experienced the same behavior when trying to connect to guest wifi. Its kind of hit and miss but eventually the page finally loads up and I can login.. It would be good to have a workaround or a fix as you said.

[ernest]

Most of the guest wifi network request to catch an non https request to bring you to their non secure login page.
So to get the login page try to load a page in http only like http://www.no-ssl.com/ then you should normally get the login page.
Then it's the moment to start your VPN connection.

[bf]

Thanks a lot, that's great to know. Next time I have the chance to connect to a guest wifi I'll check it out and give some feddback.
Thanks again for the info.

[bf]

The first chance I got to try it, it worked perfectly. Thanks again for the info.

[flohack]

These landing pages or portals are non-standard, so there is nothing that can be done to make it easier from the official functions. Some OSes like Windows and probably also iOS somehow send out queries to detect if there is a captive portal after connecting to the WiFi and offer to open the browser, but ATM I cannot see such functions on UT...

[MK73]

Hi, I had similar experience pherhaps at MacDonald, having a different starting web browser page to the default Canonical one. When I switched back everything start to work properly. Hope this feedback will help to resolve this issue.

[Leppa]

From what I can see, android connects to a network, then immediately tries to connect (connectivitycheck.gstatic.com or something). If it takes too long, it just says that it has no internet; if it gets redirected to another website, it gives a notification.

[guru]

I have here in my town a place where I am from time to time and they offer free Wifi for the guests. The authentication URL of the AP (some FRITZ!Box) is http://192.168.179.1:8186/untrusted_guest.lua and the UT never gets redirected to this. I used an iPhone which magically goes right away after enabling Wifi to this page and I typed the above URL into the UT and bookmarked it. I'm asking me how the iPhone is "guessing" this URL?

[bf]

@Flohack OK, thanks for taking the time to reply.
I have also had similar problems from time to time with apple devices; Android seems to handle it quite well in my experience. Anyway, I don't see it as a major issue if I have to open the browser myself and try to load a page as long as it redirects me to the login page reliably and repeatably when I do that. However, this was not happening every time and it seemed to me to be random.

The answer provided above by ernest seems to have solved it for me, although I have only tried one guest wifi so far. I have bookmarked http://www.no-ssl.com and if I try to load that I get a successful redirect. Hope it keeps working like that.

[Leppa]

We could just have UT automatically try to connect to www.no-ssl.com, and if it redirects, show a notification prompting you to connect.

[arubislander]

There was an article not top long go on OMUbuntu about this exact feature which would be landing in 17.10. Maybe something similar could be backported to 16.04? Battery life would be a concern, though...

[ernest]

@Leppa We cannot rely on a website that we don't manage.

Ubports could create a http:// webpage to fix that, however i don't know the complexity to implement such feature on the phone side and there are other priorities.

I would say a well organized wiki in open access like OSM or wikipedia with this kind of tips would be easier.

[guru]

I sniffed with TCPDUMP in my FreeBSD netbook what's going on on
first requesting with firefox some web page:

1. FF starts and asks the (local) DNS at IP 192.168.179.1 port 53
   for the IP addr of A? detectportal.firefox.com

2. DNS answer: CNAME detectportal.firefox.com.edgesuite.net.,

   CNAME a1089.d.akamai.net., A 92.226.1.104

3. FF makes HTTP request to 92.226.1.104 and sends

   HTTP: GET /success.txt

4. 92.226.1.104 (and this is perhaps not the answer of 92.226.1.104, but sent by the local AP):

   HTTP/1.0 302 Moved Temporarily
   Location: http://192.168.179.1:8186/untrusted_guest.lua.

which FF now let bring up the landing/login page of the AP

But, this (HTTP redirect) is only one of more arts to direct a browser to
a login page; see also: https://en.wikipedia.org/wiki/Captive_portal

I also would suggest a good organized description in the Wiki about some common methods to try in UT/UB to get to the login page of the local Wifi AP.

matthias

[L-00032]

This post is deleted!

[L-00257]

This post is deleted!