Detect captive WiFi hotspots

Bug #1571522 reported by Michael Zanetti
22
This bug affects 5 people
Affects Status Importance Assigned to Milestone
Canonical System Image
Confirmed
Medium
Alejandro J. Cura
indicator-network (Ubuntu)
Confirmed
Undecided
Unassigned
network-manager (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

Right now it is very annoying that when you connect to a captive wifi portal, the device does not detect that. All other devices open the log in page automatically, except ubuntu devices. One needs to manually open the browser, type a url and get redirected before being able to log in and start e.g. telegram messaging over the wifi connection.

My proposed solution to solve this:
When a WiFi connection is established, indicator-network should do a http GET call to ubuntu.com. If the reply turns out to be a redirect, it should open the browser with the redirect url.

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in indicator-network (Ubuntu):
status: New → Confirmed
Revision history for this message
Cris Dywan (kalikiana) wrote :

Note: The cumbersome work-around (and in practise the only current way to log into arbitrary hotspots) by opening a website in a browser requires an insecure website: Google or DuckDuckGo won't work. http://example.com does work.

Changed in canonical-devices-system-image:
assignee: nobody → Alejandro J. Cura (alecu)
importance: Undecided → Medium
status: New → Confirmed
description: updated
Revision history for this message
Lorn Potter (lorn-potter) wrote :

There can be many ways captive portals work and it is tricky being able to support the different ways of detecting this.

I've seen some offer redirects, but others offer different status codes to indicate the captive portal, and not all captive portals act properly once things get returned.

I would think this comes from network-manager level and not indicator level.

Revision history for this message
Simon Fels (morphis) wrote :

connman does a really good job here in implementing WiSPr (https://en.wikipedia.org/wiki/WISPr) support to deal with captive portals.

If you want to check if you're really not on an captive portral you want to implement something like this to perform a check if you're "online" or not:

1. Setup a well known server, lets say online.ubuntu.com which returns respecific HTTP headers like X-Ubuntu-Online: true once a HTTP GET request is received
2. When NetworkManager performs a check if its online or not (when connected to a new WiFi network or when the IP configuration has changed) it can send a HTTP GET request to online.ubuntu.com and if it gets the X-Ubuntu-Online header back its really online and otherwise not.

There is not right way to rely on result codes as those are not reliable. The one way is to set up an endpoint which will return a set expectation if you're really online.

This feature would be really something to add to NetworkManager rather than indicator-network.

Revision history for this message
Michael Zanetti (mzanetti) wrote :

FWIW, here's Android's code to detect it:

http://grepcode.com/file/repository.grepcode.com/java/ext/com.google.android/android/4.0.1_r1/android/net/wifi/WifiWatchdogStateMachine.java#WifiWatchdogStateMachine.isWalledGardenConnection%28%29

Seems they connect to something returning status 204 and expecting that code or else will open the popup.

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in network-manager (Ubuntu):
status: New → Confirmed
Changed in canonical-devices-system-image:
milestone: none → 11
milestone: 11 → backlog
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.