←back to thread

354 points timdoug | 10 comments | | HN request time: 1.03s | source | bottom
Show context
saurik ◴[] No.2755677[source]
> This network recognition technique allows the Mac to very rapidly discover if it is connected to a known network. If the network is recognized (and presumably if the Mac knows that the DHCP lease is still active), it immediately and presumptuously configures its IP interface with the address it knows is good for this network.

Ok, seriously? That isn't a bug in an implementation somewhere, but in fact a feature that Apple actually is proud of? Am I the only one who finds that if you get a room full of people sitting around with Macs at least one person gets their IP address stolen by someone else?

(edit: I just got downvoted, and then asked the people in the room with me, and they seemed to agree with my perceived correlation regarding the "another computer is using 192.1.0.1" issue... instead of just downvoting, maybe reply? It is actually quite common that DHCP leases on a network get reset for various reasons, and if you just jump on the network without revalidating your lease, you are actually quite likely to just "presumptuously" steal someone else's IP address.)

replies(11): >>2755698 #>>2755761 #>>2755851 #>>2756177 #>>2756303 #>>2756333 #>>2756755 #>>2757385 #>>2758088 #>>2758576 #>>2758677 #
kelnos ◴[] No.2755698[source]
Why would that be the case? Assuming it only does this if it knows its previous DHCP lease hasn't run out, it's very likely (unless the DHCP server has been rebooted or has otherwise lost its lease table) that no other device is using that IP.

And even if it screws this up, it looks like it does a proper DHCP request about a second after the interface comes up, so the problem will be fixed quickly.

Do you have any evidence that Macs in practice tend to inadvertently boot people off the network when they join?

replies(1): >>2755728 #
1. saurik ◴[] No.2755728[source]
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.)

replies(4): >>2756052 #>>2756322 #>>2756356 #>>2757534 #
2. Locke1689 ◴[] No.2756052[source]
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.

3. kelnos ◴[] No.2756322[source]
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.

replies(2): >>2756952 #>>2757021 #
4. Terretta ◴[] No.2756356[source]
If you're having to reboot the router more often than DHCP leases expire, you may want to look into a new router.
replies(1): >>2756713 #
5. jarek ◴[] No.2756713[source]
Ah yes, the Apple solution: just buy a new one. Because that's always an option for everyone, on every network they use.
6. to3m ◴[] No.2756952[source]
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.

7. nitrogen ◴[] No.2757021[source]
...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.

replies(1): >>2757158 #
8. Steko ◴[] No.2757158{3}[source]
http://www.net.princeton.edu/apple-ios/ios41-allows-lease-to...

http://www.net.princeton.edu/apple-ios/ios41-allows-lease-to...

9. tzs ◴[] No.2757534[source]
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.

replies(1): >>2757574 #
10. saurik ◴[] No.2757574[source]
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.