Slashdot Mirror
IPhones Flooding Wireless LAN At Duke
coondoggie sends us to a Network World story, as is his wont, about network problems at Duke University in Durham, N.C. that seem to be related to the iPhone. "The Wi-Fi connection on Apple's recently released iPhone seems to be the source of a big headache for network administrators at Duke. The built-in 802.11b/g adapters on several iPhones periodically flood sections of the school's 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.'" So far, the communication with Apple has been "one-way."
"I don't believe it's a Cisco problem in any way, shape, or form," he says firmly"
How do they know that?
Sounds like they are having some issues with arp-whois being propagated across the subnets. Knowing Apple, each time these iPhones try to 'rendezvous' with all the Macs or iTuned PCs they refresh their ARP tables off the entire campus. Something is fucked up with their network machines if the arp boroadcasts are seen by the entire campus (hence the 30 access points going at once).
What they need is an AP isolation: the connected client should not (easily) see other subnets and should definitely not be able to spam ARP broadcasts across subnets.
Some BOFH admin really screwed up his net config.
Umm, a bunch of ARP Requests by a few mobile devices shouldn't be knocking out a Cisco router. These AP's are supposed to be able to withstand much worse than a few of these things.
I call bullshit. I say it's their IT/Computing Department is blaming their poor infrastructure on iPhone.
The number of students who use a wireless network for basic needs is rapidly growing at Duke. As a recent Duke graduate, I've been in a number of classes where tests are administered over the WLAN using Blackboard (burn BB to hell!). If a WLAN AP goes down, and that's during a test, you've got the grades - and unhappiness - of 40+ people/class on your head. Given that we're a rather nitpicky bunch over our grades, grade unhappiness doesn't end well for those who cause it... So yes. Wireless is critical at Duke.
Site slashdotted out? Use SharePapyrus under Site Directory
spend thousands of dollars on expensive Cisco AP equipment, a factor above consumer grade systems, and something goes wrong, the extra instrumentation doesn't help and the vendor just blames somebody else? Is this a good reason not to go with expensive equipment, or just colossal incompetence of the administrator who configured everything?
Actually I was in an Apple store last Thursday and they were having the same problem. I was trying to connect to their network with another non apple device and finally connected on third attempt. The store employees were all aware that their phones were having trouble connecting and staying connected to the wireless. Many of the phones were having to connect through ATT.
Oh come on. MAC registrations are almost wholly automated at any given large university--including Stanford, Berkeley, UBC, UC Davis, and Penn, where I have had personal experience. All you do is login with your staff (or I suppose student) account information and head to a page where you enter the MAC address(es) of your computer(s) along with your employee number and birthday or some other personally identifying information they already have on file. You click submit, and within 30 minutes you get an email saying your computers have been authorized.
The only downside is that some schools require this must be done from an authorized computer, so you have to head to a computer lab or classroom the first time you do it. Other schools allow you to get into the system from any Internet-connected computer, which is the ideal solution, since it's behind a two-part authentication system anyway.
An interesting factoid on this, though a little OT: iPhones do not appear to implement rendezvous/bonjour/zeroconf. I can't connect to any of my Mac zeroconf hosts by connecting through the *.local domain names that bonjour usually sets up, and I've read others are unable to do this as well.
Don't blame me, I voted for Baltar.
Actually, it's probably really an ARP request. They probably have a very large, flat network and when the iPhones does an ARP broadcast request the AP gets overloaded by the results. This was a known problem with the old Aironet AP's, one of the senior software guys at Cisco/Aironet produced a one off patch for a large university client for the old VxWorks based AP's when I supported them back around the 2001 timeframe. It was actually one of the best examples of object oriented code I had ever seen, he changed the definition of the ARP buffer in one place, recompiled and everywhere that ARP was used the code was updated, very slick.
There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
You make the mistaken assumption that the goal of MAC address restrictions on university campuses is to crack down with an iron fist. It's not. Since the networks are so large and fluid, with tens of thousands of users and machines, it's pointless to expend tremendous funds to lock down the Internet like a Defense Department project.
MAC address filtering is simply a roadblock to keep the general public off the network. This need must be balanced with the high number of legitimate visitors on campuses (for presentations, symposiums, conferences, guest lectures, and all sorts of other purposes) which need to have a way to access the Internet (simple using preconfigured authentication tokens).
The students and staff are not the concern at all. Their MAC address spoofing and playing around is simply a matter of course. It's people outside the campus community that they want kept out. A combination of authentication and MAC filtering pretty much takes care of that. Even if they do successfully spoof a valid MAC, they don't have a username/password to get past the login screen. If they've gotten all of that, there's really nothing practical that will stop them from gaining access. It's also irrelevant for that handful of people. There's little point to waste any time or money tracking them down or even trying to find those isolated incidents unless a crime or breach occurred as a result.
If Apple can't make hardware that works, and/or won't own up to their problems and fix them, then ban all iPhones from connecting to the university WiFi network via their MAC vendor and device ID portions. After all that is what the structure of a MAC is for - so the network admins know what kind of devices are being used.
Banning iPhones campus wide because they are faulty would trigger some nice nasty press for Apple and piss off a lot of owners of the device - I imagine they would fix the problem much faster (or at least respond to the ticket!)