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."

No wonder

[marcosdumay (620877)]

"So far, the communication with Apple has been "one-way."

No wonder there is no answer... Apple people weren't able to receive any network package with all those iPhones around.

Re:No wonder

[User 956 (568564)]

"So far, the communication with Apple has been "one-way." No wonder there is no answer... Apple people weren't able to receive any network package with all those iPhones around.

Communication with Apple is always "one way". Or the highway.

Bet you 10 to 1...

[g-san (93038)]

...it's their network. Why are we only hearing about it here? They probably have a loop in their network or some kind of ARP forwarding active they don't understand. You would think something like this would get caught early on in testing with the iPhone, this kind of problem tends to stand out. I also doubt the iPhone has enough horsepower to pump out 10Mbps of ARP requests, sounds like a networking device is sourcing these packets.

Re:Bet you 10 to 1...

[blindbat (189141)]

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.

Lets focus on the real problem

[bhmit1 (2270)]

Any non-secured network (either where users can plug into the lan or over wireless) where a device is able to bring down the network should be considered defective. I've seen places were the entire lan was flat with users connecting on cisco's management vlan and could bring down the whole company by plugging in a device that advertised a new route to the internet (legit or not). To a similar point, if a device on a wireless network is able to flood the network, then the access points need to be tuned. Sure, they can jam the airwaves, and there's nothing you can do to stop that DoS. But, you don't have to turn 18,000 requests per second into something that broadcasts across the rest of the network. Every firewall app that I've worked with includes throttling and I would hope these APs do as well.

This doesn't mean that apple released a product without a defect. But if your network crashes because of a defective device, then you should fix your network first.

Taking out Cisco Router with ARP Floods?

[xRelisH (647464)]

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.

Re:Taking out Cisco Router with ARP Floods?

[technormality (1086527)]

18,000 arp requests a second? Smells like a spanning tree loop to me. Thats where I would start looking. Could be a single AP bridging the same vlan with spanning tree disabled. Anyone roaming into into its range could cause havoc.

Apple DHCP client

[papasui (567265)]

I'm a net engineer for one of the major US cable isps.. A VERY common issue I see with the Apple Airport Extremes is a problem with them declining offered leases infinitely. When this happens the DHCP server marks the lease as temporarily unavailable, the end result is a single offending Airport extreme can eat all the available addresses. The work around is to configure the dhcp server to ignore declines from the client. Regardless it's very annonying (and I'm typing this post on a Macbook so I'm not anti-Apple).

Re:Apple DHCP client

[Doctor Memory (6336)]

Actually, that's just what the server should do. The client is only supposed to send DHCPDECLINE if it detects that the network address is already in use. DHCP servers are encouraged to check any address offered (using an ICMP Echo Request) to make sure it is not in use. However, there's also supposed to be a switch to turn this off. DHCP clients are encouraged to check any offered addresses using an ARP packet. If the ARP packet generates a response (indicating that another machine already has the offered address), then the client should respond with DHCPDECLINE. Therefore, if the server isn't checking addresses before it hands them out, it stands to reason that it would mark them as "unavailable" if a client responds that the address is already in use. Unfortunately, the side effect would seem to be that a misbehaving piece of hardware could indeed eat all available addresses. I'd suggest that the remedy for that is to have the server check any declined address, and only mark it "in use" if it got a response.

So when you

[phoebe (196531)]

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?

Re:Interesting problem

[beheaderaswp (549877)]

What I want to know is what is a "MAC address request". I've never seen one. I've seen DHCP requests, ARP requests, even AARP requests- but not a MAC address request.

I didn't know MAC addresses were assigned dynamically.

But I'm over 40- what do I know?

Re:Interesting problem

[Architect_sasyr (938685)]

I don't know if this is a "better" answer, but I haven't liked the one's given yet: Initial DHCP request goes to ARP broadcast (which should NEVER make it past the AP/Authenticator depending on setup - much less into another subnet), a response is returned containing an IP address. Most units hold the IP address in temporary information and do another ARP request to see if anyone has that address in use (again to ARP broadcast). If it is in use then they try again, if not the unit assigns itself the IP address and joins the network. It then tries to find the ARP address of the DNS servers (look at it in wireshark or tcpdump - "who has x.x.x.x tell y.y.y.y"), the Gateway and whatever else your standard unit would be looking for (Domain Controller for a PC, Samba shares if you have auto-search enabled etc.).

My guess is that either there is no DHCP and the iPhones just try like crazy, or some other misconfiguration of the network is causing these. Couple this with potential interference from all the other iPhone devices in the area, which could (and probably does) cause dropped packets, and one has a veritable storm of ARP requests which could easily take out subnets. 8 wireless cards is enough to DoS a high end wireless access point (Yellow Laptop anyone) so it doesn't stretch the imagination to think that some iPhone's could do it.

My $0.02 AU

Re:Interesting problem

[kayditty (641006)]

I have no idea why no one on the entirety of slashdot knows anything about networks. If I were to reply to every wrong post in this thread alone, I'd be here all fucking morning, so I'm just going to deal with this one.

DHCP is not implicit in any network topology. It may be modern and 'expected,' but, jesus christ, every time there's a network discussion on this site, DHCP is strewn all over it like shit on a truck stop toilet. Just because you were born in 1995 and have an "ADSL" connection that uses DHCP (well, it probably uses PPPoE now) doesn't mean you're qualified to say anything, and it certainly doesn't mean there aren't real networks that have never even heard of the silly little protocol.

