←back to thread

Rapid DHCP: Or, how do Macs get on the network so fast?

(cafbit.com)
354 points timdoug | 7 comments | 12 Jul 11 17:04 UTC | HN request time: 0s | source | bottom
Show context
saurik ◴[12 Jul 11 17:52 UTC] 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 #
bradleyland ◴[12 Jul 11 20:15 UTC] No.2756333[source]▶
The DHCP stack in iOS does some profiling that should reliably detect whether it is, in fact, on the network that it expects. The most significant of which is the verification of the DHCP server's Ethernet address as correlated to IP.

If you are on a known network, your DHCP lease is still active, and network equipment is working as expected, all of these assumptions are safe. The most common failure scenario is where the DHCP server has lost its DHCP lease table. For many consumer routers, this will occur when the router is rebooted. If you have to reboot your router frequently, you should replace it. Even if you do encounter a failure mode, the error will clear a second or two later when a new address is negotiated via DHCP and the subsequent ARP update.

This is very clearly a trade-off. Devices like the iPhone and iPad are switched on and off very frequently. The difference between 10s to network ready and 0.3s to network ready is more than significant; it's monumental. This is especially true for devices whose use-pattern will involve frequent on-off usage.

If you're uncomfortable with this trade off, you should stay away from Apple devices. Personally, I'll take the 10s.

replies(2): >>2756511 #>>2756642 #
saurik ◴[12 Jul 11 20:52 UTC] No.2756511[source]▶
Down-thread of this comment, people have already discussed numerous issues with the assumption that DHCP leases are stable when not in use (such as that servers often choose to allocate out of an artificially small pool of addresses, and ping old addresses to determine if they are in use before simply reclaiming and reassigning them).
replies(2): >>2756557 #>>2757434 #
bradleyland ◴[12 Jul 11 21:01 UTC] No.2756557[source]▶
Like I said, if you're uncomfortable with the trade-off, avoid Apple devices. Personally, I only see the number of devices like the iPad/iPhone increasing, and I'm relatively confident that your normal user doesn't give a damn about any of this. They want the device to work when they turn it on.

I'd also argue that any DHCP server that applies that policy of artificially limiting the IP pool by re-issuing non-expired leases is an asinine implementation.

replies(3): >>2756653 #>>2756675 #>>2756909 #
1. pyre ◴[12 Jul 11 21:23 UTC] No.2756653[source]▶

  > They want the device to work when they turn it on.
If there is a collision, then this doesn't 'just work' when the user turns it on. Just sayin'. From the user's perspective the device should never fail, in any situation, for any reason... ever. Users don't care about trade-offs because they don't want to trade anything off, they want it all, 5 minutes ago.
replies(2): >>2756800 #>>2756920 #
2. Locke1689 ◴[12 Jul 11 21:59 UTC] No.2756800[source]▶
This implementation will always work for the Apple device that's connecting.
3. shinratdr ◴[12 Jul 11 22:30 UTC] No.2756920[source]▶
> If there is a collision, then this doesn't 'just work' when the user turns it on.

No, it just potentially kicks off another user. I've never been unable to acquire an IP because of this practice, I've just seen other people's wireless mysteriously give up the ghost when I connect with my iPhone or Mac. I would prefer to have the aggressive device, personally.

replies(2): >>2758372 #>>2758849 #
4. derleth ◴[13 Jul 11 09:31 UTC] No.2758372[source]▶
> I would prefer to have the aggressive device, personally.

So, by basic game theory, everyone implements 'asshole mode' in their devices. What happens on a technical level when every device behaves like that?

replies(2): >>2758601 #>>2760266 #
5. nicolasp ◴[13 Jul 11 11:36 UTC] No.2758601{3}[source]▶
Router vendors start saving DHCP lease tables to stable storage and the issue is fixed?
6. bradleyland ◴[13 Jul 11 13:21 UTC] No.2758849[source]▶
You're falsely attributing this behavior to your iPhone/Mac. Keep a couple of things in mind:

* If you have a valid lease, there should be no conflicting IP addresses on the network

* Even if you do have a conflicting IP address, that conflict only exists until the DHCP server issues you a new one (iOS immediately performs the DHCP request after sniffing)

IP conflicts are not voodoo magic. Once the conflicting machine gets a new IP address, everything returns to normal. The network events shown in the article show that this occurs in about 1s; between the time that the interface comes up, 0.3s, and the time the interface is active, 1.3s. If this were a full negotiation, it would take around 5s.

The key thing to remember is that this shouldn't happen at all on healthy networks. So, if anyone chooses to remain opposed to this, they're saying that waiting 10s every time you wake a portable device from sleep and want to use the network connection is a worthwhile tradeoff to accommodate DHCP servers that don't respect leases and switches that can't adequately resolve an ARP entry conflict in a timely manner.

I've said it about ten times in this discussion already, but I'll keep the ten seconds (times 15-20 sleep/wake events per day) and buy decent network equipment.

7. shinratdr ◴[13 Jul 11 19:31 UTC] No.2760266{3}[source]▶
> What happens on a technical level when every device behaves like that?

We start putting battery backup in routers so they won't drop their DHCP tables? This isn't asshole mode, it's "assume the network is functioning properly and hasn't been reset" mode. In the world of portable devices, it's important to look at where we waste time and compensating for errors is a frequent culprit.