User:Magick777/WISPr WiFi Autologin

(Design goals)
(Design goals)
Line 36: Line 36:
* provide a way to try fallback credentials for a previously unknown portal?
* 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 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 making sure that the verified domain being given to us by WISPr is a list of known providers.
+
** 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'''
but '''should not'''

Revision as of 13:01, 23 July 2013

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.


Contents

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 BT WiFi app, the FON app, and perhaps the 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?
  • 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
  • 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 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 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 ndg-httpsclient if it works under python 2.5

Option 3: update python client to use 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