That said, the initial DHCP request does go to a broadcast address, but it certainly has nothing to do with ARP. It goes to the global broadcast address (MAC: FF:FF:FF:FF:FF:FF). There's no such thing as an ARP address. ARP is a network layer protocol lying atop Ethernet (primarily; it isn't limited to Ethernet, of course). It is a MAC address you are thinking of.

Your use of commas is worse than your knowledge of low-level network protocols, really. I don't even know why I bother. Whoever mods this shit up, go fuck yourself. And whoever's out there that actually does know what they're talking about (surely there's someone else out of two million users), like I do, fuck you for not replying and setting these morons straight. It's a ridiculous place to read for technological discussion, anymore.

Re:Most likely a Cisco bug - firmware upgrade need

[by Anonymous Coward]

In reality, it seems that your router tends to substitute its own MAC address for non-local ARP entries (since all non-local packets go through the router, you really don't have to know what the real MAC address is)

Say what? The last time I saw something equally screwy it was a Cisco LightStream 1010 (ATM switch) running LANE (LAN Emulation) that played no part in layer 3 at all, yet it was still building up an ARP table of every IP datagram that flowed through it (and wondered why it kept running out of memory).

If you send out an ARP for an "unknown address", you'll get no response - it's not up to the router to respond on behalf of "non-local packets", it's up to the client to determine that the destination is non-local (by using the network and mask together) then picking a suitable gateway (usually default) for sending the packet on its way.

Therefore, the client already knows it needs to send the non-local/unknown-addressed packet through the router so it explicitly ARPs for the router's MAC address (if not already cached) - nothing to do with trying to get the MAC of the remote destination.

Re:Interesting problem

[Icarus1919 (802533)]

That's preposterous. Summer is when teachers return to their coffins to rest. Who would the students learn from?

Re:Interesting problem

[MoOsEb0y (2177)]

Zombie graduate students.

Re:Critical?

[gravos (912628)]

Mod parent up. My university has gone to all-wireless too, and it's completely retarded because it's so unreliable. **A MICROWAVE OVEN IN THE KITCHEN KNOCKS EVERYONE OFF THE NETWORK**, for christ's sake, and that's to say nothing of intentional disruption.

Re:Critical?

[PCM2 (4486)]

Yes it is dumb. Run some cable and leave the wireless for students with laptops and shit. Cables are the best method for mission critical things anyways.

Yeah. Unless you're a university, and your "mission critical things" (remember the definition of "mission"?) include things like ... ohhh, I dunno ... students with laptops and shit?

Re:Critical?

[Citius (991975)]

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.

Re:Nothing new here

[by Anonymous Coward]

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.

MAC address REQUEST?

[by Anonymous Coward]

I'm sorry, but there's something a little OFF here. No wireless hardware requests a MAC address. It may use MAC to authenticate to a table, but it goes for a DHCP lease.

Slashdot...sigh...

Re:sigh

[HTTP Error 403 403.9 (628865)]

"18,000 address requests per second"

It's like me at the discotheque on Saturday night.

Re:MAC filtering is not a solution

[mr_matticus (928346)]

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.

Re:Economic class and higher education

[Dhalka226 (559740)]

Instead of being wealthy and pay tuition, you can also simply be smart and hard working.

He mentioned scholarships, though it was in an offhand way. You're certainly free to disagree with what he's saying, but insulting him twice in six sentences while "refuting" him with a point he already made is absolutely wrong on any level.

Besides which, your own point is really no gem either. Your advice to get a scholarship is to be smart and hard working? It's half true, sure. Colleges do give scholarships to people with good grades--though often you also need extra-curricular activities to put you ahead even though that really has nothing to do with intelligence or hard work, merely interest in organized activities--but those are limited. If every student in the nation suddenly became smart and hard working, it would still help only an exceptionally small percentage of them receive a scholarship. In fact, since Duke is a good school you can be relatively sure that the vast majority of students who are accepted there are already smart and hard working, so even in your limited example

I happen to think the way the OP handled himself was flamebait, but the question he raised about free education is a debate worth having. Preferably without insults.

Congratulations to your daughter for getting in, getting money and getting through--but just because she did doesn't mean everybody else can, even those equally smart and hard working.

Re:Cisco

[prisoner-of-enigma (535770)]

I am taking a cisco internetworking class and I do not think that it is similar to a DoS attack because a DoS attack involves changing the source address in the packets that are sent to a server. I do not think any students at Duke have found a way to hack the iphone to allow modified packets to be sent out.

Not to seem unkind, but it sounds like you need to finish your classes before weighing in on this subject. You do not seem to understand the nature of a DoS attack enough to comment properly on it.

To clarify, it has nothing to do with altering the source address. While some hardwired DoS attacks involve the spoofing of source addresses, it is not required. Any kind of action that prevents the target from functioning as designed constitutes a DoS attack, and flooding an AP with spurious MAC requests fits that description. Since the iPhone is doing this as part of its (probably flawed) design, no hacking of the iPhone is required.

The Cisco AP's and WLAN controller have little choice but to listen to whatever traffic the iPhone spews out. Sure, they can discard or ignore the traffic, but it doesn't change the fact that a rampant iPhone "attack" will consume shared air time even if such action is taken. With enough iPhones, any single AP can be completely overwhelmed even if it's ignoring everything the iPhone is throwing at it.

As I said before, you can't switch, route, or firewall air. You're always at the mercy of the person transmitting with the least control or scruples.