Rapid DHCP: Or, how do Macs get on the network so fast? (2011)
cafbit.com
cafbit.com
On chromeOS network bring up is extremely fast. We are talking 1-3 seconds from cold boot to your emails have been synchronized.
My Ubuntu is almost as fast, if we subtract the 4 seconds the ugly bios screen adds.
No idea about Android, but did you read the end of the article?
The mac from 6 years ago does it in 300ms which is still 3-10x faster than what you suggest is the norm for your setup.
The difference between 300ms and 3 seconds is the tipping point for being annoyed when you cannot connect to the first page you visit.
Search "chromebook boot time" on YouTube. Checkout the comparisons between a $200 chromebook from 2013 and a $2000 MBP...
You'll get similar performance if you put your OS on an SSD, and select services that minimize your boot time.
Ok, so the article covers ARP discover, but actually it's not the only issue.
The author mentions a 10s timeout because his DHCP is not authoritative. But in my opinion, that's not the real problem (though I admit it is better if his setup has it). The author's device should not ask for an unrelated IP in the first place. If it doesn't do so, and asks for the correct IP address, you save 1.5 RTT. This is because at the time of that article, dhcpcd had one lease file per interface.
In my opinion, between RFC4436, and per-ssid interface, having a per-ssid lease makes a MUCH bigger user-facing change than RFC4436. RFC4436 worst 1-percent gain is 1s, per-ssid lease worst 1-percent is gain 10s.
I suggested a fix to dhcpcd's author: have one lease file per { interface + ssid }. This has been merged in dhcpcd in February 2015 (sorry, it looks like mailing-list archives is down). So the bad feeling of > 10s connection time should be gone when using dhcpcd.
I've also suggested him to implement rfc4436, but got no answer at the time. Considering the friendly answer I had for my previous patch, I guess it just got lost. As far as I can tell, as of today, mainline dhcpcd still doesn't implement it.
ChromeOS uses a patched dhcpcd, which includes RFC4436: https://chromium-review.googlesource.com/c/22643/ https://chromium-review.googlesource.com/c/23906/
isc-dhcp-client, aka dhclient, doesn't seem to include either the ssid-based lease, or the RFC4436.
Android used to use dhcpcd until Android 6, but a very old version. I published an updated version of dhcpcd for rooted Android: https://forum.xda-developers.com/android/software/wifi-dhcp-...
I pushed to Android's gerrit the changes that were merged to dhcpcd (it had to be rewritten, because Android's dhcpcd is really old).
The result of this, is that for Android 6, Google decided to rewrite their own DHCP implementation (mostly because the integration with dhcpcd made a state machine more complex than rewriting a DHCP client). This led to a java dhcp client which doesn't save leases, had flaws which could make an android device reboot, and which doesn't support RFC4436. At least, there is no longer any authoritative problem, since the device will always send a DISCOVER. As far as I know, this still is the current status of Android.
Android Things, which is basically Android... Well, they are using yet another google-written dhcp client. ( https://android.googlesource.com/platform/system/connectivit... ) This supports leases (I couldn't tell based on the sources whether it was interface or ssid-based), but no RFC4436.
And of course, thanks for all this work, it's quite impressive.
Also, You not working for Google just proves their headhunting and recruitment process is not worth shit
Set authoritative on your dhcpd.conf! I checked, fortunately mine is set :)
But its a dhcp server, network admins would be expected to touch config files, and the interface for a DHCP server really can't be much worse than the GUI version that microsoft supplies!
but digressions, to say "this is why I won't use a linux desktop" in response to a server-specific use-case, is at best antagonistic!
Conversely, most group policies I have ever needed were pointed out, including where to find them, after one web search, and their use is extensively documented in the config editor.
> were pointed out, including where to find them, after one web search,
Well, if you are doing that one web search, it doesn't matter whether the named key is for gui or text config. Except for that localization issue, if you find English string, it won't help you with localized one.
Then there is the issue of the GP items themselves: many times you don't know whether to choose enable or disable, because double negatives FTW.
There are still some configuration items that have to be set in the registry or through Powershell (wmi and so on). The registry is much worse than editing files in /etc/ because you can't back it up, revision control it, or put comments in.
Random googling reveals people having surprisingly similar problems with the Windows DHCP server: https://community.spiceworks.com/topic/332253-cannot-backup-...
As for GNU/Linux, I know it since Slackware 2.0.
Leaving aside the fact that the variation among Windows versions is quite small versus the GNU/Linux distribution fragmentation.
Making it authoritative is then to just press a button in that dialog.
Yes. You have to know that you have to open the GUI for DHCP server configuration in order to configure the DHCP server, but that's really all you need to know to prevent the issue described here.
isc-dhcpd that's often used under linux doesn't even warn to syslog when it's not authoritative. All indication for doing so is given in the sample config file using
# network, the authoritative directive should be uncommented.
#authoritative;
Case in point: Back when I was learning about all of this my Windows-based DHCP servers were all authoritative, whereas none of my Linux or FreeBSD based DHCP servers were.
# If this DHCP server is the official DHCP server for the local
# network, the authoritative directive should be uncommented.
Though for the opening to the current discussion that is a moot point - this is not relevant to either OS on the desktop.
Seriously, I understand where you're coming from, but you're blathering needlessly about an issue that is a) not really a contentious one, and b) completely irrelevant to the discussion.
This has nothing to do with the linux desktop - this is a misconfiguration of the dhcp server, which would affect all clients. The mac circumvented the issue because it sends out information of all previous networks (which is a security issue, btw - I'd rather not want my laptop to push out all of my recent networks' information to anybody).
Also, this guy is running his own ISC dhcpd server to have more control over the network and to learn more about networking in general. This is not a professional network admin/dev - of course he doesn't do all of it right, but if he'd read the manual, he would've enabled it. Seriously, even in default configurations the option is marked as 'if this is the only DHCP server in the network you'll want to enable this' or something along the lines of that.
So we're not speaking about an out-of-the-box ready-to-roll router - we're talking about a guy who's running a server with Ubuntu on it to provide leases to his network.
Besides - the same would've happened if a windows user were to use Microsoft's DHCP server, which is non-authoritative by default as well. It's a good practice that a DHCP server on default configuration doesn't assume to have the authority - since, well, since the configuration has not been touched.
It's some information about the last few _wired_ networks you've connected to, to any of those networks, that the owners of those networks already have. If you have a wifi you already know which network you're on, and there's no sense in asking about addresses you haven't seen with that SSID+key.
There certainly appears to be a privacy issue if you're connecting to a lot of public ethernets and those sites (can) collude, however if those sites can and do work together, they can unmask you anyway.
If they don't yet collude (but are willing) and you don't use random MAC addresses, then there may be another privacy issue where they can use the MAC address you leak to discover each-other, but I'm unconvinced even Google has the resources to do this.
How often do you find yourself needing to run a DHCP daemon on your desktop, Linux or otherwise?
Some might say that Windows' DHCP setup being authoritative by default is one of the reasons they prefer Linux on the server. It is not the safest default: sending NAKs when you shouldn't could cause significant disruption, not sending NAKs when you could correctly do so does nothing worse than delaying new connections by a few seconds.
Done: https://github.com/majewsky/system-configuration/commit/f917... :)
Will see if it helps once I get home.
I guess that modern macbooks keep the connection alive on the PHY level while asleep... they do have that "backup/sync while you sleep" feature, so quite possible that the chip handling this feature only speaks "normal" WPA2, keeps the connection alive and then after resuming the OS only has to re-check the IP address and does not have to do the full PHY handshake first...
Why did you pour coffee on your screen? That's really quite strange behaviour.
I wonder if that is my problem. Often, my Mac won't connect to my mobile hotspot. I open the lid, it starts attempting to connect to the hotspot and just sits. Connecting. Forever. I can turn off WiFi, turn off the hotspot, and sometimes even reboot both my phone and my laptop and still be unable to connect.
I recently figured out that if this not-connecting happens, I can disable wifi, disable hotspot, turn on WiFi and select my not-on hotspot to connect to. A couple of seconds later, it fails and asks to run network diagnostics. I cancel, disable wifi, turn back on the hotspot, turn back on wifi and, presto, it connects.
I figured there was some caching going on and that I am effectively invalidating the cache. Maybe this is what the op is talking about here.
Previously discussed here: https://news.ycombinator.com/item?id=2755461
When my kid comes home with his iPhone there is a better than even chance that my home network will go out to lunch. Router reboot time.
Never happens with Windows or Android devices coming and going.
If that's an exaggeration and the iPhone is just booting other random stuff off the network, have you tried just increasing the DHCP lease time? On a home network that just sees the same devices day in and out you could safely set it to several days long.
So rather, the title would be Apple devices cause issues on your home network. Or more accurately, something on your home network works in an unintended fashion when your son's iPhone connects.
TFA describes how Apple is taking shortcuts in the DHCP negotiation. I blame them for assuming that the previous IP address assigned to the device will still be available.
And Apple isn't taking a shortcut or a hack here, it's a known scheme: http://www.ietf.org/rfc/rfc4436.txt It's not so much doing anything special as crafting a special call to the network it tries to connect to. It's more of a shortcut to know if the Mac should go to the DHCP phase rather than cheating its way on to the network.
It used to have an open root exploit (patched), but it never had an Apple problem. :-)
There are really very few routers out there anymore that have so little memory they can't be robust and run modern software. Flaky hardware is quite a bit more rare than some users seem to think. The problem is mostly that the hardware vendors have very little incentive to continue polishing the software after the device is shipping, because by the time you get fed up with the consequences of their crap software there will be a new model to sell you. They love that "buy a new router" is such a common troubleshooting step.
https://askubuntu.com/questions/248355/can-i-run-a-dhcp-serv...
Hope that helps. You'll still be behind the NAT of the netgear router but you'll have better control over QoS.
Here's how you can do it on a debian box
A DHCP negotiation to get an IP address takes 4 UDP packets, all of them usually below 500 bytes in size.
Not even when you have set the lease time to the theoretical minimum of 1s, this traffic will be at all significant in your network.
If your network is really having problems, either dig deeper if you want to learn more about networking or buy something like a Google WiFi device if you just want something known to handle much greater loads without issue.
Unfortunately, most domestic networking equipment is in my experience awful.