| Latest revision |
Your text |
| Line 1: |
Line 1: |
| - | 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. | + | 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 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 == | | == 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. | + | 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. |
| - | | + | |
| - | 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 == | | == 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. | + | My preference is for an event-driven, script-based autologin; whilst turning it into an application might take 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''' | | This client '''should''' |
| Line 33: |
Line 23: |
| | * notify the user of relevant information during the logon process | | * notify the user of relevant information during the logon process |
| | * generate logs of its activity | | * generate logs of its activity |
| - | * provide a way to try more than one set of credentials for a single portal? | + | * 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.
| + | |
| - | * 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''' | | but '''should not''' |
| | | | |
| | * interfere with connections to private or non-WISPr WiFi networks | | * interfere with connections to private or non-WISPr WiFi networks |
| - | * open any popups or applications that require user interaction (with one or two exceptions) | + | * open any popups or applications that require user interaction |
| | * be too difficult to install, configure, or understand | | * 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 on N900 ===
| + | == Design challenges == |
| | | | |
| - | '''* Our WISPr client needs to speak XML, HTTP and HTTPS from CLI
| + | * Our WISPr client needs to speak XML, HTTP and HTTPS |
| | * SSL support is not natively present in Maemo 5's perl or python | | * 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] | + | * 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 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
| |
| | | | |
| - | | + | * We want to be non-interactive, so how do we handle logoff? |
| - | '''* 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 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 | + | '''Option 2''': provide manual logoff by saving the logoff URL, only works if we still have a connection |
| | | | |
| - | | + | == Sources == |
| - | '''* 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 | | 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 ===
| |
| - |
| |
| - | 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 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
| |
| - | **** accepts BT Broadband customers
| |
| - | **** 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
| |
| - | * Brazil
| |
| - | ** Oi with FON
| |
| - | * Croatia
| |
| - | ** HT with FON
| |
| - | * France
| |
| - | ** SFR with FON
| |
| - | * Germany
| |
| - | ** DT with FON
| |
| - | * The Netherlands
| |
| - | ** KPN with FON
| |
| - | * Poland
| |
| - | ** Netia with FON
| |
| - | * Portugal
| |
| - | ** Zon with FON
| |
