So many ways they could do it, but for some reason it was done as BT Openzone WiFi. Why the hell?
First off, why not just have a WPA2 password - simple - easy - and works on everything (even my camera). But what the heck - they are in a secluded spot with a large floor area - why not have an unsecure wifi for the meeting areas. After all, anyone able to get to the wifi could ask reception for the password to use. That would, by far, have been the best option.
But no, it is Openzone with a web portal.
I recall being slightly impressed that iThings automatically pop up with the login portal page when you select such a WiFi. I assumed it was a feature of the WiFi association or DHCP somehow. That would make sense. But no - it seems Apple simply try and access a known apple web page and if that not as expected then the pop up whatever they do get assuming it is an access portal.
Clever, but not quite what you want as it is an apple.com page. Why the hell not a special portal.apple.com domain which one could intercept at DNS level to provide a welcome page on a wifi. What they have done only really works with a captive portal at IP level, which is a pain to do.
A better way would be portal.apple.com or some such as a domain.
A better way still would be an RFC defined portal.invalid, or some such.
Even better would be a DHCP attribute for "welcome URL".
One could perhaps do a Bonjour style "welcome" domain on the LAN.
So many ways that could have been so much more standardised and flexible.
OK, so why the rant - it worked didn't it?
Well, yes and no. Sorry BT Openzone, but you are severely broken - just try and use an iPhone or iPad at an event at the hotel. Even when I have tried to use such things at BT Tower it is as bad. Every damn time the phone re-associates at a WiFi level (i.e. every time you go to use it) it wants the damn portal and password again. That was getting so tedious it was unreal. And then, to top it all, my camera wifi could not work, so ended up camera wifi to iPhone personal hotspot on to 3G to get a few photos on to the web, and then download via Openzone on to iPad, crop, and post to facebook. How annoying.
Anyway, by far the facebook star of the even was Jimi - who took masquerade ball to a whole new level. Well done, and I do hope everyone enjoyed themselves.
Have you seen anyone using the 511 HTTP status code for this?
ReplyDeleteWell if you will insist on using these hideous free wifi things - who knows, it might have been a rogue sat nearby with a wireless AP attempting to be a man-in-the-middle to harvest your login credentials - you get all you deserve :)
ReplyDeleteI'd have thought a man like yourself would do all in his power not to use such things (especially a BT service) - I know I do, I like to know where my data is going.
Android (Jelly Bean) does something similar.. prompts you to log into public wifi. Always thought it was an RFC because it brought up the right login page - your explanation is probably what it's doing though.]
ReplyDeleteThe ones I've used (O2 and Purple Wifi) remember your phone for a while so if you lose connection you're still logged in.
Yes, fairly similar:
Deletehttps://github.com/android/platform_frameworks_base/blob/master/core/java/android/net/CaptivePortalTracker.java
It basically checks that http://clients3.google.com/generate_204 gives it a 204 (no content).
I quite like the way the Tube wifi works at the moment -- non-HTTP just works so background syncing happens without any interaction, but on visiting a HTTP site it gives you a banner.
The problem with just handing guests a WPA2 pass is that you don't keep track of who's using your connection, so if someone does bad things, it's very hard to trace it back to who did it.
ReplyDeleteMy understanding of the various systems employed by the Cloud, BTOpenzone, O2 wifi, etc, is that they actually track who is using the connection.
But so many such things rarely work, I have frequent trouble with them. The most common one, oddly, seems to be that I connect to the open network, then my phone sits on "obtaining IP address" for ages and gives up, retries, fails, etc. Making it seem like there's a DHCP problem somewhere. But I've been in situations where it works for some devices but not others. Odd.
It was one password for all!
DeleteDepends on the provider/location.
ReplyDeleteFor instance the BT openzones in Starbucks popup a captive portal that you *Can* login to with your openzone credentials but it's a bit pointless seing as Starbucks have opted to make it free you can just hit the connect button on the portal and it goes straight through anyway...
Some operators have an App for the iDevice that automates the login process, I have one from my mobile carrier that works on the Paid Openzone hotspots (although for some reason my credentials don't work for the "Fon" style ones)
The Cloud is a bit of a weird one as if you are a Sky Broadband customer you can register your device with Sky and it will authenticate using the Mac address (Secure... NOT) but you will still get the captive portal, but it will basically say "you are now online with sky click here to continue" instead of prompting for authentication.
Coming Soon, AAWIFI?
ReplyDeleteI only use Wi-Fi hotspots if I'm really down on my luck.
ReplyDeleteI tend to use my 3 One Plan service, tethered, since they seem to have coverage almost everywhere anyhow, and only resort to Wi-Fi if they and T-Mobile can't muster up some coverage.
My favourite Wi-Fi fail was the O2 hotspot - they were recently added to a lot of Costa outlets, where some had previously had a perfectly usable "The Cloud" service. To register on O2 Wi-Fi you first had to provide your details including a mobile number where they would text you a code to complete registration (a one time thing I believe)
Um... yeah except the whole reason I had reverted to Wi-Fi was that this outlet had zero mobile coverage on any network. So I couldn't use the Wi-Fi at all. Think that trumps your "captive portal" for annoyance!
It doesn't quite work how you describe it - this is the WISPr protocol. When the device connects to the wifi, it makes a web request (yes, the idevices make a request to apple.com, but they don't have to - it could be any web page). If you're behind a captive portal, the portal issues a redirect to a page with some embedded XML (that's the WISPr bit) and the normal captive portal login page. You log in as normal and the device scrapes your login credentials from the POST (yes, yuck!) and caches them, so the next time you end up behind that portal, instead of popping up the login page it automatically posts your credentials to the place the XML told it to.
ReplyDeleteThe usual way to handle this is with a transparent proxy - when you're not logged in, that intercepts *all* your web requests and redirects them to the portal login page (so it doesn't matter what page the device requests, it'll always be redirected to the portal). However, there is no reason why you can't futz with the DNS server that's handed out by DHCP and have it intercept all DNS requests and redirect them. However you do it, you still need to block traffic at the IP level anyway, of course.
As for re-requesting the auth every time you connect to the network, I imagine that means that BT have buggered up the WISPr XML.
I've recently spent a *lot* of time faffing with WISPr as a result of Apple's complete failure to properly support standard authenticated proxy servers on iOS - iOS provides a nice place to set your proxy address and login credentials, but very few apps bother to use them properly - I've seen any combination of:
1. Working properly.
2. Using the proxy but still popping up an authentication box, even though the auth credentials are set.
3. Completely ignoring the proxy settings entirely.
4. Sending broken authentication credentials (for example, the ebay app sends your username as your password!)
(1), (2) and (3) are all observed in the standard Apple apps that ship with the devices, as well as third party apps. In the case of (2) you get a separate auth dialogue box for every application, since the cached credentials aren't shared between them.
Not being able to authenticate a device is a complete pain in a corporate environment, so we settled on the idea of using the WISPr protocol. This is a protocol that was invented and documented by Apple, but the documentation is no longer officially available because it is so patent encumbered. However, unavailable documentation isn't really a big deal since it appears that Apple's implementation doesn't even follow their own documented protocol specs, yay!
(And no, Google aren't a lot better either)
I appreciate that it intercepts all traffic not a specific page - my point was that if someone does want to have a "pop-up", then directing a specific page (using DNS or IP) is a lot simpler than redirecting all pages, and can also be done in cases where you don't want to block access in the first place, just have a "welcome" splash screen when you connect using a simple local DNS override for one specific page.
DeleteSo proxy the target page and redirect would work, yes?
DeleteSo proxy the page and redirect would work, yes?
Deletebtw I hate blogger's useless reply as - If I'm not logged in and my gmail user isn't displayed and I click publish it blanks out my reply and doesnt' tell me if it's submitted the message. iirc we get an 'awaiting moderation' type message. That's why you might be gettng 2 posts of all my comments because I've no idea if they've been sent for moderation or blogger has just cast them aside...