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

131–140 of 191 posts

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

#131

Post by tzs »

deskamess wrote: post #96
jarek wrote: post #85

Earlier quoted context omitted.

So here's my understanding of the situation: when a DHCP server runs out of leases to assign, it will kill the oldest (in terms of use) lease. If the device that held the lease is not on, for relevant values of "on", at the time, it will not be notified about this. The usual (perhaps standard, I'm not sure) process has the device confirming its DHCP lease when coming back on, and in this situation the device would be…

I think your description is correct. The problem is the impact of the false "ip conflict" that is caused by this optimization. A device that detects an ip conflict should not have to guess whether it is an ip conflict caused by an optimization on another device. As pointed out in other comments an ip conflict can cause other systems to drop existing connections. No one likes ip conflict notifications, or to have thei…

This optimization does not cause IP address conflicts. If a DHCP server is not correctly keeping track of lease times and ensuring that addresses already assigned are not reused while the client still has a valid lease, you can get IP conflicts regardless of whether or not their are any Apple devices on the network.

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

#132

Post by tzs »

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…

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.

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

#133

Post by saurik »

tzs wrote: post #132
saurik wrote: post #20

Earlier quoted context omitted.

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…

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

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.

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

#134

Post by krakensden »

vacri wrote: post #126
flogic wrote: post #79

Rather than asking why the mac is so fast, the correct question is "why the hell is dhcpcd so slow?". There's a full second before it does anything.

I think it's apples and oranges to some degree - a macbook pro with a venerable operating system versus a tablet with one that's still heavily in development. Better to compare galaxy vs ipad tablets, or osx vs other unix vs windows

The tablet is using dhcpcd, which is plenty venerable.

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

#135

Post by tzs »

jarek wrote: post #103
shinratdr wrote: post #92

Earlier quoted context omitted.

The only reason that is a useful example to you is because that act is genuinely dangerous. There is nothing dangerous about swiping someone's IP and causing them to have to reconnect.

You're right. I guess it's more comparable to walking up to a checkout or a cash register without looking to see if anyone is waiting in line. Great UX if you don't look around you.

That's as bad as your exit lane analogy. If you want a checkout line analogy that actually somewhat fits the situation, here is one.

You pay for a cup of coffee at Starbucks, standing in line until it was your turn to pay. Then you pay and go sat down and drank some of it, while working on your laptop. You get caught up reading HN, and don't take a sip from your coffee for five minutes. You then want to take a sip.

What Apple is doing is like resuming finishing the coffee without going back to the checkout and trying to pay for it again.

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

#136

Post by sid0 »

shinratdr wrote: post #119
sid0 wrote: post #94

Earlier quoted context omitted.

And yet it is exactly as dickish and disrespectful of others. Just like Apple as a whole, it seems.

Meh. Treating developers and the back end gingerly results in no benefit for consumers, in fact by and large it results in in a pretty clear loss. Characterize it however you wish, as a user I'm going to go with the platform that focuses on pleasing me rather than making the lives of other users or developers easier.

I agree with Kant here: when deciding whether an action is right, one should consider what would happen if everyone started doing it.

Also, you're a dick. Congratulations.

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

#137

Post by th0ma5 »

bradleyland wrote: post #129
th0ma5 wrote: post #108

Earlier quoted context omitted.

rfc 2131? seems to say the client can ask for an unlimited lease, but the server can specify a finite one. this article seems to be saying that this thing will use the last one leased no matter how long it's been off the network

The DHCP client acts as expected. The behavior observed by the post author occurs before DHCP negotiation executes. I know this seems like a technicality, but it's the truth. The sniffing and assumed use of an IP address occurs outside the DHCP request/response cycle. It's used ahead of time, and discarded if the DHCP 'request' request is denied. The only people bent about this are people who have any idea what's goi…

hrmmm! good point, i assume too much, and i guess i assumed in the cadence of 802.11 whatever, dhcp comes next because it always does, but it never has to! and apparently not here for a moment. thanks for coming back to post this.

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

#138

Post by dhess »

calloc wrote: post #67
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 bec…

I can't rule that explanation out, but I think it's unlikely in this case: my DHCP server knows the MAC address of all of my machines, uses a static MAC->IP mapping, and doesn't update DNS (which is also static). The IP and hostname (as reported by `hostname`) are always correct; it's just the name as reported in the Sharing preference pane and in Finder from other machines on that network that gets the " (N)" suffix.

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

#139

Post by hristov »

rektide wrote: post #128
tonfa wrote: post #24

Earlier quoted context omitted.

Well, in that case they might not be following the protocol. And in some cases break the connectivity for others...

DHCP (rfc2131) doesn't really talk about IP exhaustion. It's undefined behavior, and there's a bunch of people in here saying that server's have every right to violate DHCP leases, otherwise someone can take over a network by continually claiming all of a Class C by continually making DHCP requests. That argument makes sense, but it goes very strongly against the grain of what I would think a DHCP lease meant, whcih…

Look at parts 3.1, 3.2, 4.4 and Fig. 5 of the DHCP protocol. They describe what a client must do on initialization. For example, section 3.2 describes what a client should do if they have a previously assigned addressed they would like to keep using. It seems to me the behavior here is very precisely defined.

Maybe a networking expert can correct me but it seems to me that those initial ARP requests before the DHCP request are not exactly in accordance with the protocol.

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

#140

Post by hristov »

sedev wrote: post #82
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…

I think that you're wrong because, basically, if that 'steal an IP address' scenario happens, it means that the DHCP server has in some way broken its promises. That _happens_ in production environments, but I'd much rather clients use behavior like this, that assumes that a DHCP server will keep its promises about things like lease length, than assume the worst about the DHCP server. The clients should first assume…

Being a dork and a lawyer, I actually looked up the DHCP protocol. This is the relevant part:

"3.7 When clients should use DHCP

   A client SHOULD use DHCP to reacquire or verify its IP address and
   network parameters whenever the local network parameters may have
   changed; e.g., at system boot time or after a disconnection from the
   local network, as the local network configuration may change without
   the client's or user's knowledge.

   If a client has knowledge of a previous network address and is unable
   to contact a local DHCP server, the client may continue to use the
   previous network address until the lease for that address expires.
   If the lease expires before the client can contact a DHCP server, the
   client must immediately discontinue use of the previous network
   address and may inform local users of the problem."
So no there is no indication in the protocol that the clients should assume that the DHCP server will keep its promises after a disconnection from the network. Furthermore, if you use common sense there is no reason to make this assumption in most real life situations. In a coffee house somebody can always trip over the router's cable, for example.
Post reply on HN