Princeton University’s Office of Information Technology has posted a document describing networking problems suffered by roughly half of the 40 iPads on campus. The problem isn’t so much experienced by the iPad as caused by it – here’s what’s happening. (Since I initially wrote this article, I’ve heard of other sites experiencing the problem, including the University of Washington and George Washington University.)
The iPad uses DHCP (Dynamic Host Configuration Protocol) client software (in the iPhone OS) to request network configuration information – most notably an IP address – from a DHCP server. That IP address is typically “leased” to the DHCP client for a period of time; once that lease expires, if the DHCP client is still online, it asks to renew the lease and retain its IP address. If the client is not online when the lease expires, the DHCP server is free to assign that IP address to another device. When the DHCP client returns to the network, it requests and receives a new IP address.
The problem seems to be that the iPad, in some situations, is failing to renew its DHCP lease but continuing to use the previously assigned IP address. Because the lease wasn’t renewed, the DHCP server believes it is free to reassign the IP address. If that IP address is reassigned to another device while the iPad continues to use it, both devices end up using the same IP address, which can cause loss of network connectivity, confusing dialogs as operating systems attempt to handle the error condition, and more.
Princeton is working with Apple to resolve the problem, which is believed to lie with the DHCP client in iPhone OS 3.2, and which should be easy to fix with an update to that version of the iPhone OS. In the meantime, Princeton recommends that iPad users not connect to the campus network because if an iPad malfunctions, it may need to be blocked to prevent it from causing problems for other network users.
Who’s likely to experience this problem? Primarily institutions with large networks that rely on DHCP for a constantly changing collection of network devices. Home users and those with small networks aren’t nearly as likely to experience IP address collisions due to this problem.
If you do run into this problem on a small network you control, there are a variety of possible solutions:
- Assign a static IP address to your iPad and configure your DHCP server to avoid handing out that address to other devices. This fix isn’t feasible on a large network with a lot of devices because it requires too much manual intervention.
- Configure your DHCP server to reserve a particular IP address for your iPad. I tried this in AirPort Utility using the client ID approach to identifying the iPad, but it didn’t work; it’s possible the MAC address approach would work better. This approach also requires too much manual intervention to be useful on a larger network.
- Set a very long DHCP lease time so the DHCP server is much less likely to reassign the iPad’s IP address to another device. Trying this on a large network would likely tie up too many IP addresses that weren’t actually in use or require the use of NAT.
It is worth noting that, despite a quote in The Daily Princetonian article linked above, this DHCP problem is almost certainly unrelated to the Wi-Fi problems that have plagued some iPad users (see “Some iPad Users Suffer Wi-Fi Woes,” 6 April 2010).
Nevertheless, here’s hoping that Apple fixes this problem soon, not because it’s necessarily causing all that much trouble even for large networks, but because it would be a shame if the iPad garnered a bad reputation among network managers based on what should be an easily fixed bug, given that DHCP is a long-established standard.