CaptivePortal issue on Fairphone Open OS?

Has anyone on Fairphone Open OS experienced some difficulties with CaptivePortal?

I needed to use an open wifi connection last week, but my FP2 couldn’t open the authentication page to log on to the open Wi-Fi.
Since my notebook as well as other people’s phones could connect, I suspected it might be an issue with CaptivePortal which was failing, though I’m not sure about it.

I finally managed to workaround the issue, by simply trying to the connect to the router, which very often has the IP 192.168.0.1; this actually worked. However, without that trick I wouldn’t have been able to connect to use the internet connection of the network.
I have to say that I was still using 16.04, so I don’t know if I would have the same issue with 16.05, and I also have to test possibility now.

Anyhow, I was wondering if some my settings prevented my phone from connecting to the login page, or if this is a general issue with the Open OS. Did anyone weeks experience problems with logging in to an open Wi-Fi that requires authentication through a web site?

I used an open (read: non-wpa/wep) wifi with a captive login today and it worked without problems.

I regularly login to the Madrid bus Wi-Fi without problems.

See this topic too:

No problem here to access wifi networks using captive portals.
Another tip as “using 192.168.0.1 IP@”, is to try to connect to any http webpage, not your default httpS page/bookmark ! :wink:
Some (badly set up) portals just do not redirect from httpS pages to their “https login page”…which prevents access to Internet ! :dizzy_face:

Captive Portals technically don’t work when you try to access a HTTPS page. A captive portal hijacks your HTTP connection to replace the original web page with a redirect to the captive portal. For HTTPS, you can’t successfully hijack the connection as you have not a trusted certificate for the original website. It would show a certificate warning. If not and you are redirected to the captive portal from a HTTPS page, that would be very suspicious (then the captive portal could also hijack your online banking or webmail).

Successful connection hijacking does mean that the captive portal could read the webpage contents, usernames/passwords or cookies. It could also try to read cookies from webpages you don’t want to visit now, via a redirect cascade (you want to access example.com and the captive portal redirects you via google.com, facebook.com, twitter.com, amazon.com, youremailprovider.com, yourbank.com to the captive portal).

So, if the device does not automatically open the captive portal, you have to open a non-HTTPS page (like www.golem.de) to check if there is a captive portal and to access it.

I have an app installed which automatically clicks through a captive portal. Well, it’ll take some time and does not work with all captive portals. It does not work at all with those SMS verification portals.

I don’t like captive portals because of:

  1. the above connection hijacking
  2. not working when trying to access a HTTPS web page
  3. not working when using a non-browser client (e-mail client, apps)
  4. appearing not only once, but every time I connect to that Wi-Fi
  5. there are better methods to ask for a username and password (I mean WPA2-Enterprise)
2 Likes

Captive Portals technically don’t work when you try to access a HTTPS page. […]

I believe we are getting out of topic here, I cannot see any technical reason preventing HTTPS redirections for captive portals (that would imply routing capabilities, that almost all captive portals boxes have).

I don’t like captive portals because of:

  1. the above connection hijacking
  2. not working when trying to access a HTTPS web page
  3. not working when using a non-browser client (e-mail client, apps)
  4. appearing not only once, but every time I connect to that Wi-Fi
  5. there are better methods to ask for a username and password (I mean WPA2-Enterprise)

I fully agree on this !

@freibadschwimmer : Did you found any setting on your FairPhone2 preventing access to login page of your usual captive portal ? Did you found the root cause of your first post in this thread ?

HTTPS works with certificates, a site proves it’s genuineness via them.

When I log in into the WLAN which uses a captive portal, and I first visit https://example.com, the provider of the captive portal needs a valid certificate for example.com in order to send e.g. a HTTP 302 and redirect me to an other site where his captive portal is.
In all other cases, the connection just fails with a more or less meaningful error message, because they will never get a valid certificate for example.com.

This is the case e.g. at my work, and the connection to any HTTPS-Site fails there, I have to visit either a HTTP site or https://<mywork>.com (Since they have a certificate for this one).

So here is your technical reason. :wink:

2 Likes

I don’t often need to use captive portals. So after it didn’t work at this one place, I’ve had software updates before using it again. Lately I used captive portals without problems, so it is difficult to say wether it was connected to the set up of that particular portal, the OS version or whatever. I never figured out what the problem actually was, but it did work recently.

Even if not knowing what the problem was in the first place, knowing that this is not an issue anymore is good to know, thanks for the feedback ! :slight_smile:

Oh okay, I see better what you mean by a failed connection.

Around here (France), most ISP allow you to connect to their wifi network with customer’s login/password only if you activate wifi on your home box (allowing other customers to use your home box).

So that, for example I can connect to orange network.
Then, if I go to a HTTPS website (like https://google.fr ), I have a warning about an invalid certificate, as you stated.
But, once an exception is made for this “false” certificate, my browser is redirected to their (valid) HTTPS page, in this example: https://hautdebitmobile.orange.fr:8443/home
On this very page, I can use my customer login/password and once this is done, I can connect to (valid) HTTPS google page.

Again, I fully agree that captive portals have major drawbacks, as making an exception without checking certificate first is bad and I don’t know if FP2 allows this.
But I believe that most (non-computer science) people do use exceptions, without even checking certificates (in the very same way that only a few computer science people check server’s ssh certificate on very first login). :stuck_out_tongue_winking_eye:

Low Memory, loving being out of topic :wink:

1 Like

We have this in Germany, too, with the ISPs Telekom (cooperating with Fon to have a worldwide network) and Vodafone.

Oh, I didn’t know that.

Here in France following ISPs have a “shared” wifi:

  • SFR, which also cooperates with Fon: SFR Wifi FON network
  • Orange, which has orange network
  • Free Telecom, which has FreeWifi network
  • Bouygues Telecom, which has Bouygues Telecom Wi-Fi network

Edit : added other ISPs

This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.