Live data from Hacker News

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

cafbit.com

151–160 of 191 posts

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

#151
post #4

There already exists a minimal DHCP client implementation in the Linux kernel, but it lacks certain features such as configuring the DNS nameservers. I wonder if it is possible to use the kernel-level DHCP client to instantly request the IP address while asynchronously initiating the more functional user-mode dhclient? Once dhclient is up, and the kernel DHCP client has obtained an IP address it could just pass that…

The whole kernel discussion seems to be a red herring. The reason the android device was so slow is because the DHCP server timed out twice on a DHCP request. Those two timeouts caused 10s of the 11s delay. I think there probably was something wrong with the DHCP server configuration.

It timed out because it wasn't there, not because it was misconfigured. The tablet was revalidating its previous lease, which was from a different network - so it was sending the request to the previously-known server address.

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

#152
post #66

Earlier quoted context omitted.

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.

Ah, after a closer look at the original article, I see that now. Curious that Apple would choose to unicast those requests.

It does this to verify that the DHCP server has the same MAC address as the one that it remembers. If the server that it remembers isn't present on the current network, the unicast packet should be ignored.

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

#153
post #32

Earlier quoted context omitted.

The lower level networking protocols do rely on some levels of peer trust, but carefully controlling that trust has come a long way in the last decade. If I'm correct in assuming by "actual security" you mean "physical security" you're making some pretty broad and faulty statements (even about layer 1). There are many networking devices and techniques for hardening hostile networks at layer 2. Layer 3 is IP; to say l…

Sorry, I double-posted accidentally and it looks like I deleted the wrong one. I meant that layers 1-4 should not be relied upon to provide your application security. You are right that there are cool advances that can be worthwhile to slow down attackers, but I think that in most circumstances, you will want to make your guarantees higher up the stack* *I am not a security expert

[deleted]

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

#154
post #32

Earlier quoted context omitted.

The lower level networking protocols do rely on some levels of peer trust, but carefully controlling that trust has come a long way in the last decade. If I'm correct in assuming by "actual security" you mean "physical security" you're making some pretty broad and faulty statements (even about layer 1). There are many networking devices and techniques for hardening hostile networks at layer 2. Layer 3 is IP; to say l…

Sorry, I double-posted accidentally and it looks like I deleted the wrong one. I meant that layers 1-4 should not be relied upon to provide your application security. You are right that there are cool advances that can be worthwhile to slow down attackers, but I think that in most circumstances, you will want to make your guarantees higher up the stack* *I am not a security expert

Kerberos is an attempt to push security guarantees below the application layer - applications are supposed to be able to rely on it for their security.

It has been somewhat less than wildly successful.

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

#155
post #59

The mac implementation is good for 99% of the times, since it is really fast, but the 1% of the times that it steals an ip adress it is really a pain in the ass. I don't mind to wait a few seconds to get a connection in the stardard way.

...but the 1% of the times that it steals an ip adress... Could someone explain how we're imagining this might happen? If my Dell Precision laptop is using the contended IP Address, then why didn't its interface's mac address get returned by the ARP who-has request for that IP?

The problem may well be that specific ARP request - the one at 0.0180 in the original article. It appears to have a non-zero sender IP address, which means it doesn't conform to a classic ARP probe. The Dell Precision laptop, upon seeing an ARP request appearing to come from itself, might well decide that an address conflict is occuring.

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

#156
post #151

Earlier quoted context omitted.

The whole kernel discussion seems to be a red herring. The reason the android device was so slow is because the DHCP server timed out twice on a DHCP request. Those two timeouts caused 10s of the 11s delay. I think there probably was something wrong with the DHCP server configuration.

It timed out because it wasn't there, not because it was misconfigured. The tablet was revalidating its previous lease, which was from a different network - so it was sending the request to the previously-known server address.

I am pretty sure that request is supposed to be broadcast across the entire subnet.

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

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

Both Mac and Windows perform gratuitous iparp before configuring an IP address to ensure no one else is using that IP. This is common really and not that big of a deal.

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

#158
post #5

Earlier quoted context omitted.

ChromeOS is based on linux, so I'd expect something similar to what Android does: userland dhclient with the same performance profile as the tablet he tested.

"Chrome OS" is Gentoo, not Android. One of my friends has a Cr47 and some hacking exposed dhcpcd inside, with some unspecified patching to bring it down to sub-second DHCP.

The patching is definitely specified (Chromium OS is partially open source after all):

http://git.chromium.org/gitweb/?p=chromiumos/third_party/dhc...

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

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

[deleted]

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

#160

Earlier quoted context omitted.

"Chrome OS" is Gentoo, not Android. One of my friends has a Cr47 and some hacking exposed dhcpcd inside, with some unspecified patching to bring it down to sub-second DHCP.

I believe that Android also uses dhcpcd, if I recall correctly from recently browsing the source code. I do not know whether or how Android's dhcpcd may be modified.

Hard to say: http://android.git.kernel.org/?p=platform/external/dhcpcd.gi...
Post reply on HN