The iPad at Princeton: DHCP Problem/WiFi Problem?

The Wall Street Journal wrote today that the iPad is having problems on WLANs at the campuses of George Washington and Princeton. While the GW problem has yet to be described in detail, Princeton's Office of Information Technology has described their problems. The Princeton problem is about DHCP, and it reminded me of another problem that I saw with the iPad's WiFi behavior.


First, the background. WSJ.com reported that 20% of the iPad's seen on Princeton's WLAN had been banned for "malfunctions that can affect the entire school's computer system." Then the office of IT at Princeton clarified the issue by saying that iPads continue to use IP addresses after their DHCP lease time expires. This indicates that there is an error in Apple's implementation of DHCP.

The reason I decided to write about this is that there is an error in Apple's WiFi that has some relation to the DHCP problem that threatens Princeton's entire computer system (a tad overdramatic, are we?).

An important note in Princeton's description of the problem is that the iPad only displays this bad behavior when it is locked. When the iPad is unlocked and active, it renews its IP address when it's supposed to.

When I found out that the iPad had to be locked to exhibit this bad behavior, I immediately went back to some of the captures that I did on the iPad using WildPackets OmniPeek. I found the exact odd behavior that I remembered about the WiFi: the iPad does not wake on DTIMs like it is supposed to. In fact, there were times that the iPad didn't wake at all for minutes at a time when locked. This is not supposed to happen if WiFi is implemented correctly in station devices. I don't know it it's related to Princeton's DHCP problem, but they both occur when the iPad is locked.

The way power save mode works with WiFi devices -- whether they use 802.11power management (a.k.a. Power Save Polling), 802.11e/WMM Automatic Power Save Delivery or 802.11n Power Save Multi-Poll -- is that stations are allowed to sleep in between the DTIM Beacon frames that are send out at regular intervals by the AP. Stations can wake more often than the time in between DTIMs, but they cannot sleep through a DTIM. The reason is that DTIM Beacons contain information about broadcast and multicast data that's been buffered at that AP. All stations need to hear that.

In any case, the iPad simply doesn't wake for DTIMs. It sure helps the iPad's battery life (I can certainly attest to the fact that the iPad seems to stay alive forever when it's locked), but it violates the 802.11 standard.

Could this problem of not waking for DTIM Beacons end up causing the DHCP problem reported at Princeton? I wouldn't think so, but then again I don't claim to be an expert on DHCP. I would think that if the iPad's DHCP is working properly, it would just renew the IP address when the iPad unlocks. The Princeton report indicates that the iPad is not doing that.

There is one missing piece of information that I'd love to look at, and that's a frame capture from Princeton's APs. I do wonder if the APs on Princeton's network are simply dropping any kind of DHCP lease messages coming from the DHCP server because the iPad is waiting too long to wake up when locked. Again, I am not a DHCP expert so I don't know if dropped messages from a server could cause this. Still, I'm very curious to know what type of APs Princeton is using and whether those APs drop data that stays in the buffer too long when stations sleep.

For now, this will all have to stay as speculation but if anyone hears more about the nature of Princeton's WiFi network, email me or drop me a line on twitter (sniffwifi) and I'll post anything new that I get.