we have a customer who is implementing hotspots using cisco, aruba and Moto gear as a test. we are seeing some dificulty with the iPad clients using the customers proxy service. for sanity check, It would be very helpful to hear some feedback if anyone has had customers with iPads on their hotspot network and any issues they had to overcome. afshin
iPads on Moto-HotSpot// Expert user has replied. |
4 Replies
thanks for the great heads up Marc. if you have had any experience with Hotspot, using Proxies and/or iPads please share any issues and/or fixes that youknow of. thanks, afshin
we are using the on-board Hotspot of the RFS7000. corporate users already have the "use automatic configuration script" button checked in IE and pointed to a .PAC file on the corporate proxy-server (Bluecoat product) which is downloaded each time (e.g. http://proxy.customer.com/pac-file.pac"). visitors comming into the facility have to manuall set this parameter on their devices. in case of the iPad, seems like they first have to start with no proxy, get connected and once authenticated put the proxy back in to get access to the Internet.
Afshin, Please be aware that iOS enabled devices (a.k.a iPhone, iPad, iPod) do not operate in the same way as OSX, Linux and Windows devices do with Captive Portals. Most operating systems require the user to manually launch a web-browser once they connect to a Captive Portal Wireless LAN for the web-browser session to be captured and redirected to the Captive Portal. This is a common process and is something that most end-users are familiar with.
When an iOS device is connected to a network with a Captive Portal enabled, the iOS device will launch a sperate application Apple calls a 'Web Sheet' that presents the login page to the user. This application IS NOT the Safari Web Browser but rather a stripped down web-browser that has limited capabilities. As this is not Safari can't tell you if it supports proxies or not! The 'Web Sheet' will launch if the iOS device detects that a Captive Portal is present on the network and will launch as soon as a iOS device connects to the Wireless LAN. The 'Web Sheet' will also close as soon as the user authenticates or accepts the terms and conditions and iOS device is on the network. As the iOS device uses the 'Web Sheet' and not Safari, any re-directs that are performed after the user authenticates or accepts the terms and conditions (i.e re-direct to a welcome page) will not be performed by the iOS device. This is because the ‘Web Sheet’ is a separate application to Safari which closes as soon as the user is granted access to the Internet. This is expected behavior and is something that Apple has specifically implemented on the iOS devices. There is currently no way that we (or Apple) know of that will allow Safari to be launched automatically from the 'Web Sheet' after authentication has occurred. We have asked Apple this question but have not received any response or work around. So the with this in mind once the iOS device has connected and authenticated to a Captive Portal using the 'Web Sheet', the user will have to manually launch Safari to browse the Internet. This is exactly how Apple expects the devices to behave and this is regardless of any vendors Captive Portal solution that has been deployed. Regards, Kevin
I worked with a customer who has 2 ESSID's on a single BSS(MAC). One of the ESSID's was for use with Ipad's and the IPADS would constantly switch between the 2 ESSID's. Microsoft/Intel clients could connect to either network. We resolved thiis by manully mapping the IPAD to a BSS with no other WLAN's There are also problems with the cert when using Ipads. I dont fully undrrstand the problem, but it sounds like the Ipsad has a very lightweight browser which does not have embedded certs