iOS 5.0.1 wireless Bug - DHCP

You are not the only one having this issue. Princeton University is having the same issue as well as our university. You can image the number of these iOS devices we have on a university campus and the network disruption they cause. It is almost inconceivable to me that Apple has not recognized and permanently fixed this issue. How complicated could the fix be?

Princeton's published research concludes that increasing the lease time on the DHCP servers could possibly eliminate the occurances of these conflicts across all versions. We have tried that as well and it does not seem to have an affect. They have also published workarounds for the devices themselves. We try to have the users practice them, but these work arounds are just not practical on a university system.

One other thing that we have found is that this issue is not restricted to the Apple iOS devices. It also shows up from MacOS devices using wireless.

I am very interested in knowing how we can push on Apple to help get this resolved.

Keep us posted. I am really interested in seeing what they say about this and tracking this!!!

Thanks for sharing.

I'm not sure exactly how this was resolved, but as someone who uses mutiple wifi-only iOS devices on the Princeton U. network every day, this is no longer an issue. As a matter of fact, there are now hundreds of iOS devices deployed with U. personel. And whatever happened, Andriod devices are still basically banned from the wifi network. And I never saw any evidence that OSX devices had a similar problem.

This is nothing a feature like DHCP Snooping, IP Source Guard and Dynamic ARP Inspection couldn't resolve. Why on earth would this be affecting the rest of your network? If everything is properly segmented, it shouldnt matter if that thing boots up with your e-mail servers IP address. If it is, you are using a big *** network like a /16 and simply dishing out certain ranges to certain functions rather than using proper subnetting. I really hope this is not the case as thats a big mistake.

If you have everything setup properly, I cannot see that device as affecting anything at all; if it came up with that IP on your wireless subnet, no devices in other subnets should ever be trying to talk to that thing since that IP range is supposed to be reachable elsewhere, like your server subnet, not the wireless subnet. Your other networks will always be forwarding traffic for your server to your server subnet, never to the wireless subnet.

If you are at all confused about what I am saying, let me ask you this. What is the default gateway for your Wireless devices and what is the default gateway for your Servers? If that answer is the same, there lies your problem. Hire a network engineer to clean up that mess. If it is not the same, then something like proxy ARP must be turned on since that incorrect IP should not affect anything other than itself with proper layer 3 boundaries.

If that is not an option, you should be able to use a combination of DHCP Snooping,IP Source Guard and Dynamic ARP Inspection to nip this problem in the butt if your running Cisco gear (if other gear, cross reference, I'm sure the feature exists with another name). The only way for it to cause havok is if the offending device is producing an ARP reply for your servers IP. If running Dynamic ARP Inspection, it should see the offender responding with an ARP for your servers IP which doesnt match what the DHCP snooping database has in it, and it will drop that ARP reply. If by chance that offending device did try to transmit as your servers IP, IP Source Guard's dynamic PACL should have dropped that traffic since its source IP does not match what is in the DHCP Snooping database.

I am not doubting that a bug exists here, however a robust network infrastructure would not be affected by what you describe. Those switch features were designed to halt malicious actions, whether performed intentionally or accidentally via a bug. A network engineer worth his/her salt would have implemented that in their design.

I agree with some of what you are saying. However, the problem this bugs is creating for us (it doesn't affect our servers or other parts of the network). It creates problems for other devices that need to be managed on that same subnet as well as other users. Not everyone has the luxury of having Cisco hardware. Apple should fix the problem instead of us having to work around it. I assure you, our network is NOT a mess.

Just because you personally do not experience the problem does not mean one does not exist. I use iOS devices daily as well on our university's network. I never have an issue. However, I see the havoc it causes on other devices and users daily. A lot of this issue showing itself has to do with what IP address space is in use at the previous hot spot you were connected to. If it was an address space that is not utilized by the university, then you will probably never see the problem.

Well, I wasn't suggesting that the problem "didn't exist." I was stating that the problem at Princeton has been effectively resolved for iOS devices. And I mispoke when I said Andriod devices were "banned" - I meant to say that the current solution (whatever it is) didn't include Android devices. That's what I know. And it's not based on my personal experience running my personal devices. It's based on first-hand knowledge of a large deployment of wi-fi only iOS devices by the University.

I don't usually repeat hearsay, but this tidbit was particulaly interesting. I heard that an "if network=Princeton" statement was added to iOS that changed the DHCP behavior when connected to the Princeton network. I think that's crazy (why would Apple fix it for Princeton and no one else?) but that's what I was told. I was also told that this fix was temporairily dropped in an iOS beta - then restored when "all heck broke loose." Again - just hearsay.

Ok, I understand you aren't running Cisco gear but whatever it may be those features are likely supported and should be running on your wireless network anyway. Imagine someone was doing this on purpose rather than it being a bug. They could easily disrupt the network they are directly connected to, in your case the wireless subnet. Imagine someone sets their IP to that of the default gateway!

Cisco, Juniper, Enterasys, whatever your running, those features are likely supported and are probably even called the same thing. Since your running DHCP, they would be very easy to implement especially if you have few to none static mappings on user access VLANs. I would suggest enabling these features on the switch(es) where your WLC's reside, as well as on all edge switches where a user can plug in directly. This should not have any fallout effect, it should only solve your problem. Test it out in your lab, its pretty cool stuff.

Good points. Definately worth looking further into. Thanks for the input.

Well here is what I found on my very simple home network. DSL gateway/router, wired XP desktop, Vonage phone adapter, DD-WRT WiFi repeater, WiFi laptop, D-link print server, Two iPod Touch's, and a Kindle.

Symptom was that my Vonage VOIP adapter would stop working. Rebooting the gateway router and the Vonage adapter fixed the problem, but it would be back the next day. After a LOT of testing and research, I came accross the Princeton posting about iOS problems with DHCP. Firstly I went to static IP on all clients except my iPod Touch's, but the problem persisted. Then I went to static IP on ALL my clients, including the iOS ones. The problem has gone away, and not returned.

All this tells me is that iOS is responsible and it has something to do with DHCP.

I'm not a networking guru so I would appreciate anyone else's comment on this .....

Hi,

I appreciate this issue appears old and many may assume it is FIXED, but unfortunately I assure you it is still there, even in iOS 8 (even latest version as of Jan 2015).

i run a medium (I'd say) educational boarding school network, with approx 450 simultaneous users that at peak times can have 500+ pupil wifi devices connected! (Most kids have at least a phone and laptop or phone, laptop and tablet... Some have more like AirPlay devices, speakers etc).

this issue is causing me a massive amount of support work trying to get infernal iOS devices to connect.

As I write this, a third of our users Apple devices are not connecting to the network due to them insisting on using their last acquired IP...! Our DHCP server logs are full of NACKs listing Apple MAC/Ethernet addresses and totally fictional IP's that are not part of the scope for the DHCP server on the Pupil dedicated WiFI SSID residing on their own (contained) VLAN.

I'm flummoxed at how to proceed, as whilst I sympathise with the issues the OP mention, I specifically took care to ensure the precautions Mr Network Engineer documents in his post above. Unfortunately even though the users with bad/naughty Apple iOS clients are wreaking havoc taking my servers offline, it is tiresome dealing with 20-30 users constantly in out out of out IT office complaining they can't connect - the worst part is that we can't even write up a fix or workaround to print and put in the dormitories as we don't know how to FORCE the device to rediscover the DHCP and work like they SHOULD do.

Any ideas?

Please?!

Sorry post above should say:

I'm flummoxed at how to proceed, as whilst I sympathise with the issues the OP mention, I specifically took care to ensure the precautions Mr Network Engineer documents in his post above. Unfortunately even though the users with bad/naughty Apple iOS clients are NOT wreaking havoc taking my servers offline, it is tiresome dealing with 20-30 users constantly in out and of our IT office complaining they can't connect - the worst part is that we can't even write up a fix or workaround to print and put in the dormitories as we don't know how to FORCE the device to rediscover the DHCP and work like they SHOULD do.

Can't even edit or use the forum with my iPad and Safari or Chrome - looks like another bug Apple!