Is this the fault of the iPhone - With poll!

[Smilin]

IPhones flooding wireless LAN at Duke University

http://www.networkworld.com/ne...71607-duke-iphone.html



Ok, disclosure time. In case you didn't notice I posted this simultaneously in the "networking" and "all things apple" forum. I was mostly curious to see what sort of bias may exist. The results of "Who's fault" are in:

The networking forum almost unanimously agrees that it's Apple's fault:
Apple - 14
Cisco - 1
Duke IT -2

The Apple forum believes it is Duke IT by a one vote margin.
Apple - 6
Cisco - 1
Duke IT -7


Networking poll link:
http://forums.anandtech.com/me...=2073554&viewresults=y

I didn't vote myself.

 

[spidey07]

Pretty obvious it's a software problem with Apple. The wireless net is just doing what it is supposed to do.

From the behavior describe the iphone should be banned from wireless networks until there is a software update to fix it.

Sending out 10s of thousands of arp requests per second is bad. m'kay?

 

[DnetMHZ]

Ah yes, the iPhone DOS attack feature!

 

[Goosemaster]

Originally posted by: DnetMHZ
Ah yes, the iPhone DOS attack feature!

dude..seriously....that's what it's doing....


so badass.....forget a lappy with some apps on it...just fire up yoru cell


crack team of specialists: DDoS'ers in the English classes...no wait their at bio...chem....

 

[Tegeril]

Not seeing this problem at all in my experience.

Interesting that of all the universities nationwide, only Duke is having this problem?

 

[spidey07]

If the article is correct, and the iPhone is truely generating the arp requests, then it is clearly a bug with the iPhone.

As far as it only happening at Duke, could be a number of things that would cause that. Eitherway, a device should not do what the iphone is doing.

 

[HermDogg]

Yeah, it's highly unlikely that only iPhones at Duke are the ones afflicted by this flaw, if it were a flaw in the iPhone. Chances are it's Duke's network.

 

[blinky8225]

Crap, I'm going there this fall. I hope that they get it fixed.

 

[Nothinman]

Chances are it's Duke's network.

Even if it's a strange side effect of Duke's network setup the iPhone should not be sending out thousands of ARP requests a second so it's still a bug in the iPhone.

 

[spidey07]

Originally posted by: Nothinman

Chances are it's Duke's network.

Even if it's a strange side effect of Duke's network setup the iPhone should not be sending out thousands of ARP requests a second so it's still a bug in the iPhone.

If the sniffer trace is interpreted correctly, then the iPhone is arping for an incorrect address. The blame lies purely with the phone/client device. We're talking 18K per second at 10 Mbit/sec. Something is seriously wrong if the client is doing that.

99.9% of all wireless network problem (outside of noise) are the client and it's software.

Essentially the iPhone does not adhere to protocol standards, specifically 802.11. I'd be surprised if it is wi-fi certified with this kind of behavior. The only other thing could be CCX/aironet extensions are trigging the bug.

 

[HermDogg]

Again, why is it ONLY happening on Duke's network? You would think that it might happen somewhere else, and if it did it would be huge news (as the Duke story is) because it's about the iPhone. Read the /. comments for a more in-depth discussion, but I highly doubt a phone is sending out 18K requests per second. Why would they even put such a functionality in the phone?

 

[spidey07]

Originally posted by: HermDogg
Again, why is it ONLY happening on Duke's network? You would think that it might happen somewhere else, and if it did it would be huge news (as the Duke story is) because it's about the iPhone. Read the /. comments for a more in-depth discussion, but I highly doubt a phone is sending out 18K requests per second. Why would they even put such a functionality in the phone?

Because of a bug in the phone. That's the big if, IF the trace is interpreted correctly. IF the phone is indeed spewing out that many arps it's solely the phones problem.

A good 99% of the posts in the slashdot thread are completely and totally off base without an understanding of how wireless or networking in general works, specifically how cisco's solution works.

But without seeing the trace and having full access to their network and architecture I can only guess and assume the information presented is true. A bridging loop is out of the question (and not possible using the gear duke is using), because if there was one you would see other broadcast/multicast frames...not completely dominated by the iphone but by other devices as well.

