Can I trigger a mobile client to automatically launch a web browser when connecting to wifi?
Assume that you have complete programmatic control over a wireless router (running say OpenWrt or DD-WRT - linux). The router is configured to broadcast an ssid, and the network is wide open.
A mobile user (iPhone/Android/BB) walks up.
1) on iPhone, if the device is not currently wifi connected, a dialog appears that offers to connect to available SSIDs. The user picks my ssid and connects. Is there a way, from my router (say using Bonjour or ??) to trigger the iPhone to launch the web browser and try to load the home page, or an autoconfig url automatically?
2) any different answer for Android/BB?
The reason is that in a 'walled garden' application I need to be able to pop up a greeting page and don't want the user to have to fumble around loading a default page first.
Any and all thoughts appreciated! Thanks RM.
Update - I think the answer may lie in either 802.21 or UMA. I read somewhere that ATT uses this with iPhones for authentication.
On iPhone there is a switch called 'autologin' when connecting to a wifi gateway. If you turn that on, the iPhone sends an HTTP request, and receives a redirect from my hotspot, and then I send the welcome page. (the spot is totally open). Problem is that iPhone seems to be waiting for something specific - it doesn't change from '3G' to wifi and may eventually time out. Also it still displays the 'Login' banner docked to the top of the window.
Anyone know of documentation for the frames I need to send to do a proper autologin?
Answer
What you're describing is a captive portal system (hotspot, walled garden, etc). This functionality can be implemented with several application on openwrt. Check out another answer for details on each specific option offered in openwrt Answer.
There are a few common techniques to implement a captive portal
HTTP 302 Redirect
The most common technique is to simply block all out bound traffic on the network and then redirect any port 80 traffic to your own portal page, either local or remotely hosted. This portal page would then provide the means to "authenticate" the user (by poking a hole in the firewall). There are layer 2 methods such as chillispot which provide all the same functionality and can be authenticated against a radius server if you wanted to get fancy.
DNS Rewrite
Another technique is to use dns rules to rewrite any dns query to resolve to your own webserver which will then present the user with a login page, once the user has "authenticated" you simply updates their dns, or allow the dns request from that user to pass upstream.
IP Redirect
This technique often times overlaps a bit with the HTTP redirect. Essentially you redirect their requests to a new destination IP. You could setup a squid proxy to then handle these requests.
Both iOS and android devices will detect for captive portals by simply checking for a standard URI resource (eg: http://www.apple.com/library/test/success.html) and if that resource is blocked then you're offline, if that resource gets 302 or 307 redirected then it assumes there is a captive portal in place and they will open a browser. If that resource is found then they assume you are online and no browser is auto opened.
Android will open the standard browser on the phone or tablet to allow the user to authenticate. iOS devices will however open a pseudo browser which is a limited application which doesn't allow things like video playback popups etc.
The WISPr protocol I believe was originally intended for devices which do not have a web browser to accept the terms and conditions and thus allowing these devices a generic protocol to accept and authenticate against a captive portal. I'm not even sure that the WISPr protocol was ever really accepted. (perhaps they redrafted it)
(Didn't realize how old this originally was, sorry)