Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

By the time the problem is "fixed" the other computer on the network has already detected that its IP address is in conflict by ARP, telling the user what happened (interrupting them) and has shifted to a new IP address (losing all of its active connections in the process).

(and yes: some routers hold on to only a certain number of inactive leases, and routers actually do get rebooted in home, office, and hotel environments quite often, crossing the boundary of the 1-2 day leases that are often given to clients.)



Once again, this is almost always a router misconfiguration problem. If you don't want this to happen configure your router correctly. Apple isn't to blame for other people's incompetence.

Plus, this seems to produce tangibly better results in the majority of cases. It perfectly fits Apple's style of optimizing for the common use case, even if the rarer gets worse.


I ask again: do you have any evidence that this is a problem in practice? I feel like this is something we would have heard about before, via some outraged blog post followed by Apple discussion board postings that get deleted by Apple.

How often do computers send out ARP requests to check on the uniqueness of their IP address? If it's less often than once per second or so (and I really hope it is), I could see how you could get away with having two devices with the same IP for a second here or there with no one the wiser.


Where I used to work actually had lots of problems with this. I vaguely recall it coming to a head a while after the iPhone 3G came out and/or about the time various staff members got macs, but I could be wrong. Anyway, it sprang immediately to mind when reading this thread.

It doesn't sound like it would be a big deal, but Windows (and Mac OS X, I've since discovered, mid-7 minute `svn commit'...) just drop the connection if there's an IP conflict. That's actually quite annoying, at the very least. You have to resubmit commits, restart getting latests, your FTP craps out halfway through, file copies go wrong, you lose your remote desktop connection, the code finishes compiling before your web page loads, etc. With any luck, you won't lose any work.

If you don't run your code on the same computer you write it on, you might be less lucky. The debugger craps out and you lose your place, or the file server goes wrong and your code gets an error and stops or whatever while you were in the middle of waiting for it to get somewhere specific. And if you use any home-written tools, they're probably going to be even less resistant to network failures of this nature than the stuff you paid for - which doesn't do a fantastic job in the first place. It all adds up.

Fortunately for me, I wasn't using Remote Desktop all that much, and the device I was working with attached via USB. And I didn't lose any work when the source control just stopped mid-operation. And I could just put headphones on, and block out my colleagues' cries of pain. So maybe that's OK then, and it's no big deal?

I'd like to be able to say what the eventual solution to the problem was, but I don't remember.


...do you have any evidence that this is a problem in practice?

When iPhone OS first came out, there was a bit of an uproar on many university campus networks that they were seriously screwing up the behavior of DHCP on networks with a very large number of transient clients.



I don't see how this has anything to do with what Apple is doing. If you reboot the router and it starts issuing addresses from the beginning of its range, it is likely to issue addresses that conflict with the existing leases on the non-Apple computers.

If a DHCP server gives out an address, and then gives it out again before the least has expired or the first client has relinquished it, it is going to cause a conflict no matter who made the clients.


Before assigning an address to a client, a DHCP server will ping the address first to make certain someone isn't already using it (this behavior is even documented in the manual page of ISC dhcpd); therefore, it is only clients that join the network and assume their old lease is still valid (sniping it from one of the new clients that accidentally ended up with the IP address that used to be leased) that will cause this behavior.


If you're having to reboot the router more often than DHCP leases expire, you may want to look into a new router.


Ah yes, the Apple solution: just buy a new one. Because that's always an option for everyone, on every network they use.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: