Editing User:Magick777/WISPr WiFi Autologin

Warning: You are not logged in. Your IP address will be recorded in this page's edit history.

The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then save the changes below to finish undoing the edit.

Learn more about Contributing to the wiki.

This page documents work on automated logins to UK WiFi hotspots, and attempts to achieve native support in the N900 for WISPr auto-login on any hotspot network that supports it.

== Use cases ==

* Auto-login at free, local and national FON/BTWiFi or similar hotspots
* True 'wireless ISP roaming' i.e. auto-login via FON / iPass / WeRoam partner networks
* Multi-network, multi-credential auto-login with multiple WISPr networks

In other words, the same WiFi login functionality as the [https://play.google.com/store/apps/details?id=com.bt.mnie.wispr&hl=en BT WiFi app], the [https://play.google.com/store/apps/details?id=com.oakley.fon&hl=en FON app], and perhaps the [http://www.thecloud.net/free-wifi/get-the-app/ Cloud app], but without having to run an app, and most certainly without running multiple apps to accomplish the same thing.

== Existing WISPr clients ==

WISPr clients seem to be very few and far between; it's used in network-specific clients such as the BT app, and there are generic clients for Android and iOS, but it hasn't taken off in a big way. The most functional open source WISPr client that I can find, as of July 2013, is https://bitbucket.org/tamias/pywispr, which supports HTTPS (with the relevant SSL module), and supports multiple sets of credentials for multiple hotspot networks.

Out of the box this works tolerably well for manual use at the command line and it succeeds in making a successful WISPr login via BTWiFi. The problems are with installing it (our python doesn't have SSL per default and installing it is mildly complex), with automating it (the script, as it stands, is interactive), and with configuring it (network support for WISPr is not well documented).

== Design goals ==

My preference is for an event-driven, script-based autologin; whilst turning it into an app might bring it to the masses, we then have needless complications of putting a GUI on it, running a daemon to take care of listening for new connections, etc. So, my aim is for a command line client that can be launched from dbus-scripts (or otherwise) on connection to a wireless network.

This client '''should'''

* make an HTTP GET request and determine whether we are connected
* determine whether our captive portal supports WISPr
* determine whether we have credentials per login domain
* attempt authentication and determine the response
* support multiple sets of credentials for multiple WISPr captive portals

and '''may'''

* record the logoff URL and provide a means to log off
* notify the user of relevant information during the logon process
* generate logs of its activity
* provide a way to try more than one set of credentials for a single portal?

and '''might'''

* provide a way to try fallback credentials for a previously unknown portal?
** this might be useful to roaming users, e.g. of iPass, WeRoam, or FON, who will not wish to configure individually for every possible partner network but just connect to it and, if it supports WISPr, try the credentials
** this may be dangerous if we hand out credentials without verifying that we're talking to a legitimate hotspot network, consider insisting on SSL connection, verifying the SSL certificate, and also making sure that the domain being given to us by WISPr is on a list of known providers before we offer up any login credentials.

but '''should not'''

* interfere with connections to private or non-WISPr WiFi networks
* open any popups or applications that require user interaction (with one or two exceptions)
* be too difficult to install, configure, or understand
* involve any large or complex dependencies
* get involved in whether we connect to the SSID or not (we should just do auth)

== Design challenges ==

'''* Our WISPr client needs to speak XML, HTTP and HTTPS from CLI
* SSL support is not natively present in Maemo 5's perl or python
* Adding SSL support to python requires some SDK libs, see''' [http://talk.maemo.org/showpost.php?p=1326179&postcount=7 this thread]

'''Option 1''': keep python client as it is, using httplib + ssl. Users will just have to install ssl.

'''Option 2''': update python client to use [https://pypi.python.org/pypi/ndg-httpsclient ndg-httpsclient] if it works under python 2.5

'''Option 3''': update python client to use [https://pypi.python.org/pypi/pycurl pycurl], let libcurl do the fetching & carrying

'''Option 4''': find an alternative to python

'''* We want to be non-interactive, so how do we handle logoff?'''

'''Option 1''': don't bother, the portal takes care of lost connections anyway.

'''Option 2''': provide manual logoff by saving the last logoff URL, but only works if still connected

See also http://talk.maemo.org/showthread.php?t=90777

== WISPr Networks ==

=== America ===

Little is known about the state of hotspot networks in the USA, but you should be able to use this with iPass.

=== Asia / Pacific ===

Little is known about the state of hotspot networks in Asia, but you should be able to use this with iPass.
* Japan
** SoftBank / FON
* Russia
** MTC / FON

=== Europe ===

The author approaches the subject from a UK/European perspective, where the overwhelming majority of hotspots (almost 12 million) are provided by the residential customers of the major telcos in partnership with FON. Five million of these are in Britain and this is my primary use case for supporting WISPr.

* United Kingdom
** WISPr hotspot networks
*** BTWiFi + FON
*** BTOpenzone
*** The Cloud
** Non-WISPr hotspot networks
*** O2 WiFi
*** Virgin Media WiFi
* Belgium
** Belgacom / FON
* Brazil
** Oi / FON
* Croatia
** HT / FON
* France
** SFR / FON
* Germany
** DT / FON
* Poland
** Netia / FON
* Portugal
** Zon / FON

Please note that all contributions to maemo.org wiki may be edited, altered, or removed by other contributors. If you do not want your writing to be edited mercilessly, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource (see maemo.org wiki:Copyrights for details). Do not submit copyrighted work without permission!

Summary:

Cancel | Editing help (opens in new window)

Retrieved from "http://wiki.maemo.org/User:Magick777/WISPr_WiFi_Autologin"

Personal tools

Navigation

Views

Editing User:Magick777/WISPr WiFi Autologin

@@ Line 4: / Line 4: @@
 == Use cases ==
-* Auto-login at free, local FON/BTWiFi or similar hotspots
+* Auto-login at free, local and national FON/BTWiFi or similar hotspots
 * True 'wireless ISP roaming' i.e. auto-login via FON / iPass / WeRoam partner networks
 * Multi-network, multi-credential auto-login with multiple WISPr networks
@@ Line 40: / Line 40: @@
 ** this might be useful to roaming users, e.g. of iPass, WeRoam, or FON, who will not wish to configure individually for every possible partner network but just connect to it and, if it supports WISPr, try the credentials
 ** this may be dangerous if we hand out credentials without verifying that we're talking to a legitimate hotspot network, consider insisting on SSL connection, verifying the SSL certificate, and also making sure that the domain being given to us by WISPr is on a list of known providers before we offer up any login credentials.
-* eventually, provide a way to fall back to an automated HTTP POST login, if we're expressly configured with how to do so. Might be useful for school/college/university networks requiring a web login.
-* launch a browser if we detect a captive portal but don't have the means to log in automatically
 but '''should not'''
@@ Line 51: / Line 49: @@
 * get involved in whether we connect to the SSID or not (we should just do auth)
-=== Design challenges on N900 ===
+== Design challenges ==
 '''* Our WISPr client needs to speak XML, HTTP and HTTPS from CLI
@@ Line 59: / Line 57: @@
 '''Option 1''': keep python client as it is, using httplib + ssl. Users will just have to install ssl.
-'''Option 2''': update python client to use urllib2 and openssl
+'''Option 2''': update python client to use [https://pypi.python.org/pypi/ndg-httpsclient ndg-httpsclient] if it works under python 2.5
-'''Option 3''': update python client to use [https://pypi.python.org/pypi/ndg-httpsclient ndg-httpsclient] if it works under python 2.5
+'''Option 3''': update python client to use [https://pypi.python.org/pypi/pycurl pycurl], let libcurl do the fetching & carrying
-'''Option 4''': update python client to use [https://pypi.python.org/pypi/pycurl pycurl], let libcurl do the fetching & carrying
+'''Option 4''': find an alternative to python
@@ Line 73: / Line 71: @@
-'''* One captive portal can serve multiple hotspots'''
-* The density of BTWiFi hotspots means that one can sometimes reach two or three possible routers, all connected to the same captive portal. This can sometimes (rarely) lead to unexpected effects, if disconnected from one network and connected to another one that shares the same portal; the portal views us as logged in, but our traffic remains blocked.
-* In particular, this has been noted when switching from BtWiFi to BTWiFi-with-Fon, and it is imagined that they share a web portal but not a DHCP server. This caused problems for the perl client (which presumes by the absence of a redirect that we are connected) but not for the python client, which tests whether it is connected by verifying the content of an HTTP GET request. Of course, it creates a dependency on the availability of a remote server and I don't much like the script's default of fetching "www.yahoo.co.jp"; we don't need an entire HTML page to confirm that we are online, but we do need to keep the check in some form.
-== N900 PyWISPr client ==
 See also http://talk.maemo.org/showthread.php?t=90777
-=== Changelog & sources ===
-* Began life as an N900 fork of https://bitbucket.org/tamias/pywispr
-* Run from sh as per http://softwareswirl.blogspot.co.uk/2011/06/starting-python-script-intelligently.html
-* Exit automatically on successful login, don't wait for user input (exit @ line 266)
-* Replaced the slow online check (a Yahoo web scrape) with Google's generate_204 check
-** logic http://www.chromium.org/chromium-os/chromiumos-design-docs/network-portal-detection
-** code from https://github.com/cdown/wifilogin/blob/master/wifilogin/connection.py
-** used for Chromium OS and Android; backend shouldn't go away any time soon
-** reduces unnecessary bandwidth use, somewhat faster, works better internationally
-==== Still to do ====
-* consider whether we really need to check first for a captive portal and then make the same request again to obtain the same redirect and look for credentials? Why can we not combine the two, make a single request that serves both as online check and invitation for a WISPr redirect, and act on the response we receive? This might speed things up.
-* consider whether we can replace the dependency on httplib + SSL with something that is readily available through apt, such as pycurl
-* add (limited) user notifications
-** notify on captive portal without WISPr support? browser option?
-** notify on captive portal with WISPr support but no valid credentials?
-** notify on access granted (or refused)
-** do not notify the user about doing nothing (i.e. already online)
-* provide a usable CLI mode as well as automation
-** ability to override username and password
-** ability to logout from last used LogoutURL, mainly for testing
 == WISPr Networks ==
-=== HELP WANTED ===
-I know very little about how FON or iPass works in other countries, if you can add any information about public access WiFi hotspots in your country, or accessing them via WISPr, then please do.
 === America ===
@@ Line 130: / Line 91: @@
 === Europe ===
-The author approaches from a UK/European perspective, where the overwhelming majority of hotspots (almost 12 million) are provided by the residential customers of the major telcos, in partnership with FON. Five million of these are in Britain and this is my primary use case for supporting WISPr.
+The author approaches the subject from a UK/European perspective, where the overwhelming majority of hotspots (almost 12 million) are provided by the residential customers of the major telcos in partnership with FON. Five million of these are in Britain and this is my primary use case for supporting WISPr.
 * United Kingdom
 ** WISPr hotspot networks
-*** BTWiFi with FON
+*** BTWiFi + FON
-**** accepts BT Broadband customers
+*** BTOpenzone
-**** accepts FON customers
-*** BTOpenzone [commercial]
-**** accepts iPass customers
-**** accepts contract customers of Vodafone, Orange, T-mobile
 *** The Cloud
-**** accepts iPass customers
-**** accepts Sky customers
-**** accepts 4UWiFi customers
-**** accepts free individual users, with online registration
 ** Non-WISPr hotspot networks
 *** O2 WiFi
 *** Virgin Media WiFi
 * Belgium
-** Belgacom with FON
+** Belgacom / FON
 * Brazil
-** Oi with FON
+** Oi / FON
 * Croatia
-** HT with FON
+** HT / FON
 * France
-** SFR with FON
+** SFR / FON
 * Germany
-** DT with FON
+** DT / FON
-* The Netherlands
-** KPN with FON
 * Poland
-** Netia with FON
+** Netia / FON
 * Portugal
-** Zon with FON
+** Zon / FON