Notices

Until recently, the availability of free or reciprocal WiFi hotspots in the United Kingdom (e.g. Fon / BTWiFi) was not something that one could rely on. So, whilst I've been sharing Internet access via Fon since 2008, my N900 isn't configured to connect to the hotspots that it finds because it hasn't been worth the hassle. As of 2013, this has changed; after a few years of BT's policy of including Fon into its stock routers and opting customers in by default, BTWiFi hotspots can be found within reach of many/most residential dwellings (in London at least).

Still, having the N900 connect to them automatically remains a nuisance. At best, we log on to a network that requires manual authentication to proceed further, knocking the phone offline. At worst, we log on to open networks simply because they're there and not because we intended to, which is a waste of battery and a real nuisance when travelling. How do we fix this, so that using public hotspots becomes a viable proposition from an N900? What do we need to take into account?

Obviously we need some sort of auto-login functionality, akin to autowifi, but we need it to work well for the typical user of a N900, which means we don't want it to interfere with the use of private wireless networks, and we don't want it to interfere with the use of 3G unless we're in a situation where that is going to be helpful - perhaps this is quite a tall order.

Before trying to hack up anything, I'd welcome some input from other seasoned N900 users. Should we do this as a "one-shot" manual connection script that bypasses (and leaves untouched) the N900 settings, configures the wireless interface manually, automates the login, and (optionally) loads a browser pointed to the logout page? In other words: hit the Fon button when desired and the phone does the rest.

Should we favour a fully automated approach, where we do configure the hotspot SSID in the N900 such that it connects automatically and logs in automatically? If so, how shall we have it do this only when we wanted it to? Perhaps perform a manual scan, and only activate the auto-login for APs with a pre-approved MAC address? Might be useful for having it only work automatically in particular locations against particular hotspots.

Perhaps both of the above; a "suck-it-and-see" script that searches for a BTWiFi connection, and keeps a list of "good APs" and "bad APs" based on successful connection, plus auto-connect ability either for known-good APs or for whatever's available.

I'd also like to hear some international perspectives on this; I'm thinking about what's available in London, but it should not be any different, in principle, to support comparable hotspot networks in other countries. Please comment on what is available locally to you, whether you're interested in improving automated access to it, and how you might see that working...

Yep this app is also needed for the N9 here in Scotland.

wonder where my message went. duh! typed in address bar

i imagine connecting to the hotspot and automatically submitting credentials form would suffice. this *could* be as easy as a cleverly constructed bookmark or .desktop file. could launch a script to submit info in background. could rely on a signal (dbus or qt) to submit once connected.

ideal world would be to modify internet connections wizard to allow a hotspot category to submit automatically on.

maybe start by finding whats required fields from forms

This is the (relatively) easy part. The login form requires a POST, but it will be fairly simple to whip up an auto-login using curl. We can trigger such an action from dbus, as you say, or possibly from an if-up script on the wireless interface.

Before I rush into doing that, though, there's a problem with when and whether to connect to a (potential) hotspot in the first place; if we have the phone connect and log in by default, then it will do that every time it encounters the given SSID. Which is dozens of times within a half hour bus journey, and for none of them could I have maintained a connection to the hotspot for long enough to use it.

It's probably too much to ask the phone to deduce whether I am on a bus or not, but this is why I am thinking that I don't want to just configure the SSID in the N900 and let it autoconnect. This favours making a more fine-grained assessment of whether we want to try to connect to an available AP or not. Once I've got that figured out (playing with wireless-tools at present) then it should be fairly easy to script up the web-based login for any given provider, but that should be a bolt-on to a means of deciding when and whether to use a hotspot. I'm working on this in the background, but would welcome any thoughts in the meantime...

I don't have an N9, but I guess that favours a standard approach using wireless-tools and bog-standard Linux scripting capabilities, rather than an N900-specific app. This is more or less what I had in mind anyway, as I'd like to be able to use the same capability from a laptop or tablet.

Is it just the same login screen at every hotspot? Some guy already created such an N900 app to automatically satisfy them a couple of years ago to log onto the net at his college. It was announced & dstributed via TMO.

what if you have it as a menu icon, so credentials only get submitted when you want to?

i personally disable option to scan for wifi, but enable automatic connection. this way it will only try to connect when i want it to. only other way i can think of is to intercept the redirects when not signed in?

Hmm... apparently, on some further reading, the FON and BTWiFi hotspots natively support autologin via WISPr, which is used in autologin apps for Android, iOS, etc.

Crude client implementations seem to be available in perl and in python, which I am playing around with now. I'll report back if I get anywhere...

So... I have some (very limited) progress in getting WISPr authentication working against a BTWiFi hotspot. My first forays with the simple client scripts resulted in some not-very-helpful errors, and it was only when I tried a third perl client that it became clear that I was going to need quite a handful of perl modules to get past detecting the WISPr redirect and actually submit credentials over HTTPS.

After some messing about with CPAN to install XML::Simple and Crypt::SSLeay plus dependencies (libssl-dev needed before you start, plus some familiarity with CPAN advised) I was able to get the client to make an HTTP request, intercept the WISPr redirect, submit my login credentials... and receive "Login failed (Access REJECT)" for pretty much anything I tried.

Documentation on WISPr is pretty scant, but from reading the sources of other clients I suspected that I would need to prefix or suffix my login credentials with a string to indicate that I'm a FON customer as opposed to BTOpenzone or whatever. I'd tried prefixing with FON/ and suffixing with @fon, both without success, when I found (from the source code of the Android WISPr client) that the network prefix seems to be BTFON, so BTFON/user@email.tld as username.

And, lo and behold, it worked! Login succeeded (Access ACCEPT), plus a LogoffURL to call when we want to close the connection. And I can ping Google, so we're online.

So, if nothing else, this confirms that a WISPr login using FON credentials on a BTWiFi hotspot is possible; it should be pretty simple to make this fire automatically from DBUS although I need to figure out exactly which SSIDs it works with, and possibly how to supply credentials to/from other service providers.

There's a glaring vacancy for a WISPr client application for the N900, whether it's based on that bit of perl or not. Android has it, iPhone has it, BTWiFi supports it, I'm surprised that I could find no standard Linux clients for it and no adaptations for the N900. Hopefully, the more networks and the more sets of login credentials this works with, the more reason there is for someone to throw together an implementation of some kind.

More to follow, if I make any further headway with it...

Fredrik Wendt created a Maemo 5 app, Wifi Assistant which would make an excellent starting point for this.

His app's behaviour was similar to that built-in to iOS and Harmattan: bringing up a browser. But since the URL was configurable, it also supported auto-login, if the login portal supported GET requests.