iPhone OS3.0 introduced a change in the way a device authenticates through WiFi. If the phone detects that a Login page (ie Captive Portal) is displayed on initial connection, it ‘traps’ this and displays it when the WiFi connects and obtains its IP address from DHCP.
The page that appears correctly shows the fields for username and password, together with the Connect button. However tapping either “Done” (part of the ‘trap’ page that iPhone 3.0 displays), or the “Connect” button itself have no effect – the page is never submitted.
Cancelling-out of this causes the device to release its IP address making it impossible to go into Safari and enter the login credentials there.
I was wondering if anyone else has come up against this? As more and more people upgrade their phones (and presumably iPod Touches) this is going to become more problematic.
It seems the iPhone does a DNS lookup on http://www.apple.com prior to redirecting to the Captive Portal page. If the DNS lookup fails, the phone doesn’t display the login screen within the WiFi app, and more importantly, doesn’t lose the assigned IP address. The user can then open Safari and log in as normal through the captive portal.
To get DNS lookups on http://www.apple.com to fail I created a DNS entry for apple.com without any ‘A’ records on the ZeroShell server.
This gets around the problem, but does mean that clients can’t get to apple.com pages. Better than none at all though 😀