Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

cafbit.com

Post reply on HN
Print view View original

61–70 of 191 posts

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

#61

Post by Terretta »

saurik wrote: post #20
kelnos wrote: post #18

Earlier quoted context omitted.

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 ev…

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 envir…

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

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

#62

Post by bradleyland »

kenjackson wrote: post #8

This implementation by the Mac feels wrong. I mean it appears to work, but it seems like a violation of the protocol and can result in problems on the network. Maybe security issues (?). I'm not an expert in any of these things, but I'd love to hear a network protocol/security experts take on this.

It's not a violation of the DHCP protocol, because the requests being made aren't specifically DHCP requests. It might be a violation of network policy though, but that depends on your perspective, not an RFC.

Think of it like this. Your iOS device assumes that if it's on the same network, and it has a valid/current DHCP lease, it will use that address while it goes about the business of negotiating a proper DHCP address. The assumption is made outside the scope of negotiating an actual DHCP address.

A violation of the protocol would involve tricking the DHCP server or sending false information to the DHCP server. Neither happens here.

It's up to the network owner to decide whether or not this is acceptable. With a properly functioning network equipment, you should never encounter a failure of this assumption. If you have an unhealthy network, the assumption may fail more frequently, but then again, you're just compounding an existing issue that should probably be resolved.

In the end, we're talking about saving 10s every time you wake your device up. Ten seconds. That's significant. I use my iPad/iPhone very casually. I don't think about "grouping" my usage, because it works instantly when I pick it up. My network works properly, so I'm happy it's making these assumptions.

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

#63

Post by bradleyland »

knowtheory wrote: post #7
hardtke wrote: post #2

I've sat in many a meeting where the Macs "steal" all of the DHCP connections and I'm stuck watching the speaker instead of following TweetDeck.

I've had my wife's macbook bump mine off the network by stealing the IP my machine is using. Definitely an inconvenience when on skype.

The only time this should happen is if your router has been rebooted. Otherwise, the Mac is only reusing what should be a valid DHCP lease. If your router is handing out that same IP within the term of the lease expiration, you have bigger problems. If your router is restarted frequently, you should look in to a firmware update to increase the stability.

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

#65

Post by pieter »

Another nice trick of OS X is its use of IPv6, also for its multicast DNS (Bonjour) networking. This means you can have a bonjour session up and running long before you have an IPv4 address, especially in the absence of a DHCP server. It's what allows plugging a network cable between two macs and immediately start using NFS.

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

#66

Post by cbs »

tomlogic wrote: post #47
cbs wrote: post #31

Earlier quoted context omitted.

This certainly smells fishy, the client is relying on ARP to assume its OK to reclaim that IP address before it actually gets the authoritative answer from the DHCP server. IP networking does not require that computers submit to dhcp, so depending on how you look at it, it probably doesn't run afoul of the spec. I'd have to get a more detailed packet capture and reference some RFCs, but given DHCP isn't manditory, I…

Regarding your security statement, I didn't get that from the packet capture. The Mac is sending an ARP request for the IP addresses of the DHCP servers of networks it's been on recently. An attacker would need to know the correct MAC address to respond with -- the Mac is not sending that out in the request. If the ARP comes back with the cached MAC address for that network, the Mac continues using the valid DHCP lea…

the Mac is not sending that out in the request.

I could be wrong about this, as I haven't analyzed actual arp requests in ages, but from the article it appears the arp requests are unicast to the (at least in the example) cached MAC for the gateway.

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

#67

Post by calloc »

dhess wrote: post #49

When coming out of sleep, my Macs often get a new computer name in the form of a " (N)" suffix; e.g., a Mac named "vision" will come out of sleep and mysteriously change its name (as reported in System Preferences->Sharing) to "vision (2)", then "vision (3)" after a subsequent sleep, etc. It's annoying. I wonder if this rapid DHCP implementation has anything to do with that.

DHCP allows the computer to send a computer name to the DHCP server, the server can then dynamically set DNS entries based on the computer name.

DHCP is also allowed to send back a new hostname (the reason why on Mac's sometimes depending on the network you are connected to a different hostname is shown on the command line). What is most likely happening here is that your DHCP server is sending you a new hostname because it is not letting your Mac use its old lease for one reason or another.

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

#68

Post by thought_alarm »

One of my favorite features from way back involved running a local X Server and a number of remote X clients tunneling over ssh. I close the lid, pick up the laptop and go for lunch. Come back and open the lid and wifi is reconnected immediately and the remote X clients and SSH shells are still alive and active.

And that was 6 years ago on a PPC iBook.

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

#69

Post by bradleyland »

secure wrote: post #56

So, as far as I understand, the issue pointed out here is that the Mac is sending ARP requests with a cached source IP address (which therefore could be already in use). I wonder why it does that, as you can also send ARP probes originating from a source IP address 0.0.0.0 (and only having the MAC address set). I just tried it on linux: arping -D -c 1 -I wlan0 172.22.36.1 The computer with 172.22.36.1 will happily se…

There are three phases here:

1st phase is networking discovery. During this phase, the Mac is sending ARP who-has requests, which are "anyone out there" requests, not, "hey, I'm using this" requests.

2nd phase is the assumption. If the DHCP client in iOS is able to verify the Ethernet and IP address of the DHCP server match it's suspected network profile, and it has a valid DHCP lease record for that network, it assigns that IP to the interface and begins using it, at which point any potential ARP poisoning would occur.

3rd phase is DHCP negotiation. The first actual DHCP request goes out at 00.0140s, which is after the initial ARP network profiling, but before the interface actually comes up, so these actions could be considered asynchronous. Once the DHCP negotiation completes, any incorrect assumptions are abandoned and the DHCP issued IP would be used.

There appears to be a window of 1.0s where the device is using an assumed IP address. During this time, traffic transmitted on the network would "poison" the ARP cache, but IP conflicts are not an end of the world scenario in networking terms. Once the proper DHCP resolution occurs, the ARP table would be updated and the conflict resolved.

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

#70

Post by saurik »

bradleyland wrote: post #58
saurik wrote: post #15

> 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…

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 wher…

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).
Post reply on HN