given that this is a campus network however I can hazzard a very good guess as to what architecture they are using and how it is setup.

 

[Nothinman]

Again, why is it ONLY happening on Duke's network? You would think that it might happen somewhere else

And why is it ONLY happening with iPhones? You would think that it might happen with some other wireless devices.

but I highly doubt a phone is sending out 18K requests per second. Why would they even put such a functionality in the phone?

It's no functionality, it's a bug. 18K ARP requests/s isn't exactly something that you can confuse with something else.

 

[spidey07]

I'll back up for a moment as I've tossed something things around in my head...

1) This kind of a layer2 broadcast storm does indeed REAK of a layer2 loop (bridging loop) and could generate these rates as frames are constantly forwarded via the loop.
2) This kind of storm could knock out the access points and spike the processors on the APs and the controllers.
3) Something is seriously wrong if such a loop exists, if true then duke IT is to blame.
4) If there is a bridging loop it will stay that way until rectified even if the client leave the BSS
5) Why do only access points with iPhones (assumption) exhibit the symptoms?
6) With a lightweight AP solution there has to be some seriously funky stuff going on to create a L2 loop.
7) If the symptoms go away when the client disassociates then HIGHLY unlikely it is a bridging loop.

so what I'm saying is I have to assume the analysis of the trace is correct and the iPhone is truly sending these frames and they aren't constantly being looped. Because if they are looped you would have to try VERY hard to make that happen and break just about every "good network design" rule there is.

 

[Tegeril]

I'm surprised the iPhone is powerful enough to cause that kind of problem.

 

[Nothinman]

I'm surprised the iPhone is powerful enough to cause that kind of problem.

I'm not, it doesn't take much power to send thousands of tiny packets.

 

[nweaver]

Originally posted by: Nothinman

I'm surprised the iPhone is powerful enough to cause that kind of problem.

I'm not, it doesn't take much power to send thousands of tiny packets.

indeed. When we test roaming over wireless, we just have little mcast utilites that stream mutlicast packets at less then 10ms per packet. I've done that on crappy little RFID readers that have no processing power to speak of.

 

[AmigaMan]

Turns out it WASN'T the iphone to blame, but a faulty Cisco router.

http://www.macworld.com/news/2...o/index.php?lsrc=mwrss

silly dookies, when will they learn? I'm actually surprised they didn't blame it on their Lacrosse team

 

[Nothinman]

And yet, unless I'm missing something, they still don't say what the real problem was.

 

[AmigaMan]

Originally posted by: Nothinman
And yet, unless I'm missing something, they still don't say what the real problem was.

The statement on Duke's site said "Cisco worked closely with Duke and Apple to identify the source of this problem, which was caused by a Cisco-based network issue. Cisco has provided a fix that has been applied to Duke's network and there have been no recurrences of the problem since."

It is kind of vague. Could be network configuration or hardware or software.

 

[Tegeril]

Originally posted by: Nothinman
And yet, unless I'm missing something, they still don't say what the real problem was.

But that's not news. It's only news if the iPhone is the problem.

 

[spidey07]

Originally posted by: AmigaMan

Originally posted by: Nothinman
And yet, unless I'm missing something, they still don't say what the real problem was.

The statement on Duke's site said "Cisco worked closely with Duke and Apple to identify the source of this problem, which was caused by a Cisco-based network issue. Cisco has provided a fix that has been applied to Duke's network and there have been no recurrences of the problem since."

It is kind of vague. Could be network configuration or hardware or software.

Fine. So for the first time in history it actually is a network problem. Go figure.

Otherwise I'd blame it on Fat Angus.

 

[erikistired]

everyone who voted apple gets their pinkie removed with a cigar cutter. that oughta learn you!

 

[spidey07]

Originally posted by: fisher
everyone who voted apple gets their pinkie removed with a cigar cutter. that oughta learn you!

You don't remember AppleTalk.

That alone means apple should not step foot near a network.

 

[erikistired]

Originally posted by: spidey07

Originally posted by: fisher
everyone who voted apple gets their pinkie removed with a cigar cutter. that oughta learn you!

You don't remember AppleTalk.

That alone means apple should not step foot near a network.

unfortunately i do remember appletalk, but that does not make apple guilty this time.