Editor’s Note: This story is reprinted from NetworkWorld.
The Wi-Fi connection on Apple’s recently released iPhone seems to be the source of a big headache for network administrators at Duke University.
The built-in 802.11b/g adapters on several iPhones periodically flood sections of the Durham, N.C. school’s pervasive wireless LAN with MAC address requests, temporarily knocking out anywhere from a dozen to 30 wireless access points at a time. Campus network staff are talking with Cisco, the main WLAN provider, and have opened a help desk ticket with Apple. But so far, the precise cause of the problem remains unknown.
“Because of the time of year for us, it’s not a severe problem,” says Kevin Miller, assistant director, communications infrastructure, with Duke’s Office of Information Technology. “But from late August through May, our wireless net is critical. My concern is how many students will be coming back in August with iPhones? It’s a pretty big annoyance, right now, with 20-30 access points signaling they’re down, and then coming back up a few minutes later. But in late August, this would be devastating.”
That’s because the misbehaving iPhones flood the access points with up to 18,000 address requests per second, nearly 10Mbps of bandwidth, and monopolizing the AP’s airtime.
The access points show up as “out of service.” For 10-15 minutes, there’s no way to communicate with them, Miller says. “When the problem occurs, we see dozens of access points in that condition,” Miller says. The network team began capturing wireless traffic for analysis and that’s when they discovered that the offending devices were iPhones. Right now, Miller says, there are about 150 of the Apple devices registered on the campus WLAN.
The requests are for what is, at least for Duke’s network, an invalid router address. Devices use the Address Resolution Protocol (ARP) to request the MAC address of the destination node, for which it already has the IP address. When it doesn’t get an answer, the iPhone just keeps asking.
“I’m not exactly sure where the ‘bad’ router address is coming from,” Miller says. One possibility: each offending iPhone may have been first connected to a home wireless router or gateway, and it may automatically and repeatedly be trying to reconnect to it again when something happens to the iPhone’s initial connection on the Duke WLAN.
They’re still sorting out what that “something” is. On two occasions, one last Friday and one today, Monday 16 July, both users seemed to be behaving completely normally, yet both iPhones started flooding the net with ARP requests. In both cases, the user first successfully connected to the WLAN at one location, and then moved to another building, where the ARP flood began. “It may have something to do with the iPhone losing connectivity and then trying to reconnect in a new location,” Miller says.
Most of the W LAN is comprised of Cisco thin access points and controllers. Some older autonomous Cisco Aironet access points tend to uncover the flooding first, since they try to resolve the ARP request themselves. But Miller’s team has seen the CPU utilization on the WLAN controllers spiking as they try to process the request flood passed on to them in control traffic from the thin access points.
“I don’t believe it’s a Cisco problem in any way, shape, or form,” he says firmly.
So far, the communication with Apple has been “one-way,” Miller says, with the Duke team filing the problem ticket. He says Apple has told him the problem is being “escalated” but as of mid-afternoon Monday, nothing substantive had been heard Apple.