iOS captive-portal detection

An iPhone or iPad that has joined a network before will try to reuse the IP address it had last time. That is good for reconnection speed and battery life, and it is a problem on guest networks, because the captive portal depends on the device going through a full DHCP handshake first.

What goes wrong

Where the wireless network does not enforce DHCP, an iOS device may:

• reuse a cached address from an earlier session on the same SSID,
• skip the DHCP exchange entirely unless something forces it to revalidate,
• end up with an address that no longer matches the current network, and
• fail to trigger the Captive Network Assistant, the component that pops the portal up on its own.

The symptom a venue reports is not usually “no internet”. It is that the portal appears late, appears only after the guest opens a browser and tries a page, or does not appear at all while the device shows as connected.

The fix on a Cisco Wireless LAN Controller

Cisco WLCs expose a per-SSID setting called DHCP Addr. Required. With it enabled on the guest SSID, the controller:

• blocks client traffic until the DHCP handshake completes,
• forces every device to obtain a valid address before it is allowed on,
• causes iOS devices to perform a fresh DHCP discovery on association rather than reusing a cached address, and
• guarantees the address, gateway and DNS are correct before the portal is expected to load.

The result is that iPhones and iPads open the portal consistently, at the moment they join.

How this relates to Option 114

Enforcing DHCP and advertising the portal address are two halves of the same problem. Enforcement makes sure the device asks; DHCP Option 114 makes sure the answer tells it where the portal is. A deployment that gets detection right usually does both.

Related

• Captive portal: what the guest sees, and captive-portal detection including Option 114.
• Guest Wi-Fi captive-portal FAQ.