Live data from Hacker News

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

cafbit.com

171–180 of 191 posts

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

#171
post #135
post #103

Earlier quoted context omitted.

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

Well, no, that's a bit inaccurate as well, if we want to have nice analogies, let's go with something like this:

You pay for a cup of coffee at a coffee shop. Nominally you get your own cup, and there isn't a limit on the amount of time you can keep it. However, the store occasionally and unpredictably runs out of cups. Also, at the start of a new day a new barista might occasionally come in, and they might not know which cups should still be considered owned. Because of this, everyone else has for years observed a simple procedure where you look to make sure it's your coffee you're about to sip. It's polite and it's just — what's the phrase — not a big deal. You get your coffee, leave for two days, come back and take a drink from the cup that looks like the one you got previously without as much as a glance inside or around.

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

#172
Yes, someone may have joined the network at your old IP address but that's ok. That first ARP is going to determine if that has happened already.

Am I right?

The author should try the same ethernet sniffing experiment but put a machine at the old address and see how the algorithm adapts.

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

#173
Are there any examples of corporate networks that would reject this approach? I worked on a project in a Wi-Fi environment in a warehouse and the network admins of the company pored over sniffer logs in great detail. Excessive ARP probes and non-standard DHCP behavior was especially frowned upon. I'm pretty sure the early ARP requests would have caught their attention.

It gets really problematic if you have several APs servicing one network. What to do if the client roams from one AP to another AP with the same ESSID? Assume it's the same network, in which case you can keep your IP or do you have to redo your ARP or the whole DHCP thing? In our case the client wanted to suppress everything including the ARP but in a general case that's probably not good, especially if the network is called 'linksys'.

Might be interesting to try with a Mac.

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

#174
post #77

Earlier quoted context omitted.

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…

Well, sure, but the problem is that the Apple device user doesn't suffer from the negative consequences of the non-standard action. Other users do. Of course people are going to like devices that allow them to cut in line if there is a little bit of space.

Non-standard action? It's standardized by RFC 4436!

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

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

And as several people have pointed out to me, it looks like there is indeed an RFC for it: RFC 4436, Detecting Network Attachment in IPv4 (DNAv4).

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

#176
post #136

Earlier quoted context omitted.

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.

I'm a dick for buying products that work best for me and not other users or developers? Ok... I thought the Hacker News community was supposed to have a modicum of maturity?

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

#177

Earlier quoted context omitted.

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

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

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

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

#178
post #171
post #135

Earlier quoted context omitted.

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

Well, no, that's a bit inaccurate as well, if we want to have nice analogies, let's go with something like this: You pay for a cup of coffee at a coffee shop. Nominally you get your own cup, and there isn't a limit on the amount of time you can keep it. However, the store occasionally and unpredictably runs out of cups. Also, at the start of a new day a new barista might occasionally come in, and they might not know…

Except I drink hundreds and hundreds of cups of coffee a day. When it takes 10 seconds every time to determine who's coffee it is, we need to come up with a new solution.

Yeah this analogy blows as well. What it comes down to is old world technology spends a ton of time on error correction like this and it's an easy place to increase efficiency & speed for portable devices. It's going to keep happening, get used to it.

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

#179
post #171

Earlier quoted context omitted.

Well, no, that's a bit inaccurate as well, if we want to have nice analogies, let's go with something like this: You pay for a cup of coffee at a coffee shop. Nominally you get your own cup, and there isn't a limit on the amount of time you can keep it. However, the store occasionally and unpredictably runs out of cups. Also, at the start of a new day a new barista might occasionally come in, and they might not know…

Except I drink hundreds and hundreds of cups of coffee a day. When it takes 10 seconds every time to determine who's coffee it is, we need to come up with a new solution. Yeah this analogy blows as well. What it comes down to is old world technology spends a ton of time on error correction like this and it's an easy place to increase efficiency & speed for portable devices. It's going to keep happening, get used to i…

Except it doesn't take 10 seconds. The time between the Galaxy Tab's proper DHCP discover and DHCP ACK was 0.653 seconds. You might notice a difference between that and the Mac's 0.031 seconds to DHCP-free link up if you blink fast.

This conversation makes me want to block Apple devices from any and all devices I control. Because hey, such anti-social network behaviour is going to keep happening. Because it's not a big deal. Because you're worth it. Good thing the network layer doesn't support such, uh, experience-enhacing features.

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

#180

Earlier quoted context omitted.

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…

> Like I said, if you're uncomfortable with the trade-off, avoid Apple devices. Something tells me Saurik is a tad more invested at this point, it's not really as simple as "avoiding Apple devices" when you are the dev of Cydia.

I know next to nothing about iOS as it relates to Darwin, but if the DHCP stack is part of Darwin, it'll be OSS, which means someone could patch the DHCP client to not exhibit this behavior.

How many people do you think would install that patch?

* Resolves potential IP conflicts when recovering from sleep

* Adds 10s to network availability in most situations

Post reply on HN