This is an article from 2011, 6 years ago. Has there been any progress on implementing RFC 4436 on Linux in general or Android specifically in the interim?
ChromeOS is not a real OS. It's an embedded appliance/cloud OS as a gateway to the web and Google services. Anyone can make a machine boot fast if it has nothing to load.
Just because it's not bloated doesn't make it any less of an OS then any other minimal Linux installation, it is itself built on the Linux kernel - it is just highly optimised for a very select set of software and hardware requirements.
It's gentoo based. Just because its DE is basically just chrome doesn't make it any less of an OS. Hell, you can even run another OS in a chroot on it.
You'll get similar performance if you put your OS on an SSD, and select services that minimize your boot time.
Can I join it to my AD infrastructure? Can I access network shares (NFS/SMB) ? I could list off a million "Can I...?" questions but the fact remains that it's a Google Chrome appliance. The detail that hidden underneath is a Linux/Gentoo base is irrelevant. This is no different than your PS4 which runs Orbis, a stripped down OS based on FreeBSD. It's not a real OS targeted for users who want a complete OS computing experience. It's an appliance with a single purpose built upon parts of an existing OS.
My NetworkManager still takes multiple seconds to connect to wifi, and that's definitely the same pathetic DHCP behavior. wpa_supplicant is super fast. Modern Ubuntu (17.04) is still stuck in this ancient, lethargic world.
TL;DR: ChromeOS uses this rfc, Android, dhcpcd, isc-dhcp-client doesn't
(Note: I have no clue about systemd-networkd)
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.
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.
Interesting nugget of information here:
> Thanks to Steinar H. Gunderson for pointing out in the comments that the DHCP server on my test network was incorrectly configured. Since I was using a mostly "out of the box" dhcpd configuration from Ubunbtu Linux, it wasn't set up to be authoritative by default, so it wasn't promptly sending NAKs in response to the Galaxy Tab's requests for an old IP address. After fixing the problem on the DHCP server, the Galaxy Tab's DHCP handshake happens quite a bit faster (although still 85 times slower than the Mac).
Set authoritative on your dhcpd.conf! I checked, fortunately mine is set :)
> An instruction like that is why I don't use Linux as a desktop!
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.
> The mac circumvented the issue because it sends out information of all previous networks ... I'd rather not want my laptop to push out all of my recent networks' information to anybody
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.
> An instruction like that is why I don't use Linux as a desktop!
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.
I'm a bit disappointed that you're downvoted to grey right now because editing obscure config files and entering esoteric terminal commands is exactly why Linux is so difficult for the average user, and it's never going to improve if those who're already comfortable with it ignore the problem.
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!
Well if you're an average user, I might suggest not running your own DHCP server?
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.
In this specific case, the DHCP server configuration under Windows makes it abundantly clear though that you need to make your DHCP server authoritative by adding a warning icon and presenting a warning dialog when it's not running in authoritative mode.
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;
It doesn't however explain to you why you should or shouldn't do that and, again, it starts up just fine without this uncommented.
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.
And dump truck gearing patterns are kind of similar to manual transmission car patterns. Complaints about the difficulty of driving a dump truck remains irrelevant to cars.
"Kind of similar" is very different from "arranged by the same people following the same processes with many packages being identical". We're talking about comparing transmissions from the same manufacturers with a lot of shared parts.
From when and which distro is that default config file? I remember having a text next to it saying 'Enable this, if this is the only DHCP server on this network' or something along the lines of that with a pointer to the documentation for an explanation.
It would still be an easier to navigate GUI tool, possibly with tooltips and online help along the way, than manually editing /etc or /usr/share files.
People say things like this, but if you're not familiar with it the Windows networking GUI configuration is still quite a mess. Especially since Win8 there are now two different GUIs for it, with different feature sets.
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.
In practice, it is still easier to grep and edit config files in /etc (often commented), than to look for the needle in a haystack like gpedit, where, if localized, you don't even know exact term you are looking for.
Not really a fair comparison. For editing config files I often have to go to man pages to find out what the syntax is for the things I want (and sometimes, where to find the file). Especially if editing bash/zsh.rc, there is no hope of getting anything done without Google unless you already know how to do it.
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.
> here is no hope of getting anything done without Google
> 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.
You should try disabling mouse acceleration using your mouse, that's even better. Setting server stuff is one thing, but it's ridiculous that using a mouse is not considered important enough for simple users to be able to customize.
This is nice, but kind of useless when waking up from deeper sleep states, which prevent the password dialog from receiving keystrokes for a good five seconds anyway (despite teasing a blinking cursor).
That blinking cursor is especially sneaky. When they just loaded up what is effectively a screenshot while everything loaded, that could've been forgiven (better than a blank screen I suppose). But animating it so that it LOOKS like it's working ...
I remember this feature used to cause a lot of problems with random IP conflicts, but I haven't had an IP conflict like that in years, so it seems they've made it a lot more robust. Or are routers/DHCP servers just less broken these days (I guess since Apple's market share has forced them to)?
I think Apple "updated" the network stack with 10.10 (maybe 10.10.1) and then had so many issues with IP conflicts with the new implementation that they actually backtracked and reverted to the original. The memory is hazy but if you're interested I can do a little digging and see if I can find some other info.
It still happens. I run Ubuntu on a MBP (dual boot) and some networks are fucking great. No problems whatsoever. Others I get booted off more frequently the more people enter the cafe. I dug into the problem a while back and figured out it was this shitty behaviour by Apple that Ubuntu hadn't fixed.
The joke is, Macbooks are dead slow on WPA2-Enterprise networks once you go with certificate-based logins. At home, I'm in the network often enough faster than 1s - at work, up to two minutes sometimes.
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...
If you’re seeing 2 minute connection times that’s on your network - probably the RADIUS server, not macOS. There are tons of places using macs with WPA2 and certs that don’t have any connection lag - including my employer and many of my customers.
Except that this isn't ignoring red lights, it's taking a government approved shortcut that no-one else has done the research to know about (to extend your metaphor). This approach is standards approved:
That is indeed what happened. Unfortunately, HN has become so fucking dour, and mindless downvoting is quickly replacing interesting discourse. This is no longer a place for some occasional lighthearted discourse.
I'm more worried about the network problems i have with my mac, it disconnects sometimes out of the blue, if i reconnect or enable/disable vpn it works again, very weird behaviour.
> I assume the Mac would know to begin the DHCP discovery phase, instead of sending blind requests for a former IP address...
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.
It sounds more like your hotspot is janky - if a Mac doesn’t get a DHCP response it will still connect to the wifi network using and autoconf address. There is no dhcp related scenario that causes it to not connect to the network at all.
Interestingly, we use Cisco's Meraki APs at work. The WiFi is pretty solid most of the time, but macs are the only machines that suffer occasional dropouts and then DHCP stops working till you cycle the n/w adapter. (though iphones never seem to have this issue).
It depends on the router too. My arch Linux connects almost instantly to my Ubiquiti WiFi AP on wake from sleep, but takes seconds to connect to my phone AP.
Let’s be clear: this is an issue with your home network. If it’s not able to cope with a known and documented by RFC scheme for detecting network reattachment, then it’s broken.
Unfortunately, most domestic networking equipment is in my experience awful.
If it's "router reboot time" something is seriously messed up with your network.
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.
Really, if your router's uptime isn't measured in months, you're doing it wrong. Probably by running the software it came with, instead of replacing it with an actually-maintained Linux distribution like OpenWRT or LEDE.
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.
I'd suggest that it warrants more investigation than just writing it off as Apple trashes networks. Hybrid Apple/Windows households have been common for the larger part of 2 decades now and certainly others do not experience the same issues guaranteed.
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.
Odds are high that GP's router is configured to give out addresses sequentially, with a fairly short lease and the wireless ap is configured to disallow communication between wireless hosts.
I'm thinking the odds they'll change the configuration vs yell about apple devices aren't so high.
It's not just his iPhone. It's iPads, any Apple device that has been "away" for a while and then comes back.
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.
Well, while this may be the case, I'm not quite sure how Apple device assuming same IP as before somehow triggers the disconnect from the rest. It may be part of the steps required to reproduce, but hundreds of other consumer routers with standard configuration handle such a scenario without booting the rest of the attached clients, which is why I woudl rephrase it as unexpected behavior from the router.
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.
This is very interesting! I just replied to another commentator mentioning issues apple had with 10.10.1 - 10.10.4 when they updated some aspect of the network stack. both the macOS and iOS issues were apparently caused by the same change. More info here: https://www.macrumors.com/2015/05/26/apple-discoveryd-replac...
If you have a linux device on the network you could have that be the dhcp server and control lease times there, dhcp and dns on a linux machine(even an old laptop) are way better than all but the top tier netgear routers. If your windows machine is always on you could even run it in a vm.
My SO unfortunately has 2 ipones, an ipad and a MBP. There is a confluence of DHCP activity from all these devices that is guaranteed to take my network down.
Unless your DHCP server is an old Commodore 64, that's not the right diagnosis. The ISC DHCP server was rock solid with negligible CPU load with many thousands of clients even 10-15 years ago.
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.
That's a bug in that software stack which is unique to however they've designed it. The right thing to do is fix it or replace it rather than blaming the vendor you notice problems with, just as you wouldn't blame a pothole on the first car to hit it.
Our home network has 6+ Apple devices and a pile of other stuff (Smart TVs, DVRs, game consoles, media converters, etc) and it has zero problems whatsoever. Our router is some generic thing by NEC that I bought off the shelf at a big-box retailer because it had the biggest numbers on the box.
http://www.ietf.org/rfc/rfc4436.txt