14 ms·
Rapid DHCP: Or, how do Macs get on the network so fast?
- thecombjelly 15y agoInteresting. I have Arch Linux running on a Asus Eee pc and I was always happy that it was connected and ready to go as soon as I woke it up from sleep (including WiFi). I can access the internet within a second of waking it up. I'm using NetworkManager and I wonder if it isn't doing something similar? But then everyone else on Linux is claiming it takes much longer.
- simmons 15y agoHuh, interesting. My Asus EeePC 1000 has the slowest network sign-on of any of my devices, but I'm running Ubuntu 10.04 on it. I wonder of Arch Linux has better Wi-Fi drivers or something. I the author of the original blog post, and I performed a similar protocol analysis on my EeePC. Surprisingly, the DHCP handshaking was actually pretty fast, it just seems to take a long time to establish the link. I should really upgrade the OS one of these days.
- thecombjelly 15y agoI have a EeePC 900A and the driver for wireless is by far the best I've experienced on Linux.
- hardtke 15y agoI've sat in many a meeting where the Macs "steal" all of the DHCP connections and I'm stuck watching the speaker instead of following TweetDeck.
- knowtheory 15y agoI've had my wife's macbook bump mine off the network by stealing the IP my machine is using. Definitely an inconvenience when on skype.
- deleted 15y ago[deleted]
- daniel_solano 15y agoI am not a networking expert, and I haven't looked into this in any greater detail than what was in the article. However, it is possible that the Mac doesn't wait long enough to see if an address is already in use before using it. As such, it may end up essentially being an ARP cache poisoning attack. How this works out in the end may depend on the DHCP server in use. Perhaps the server may discover the broken ARP resolution and invalidate the lease, allowing the Mac to jump in and steal the address while the other device is still trying to figure out what happened.
- riblack3 15y agoOn some access points you can disable client to client traffic as a security precaution. If such traffic was disabled, it would probably break the ARP request to see if someone is currently using the IP. (@ 00.0180 seconds in the original article)
- mseebach 15y agoYeah, it does seem like slightly anti-social behaviour (basically, it's asking for forgiveness rather than permission). At least on your home-network, this seems like it could be fixed by assigning your machines permanent addresses or making the router give out much more long lived DHCP leases.
- bradleyland 15y agoThe only time this should happen is if your router has been rebooted. Otherwise, the Mac is only reusing what should be a valid DHCP lease. If your router is handing out that same IP within the term of the lease expiration, you have bigger problems. If your router is restarted frequently, you should look in to a firmware update to increase the stability.
- bradleyland 15y agoI'd like to understand this better. I don't understand what you mean by "steal DHCP connections." Do you mean they use up all of the available DHCP leases? Have you verified this assertion? I've never observed the behavior you're talking about, and frankly, I suspect that you're just attributing some network failure to a Mac user that just happens to be present.
- jrsmith1279 15y agoI've always wondered why my Mac jumps right on the network, while other devices such as my Xbox 360 take a few seconds before the connection is there. I'd be interested to see how the Google Chrome CR-48 handles DHCP since it seems like it takes a bit of time before getting online and allowing me to log in to it.
- masklinn 15y agoChromeOS 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.
- MostAwesomeDude 15y ago"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.
- daniel_solano 15y agoI 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.
- bugmenot 15y agoHard to say: http://android.git.kernel.org/?p=platform/external/dhcpcd.git;a=shortlog http://android.git.kernel.org/?p=platform/external/dhcpcd.gi...
- bugmenot 15y agoThe patching is definitely specified (Chromium OS is partially open source after all): http://git.chromium.org/gitweb/?p=chromiumos/third_party/dhcpcd.git;a=summary http://git.chromium.org/gitweb/?p=chromiumos/third_party/dhc...
- 15y ago
- dotBen 15y agoThere 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 to the DHClient to make another DHCP request with the same IP but the additional DNS nameservers, etc. The DHCP server would just see this as a re-request for the same IP address from the same MAC address and would just re-ACK. This would save the time it takes to initiate dhclient to then perform the initial IP address check + request. EDIT: in fact, I don't get (from the OP's link) why dhclient couldn't just be forced to accept the IP address passed to it by the kernel DHCP client, and bind it with the nameservers/any other info locally without needing to make another round-trip to the DHCP server.
- hristov 15y agoThe 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.
- caf 15y agoIt 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.
- hristov 15y agoI am pretty sure that request is supposed to be broadcast across the entire subnet.
- kenjackson 15y agoThis implementation by the Mac feels wrong. I mean it appears to work, but it seems like a violation of the protocol and can result in problems on the network. Maybe security issues (?). I'm not an expert in any of these things, but I'd love to hear a network protocol/security experts take on this.
- aaronblohowiak 15y agoNot security. You usually rely upon security for network layers 1-4 as being actual security. Adding additional controls can be useful in slowing down would-be attackers, or "casual" intruders, but they are not "real" security measures.
- cbs 15y agoThe 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 level 3 (or 4) measures are not "real" is throwing HUGE swaths of security out the window.
- aaronblohowiak 15y agoSorry, 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 15y ago[deleted]
- caf 15y ago
- pinko 15y agoThis is a great example of Apple's detail-oriented focus on real-world user experience, and helps explain why people prefer Macs even if they can't always explain why. Lots of little things just work better. You (where "you" == myself and many others, even if not /you/ personally) are left overall with an experience of less frustration.
- tonfa 15y agoWell, in that case they might not be following the protocol. And in some cases break the connectivity for others...
- rektide 15y agoDHCP (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 is that it's a contract for a specific amount of time. If it is indeed a contract for a specific amount of time, the client has every right to claim what they're contractually obliged to. This was my initial assumption, and I believe it's Apple's rather valid assumption. It's not a case of Apple not following the protocol. It's a case of the real world being more complex than the protocol.
- hristov 15y agoLook 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.
- kcbanner 15y ago
- mgkimsal 15y agoInteresting on the perspectives here. My macbook is faster at reconnecting than my linux laptop was, but it's still a few seconds. When I'm opening the lid, I typically still need to wait 2-4 seconds before the network is usable, sometimes it's a bit more. In comparison, it's still faster, but not 'instantaneous' as some people seem to suggest. Neither of my macbooks have been "instant" (but again, certainly faster than other hardware I've owned).
- kelnos 15y agoHuh, interesting. I have my Mac set up to require a password coming out of sleep. 90% of the time, by the time I've typed my password and hit enter, not only am I reconnected to my wifi network, but even Adium has had time to reconnect me to GTalk and finish fetching online contacts. It's amazing. When I'm in Linux I can't do anything with the network for a good 15 seconds after unlocking my screen.
- mgkimsal 15y agoI don't usually have a password requirement, so I have that much longer to notice it. But even when I did have a setup like yours, it doesn't take me that long to type brandy6 and hit enter. I'd still ending noticing a wait.
- kelnos 15y agoHuh, I wonder if there are just differences in the wifi chipsets and/or between the router(s) you and I have used that make the wait longer or shorter. Weird.
- troels 15y agoAnecdotally, my mac is absolutely horrible at connecting to my wifi. I often have to try multiple times and some times I give up, have to walk over to the router and restart it before I can get on. Probably an issue with the router ultimately, but I don't have this problem with other devices.
- wildmXranat 15y agoI was looking for this type of comment and I'm baffled it's a single one. None of my macbooks are that exceptional at re-connecting to wifi spots, especially the 2007 laptop. Coincidentally, I bought a linksys usb wifi adapter that could pull my neighbor's wifi from across the street. Just saying.
- cbs 15y agoAnecdotally, my mac is absolutely horrible at connecting to my wifi. There are certain networks they loathe to connect to and I haven't been able to find a common cause. The 802.1x authentication at college took lots of fiddling around on my mac every time I tried to connect, while all my other devices worked fine.
- msbarnett 15y agoThe only time Ive ever had issues with OS X connecting to wifi was while using a cheapo router that insisted on advertising its 2.4GHz and 5GHz networks using the same SSID. Moving to a router that allowed them to be configured with different SSIDs resolved all my issues.
- shinratdr 15y ago> The only time Ive ever had issues with OS X connecting to wifi was while using a cheapo router that insisted on advertising its 2.4GHz and 5GHz networks using the same SSID. That is the default behaviour for an Airport Extreme.
- jrockway 15y agoThere are cheapo routers that do 5GHz?
- saurik 15y ago> 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 Apple actually is proud of? Am I the only one who finds that if you get a room full of people sitting around with Macs at least one person gets their IP address stolen by someone else? (edit: I just got downvoted, and then asked the people in the room with me, and they seemed to agree with my perceived correlation regarding the "another computer is using 192.1.0.1" issue... instead of just downvoting, maybe reply? It is actually quite common that DHCP leases on a network get reset for various reasons, and if you just jump on the network without revalidating your lease, you are actually quite likely to just "presumptuously" steal someone else's IP address.)
- kelnos 15y agoWhy 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 evidence that Macs in practice tend to inadvertently boot people off the network when they join?
- saurik 15y agoBy 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 environments quite often, crossing the boundary of the 1-2 day leases that are often given to clients.)
- 15y ago
- lurker19 15y agoI do not appreciate when my Mac just guesses a network setup and lies about being online instead of just waiting to see what is really there. It not fun to delete or rename a wifi network while debugging connectivity issues, only to have m Mac lie and say it is still connected to the network that no longer exists.
- juliano_q 15y agoThe 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.
- pohl 15y ago...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?
- caf 15y agoThe 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.
- th0ma5 15y ago"This whole notion of being so proprietary in every facet of what we do has really hurt us." Steve Jobs, circa 1997
- bradleyland 15y agoThere is nothing proprietary about this.
- th0ma5 15y agoDo you have any examples of other vendors using the last assigned address as a default?
- intranation 15y agoProprietary in the computer sense is generally taken to mean closed source or at least not made available to competitors or others. There's nothing to stop any other systems offering this kind of quick start DHCP service.
- th0ma5 15y agoExcept that it violates the specification right? I guess we're agreeing to disagree on the definition of proprietary. I can buy all of Apple's funky connectors through various suppliers, and maybe even fab them myself, but to me they're still proprietary. Sorry to be pedantic!
- jarek 15y agoCongratulations! Your laptop does the equivalent of using the exit lane to jump ahead in traffic. There's bound to be an empty spot near the end, right?
- shinratdr 15y agoThe 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.
- sid0 15y agoAnd yet it is exactly as dickish and disrespectful of others. Just like Apple as a whole, it seems.
- shinratdr 15y agoMeh. 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 15y ago[deleted]
- sid0 15y agoI 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.
- shinratdr 15y agoI'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?
- dhess 15y agoWhen 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.
- calloc 15y agoDHCP 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 because it is not letting your Mac use its old lease for one reason or another.
- dhess 15y agoI 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.
- brigade 15y agoThe hostname returned from DHCP doesn't affect the computer name in Sharing. What causes the (2) and such to be appended is if mDNS finds a record for whatever the computer's trying to use. I don't really have an idea for why this is happening for dhess since his laptop itself should be the only device responding to the mDNS query...
- ZoFreX 15y agoIt seems a little unscientific to compare logs from one machine connecting to a new networking and having to get a lease to another connecting to a network it's been on before.
- simmons 15y agoIt is unscientific. A more comprehensive study would analyze each device in a variety of well-defined scenarios, but in the interest of time I just took a few captures and put a couple under the microscope. I hope I didn't come across as trying to directly compare the tablet's ~11.8s startup on a fresh network to the Mac's ~0.03s startup on a known network. I know that the Mac is faster than my other devices via subjective observation, so I was mostly just interested in comparing the differences in the packets during this process.
- secure 15y agoSo, as far as I understand, the issue pointed out here is that the Mac is sending ARP requests with a cached source IP address (which therefore could be already in use). I wonder why it does that, as you can also send ARP probes originating from a source IP address 0.0.0.0 (and only having the MAC address set). I just tried it on linux: arping -D -c 1 -I wlan0 172.22.36.1 The computer with 172.22.36.1 will happily send me back its MAC address. So, is Apple doing something else here? Maybe relying on the router to not poison its cache and not reply at all if the IP is already taken.
- bradleyland 15y agoThere are three phases here: 1st phase is networking discovery. During this phase, the Mac is sending ARP who-has requests, which are "anyone out there" requests, not, "hey, I'm using this" requests. 2nd phase is the assumption. If the DHCP client in iOS is able to verify the Ethernet and IP address of the DHCP server match it's suspected network profile, and it has a valid DHCP lease record for that network, it assigns that IP to the interface and begins using it, at which point any potential ARP poisoning would occur. 3rd phase is DHCP negotiation. The first actual DHCP request goes out at 00.0140s, which is after the initial ARP network profiling, but before the interface actually comes up, so these actions could be considered asynchronous. Once the DHCP negotiation completes, any incorrect assumptions are abandoned and the DHCP issued IP would be used. There appears to be a window of 1.0s where the device is using an assumed IP address. During this time, traffic transmitted on the network would "poison" the ARP cache, but IP conflicts are not an end of the world scenario in networking terms. Once the proper DHCP resolution occurs, the ARP table would be updated and the conflict resolved.
- pieter 15y agoAnother nice trick of OS X is its use of IPv6, also for its multicast DNS (Bonjour) networking. This means you can have a bonjour session up and running long before you have an IPv4 address, especially in the absence of a DHCP server. It's what allows plugging a network cable between two macs and immediately start using NFS.
- thought_alarm 15y agoOne of my favorite features from way back involved running a local X Server and a number of remote X clients tunneling over ssh. I close the lid, pick up the laptop and go for lunch. Come back and open the lid and wifi is reconnected immediately and the remote X clients and SSH shells are still alive and active. And that was 6 years ago on a PPC iBook.
- swale 15y ago
- leoh 15y agoDoes anyone remember this? Princeton Information Technology: "iPhone OS 3.2 on iPad Stops Renewing DHCP Lease, Keeps Using IP Address" http://www.net.princeton.edu/announcements/ipad-iphoneos32-stops-renewing-lease-keeps-using-IP-address.html http://www.net.princeton.edu/announcements/ipad-iphoneos32-s...
- smackfu 15y agoVery interesting. It sounds like they had some troubles getting this to a properly working state.
- flogic 15y agoRather 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.
- vacri 15y agoI 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
- krakensden 15y agoThe tablet is using dhcpcd, which is plenty venerable.
- tintin 15y agoThe client is waiting a full second to give all DHCP servers the ability to answer the request for an IP address offer. Then the client will choose the best offer and will tell that DHCP server it took the offer. I think after that the DHCP server is letting all other DHCP servers know the current status of available IP addresses. Maybe that will also take some time (with a lot of waiting, time-outs and stuff). But then the question remains why should it take more than 2 seconds?
- satori99 15y agoIs this a genuine problem for any non Mac users? I do no use any Apple operating systems, but I have never had an issue with WIFI connection and address assignment times on any platform that I have used with regularity. On both windows and linux I am connected before I can even start an application.
- smackfu 15y agoI wonder if Apple has a patent on this technique.
- tlg 15y agoThey do : patent 20090006635
- ryannielsen 15y agoI'd like one person who's claiming this behavior is causing networking issues, is non standard, or is a security risk to provide proof. Suppose for a second that Apple's networking stack ruined things for other users, were in violation of standards, or insecure. They'd be lambasted. Furthermore, their users would have a sub-par experience. Bad press and, more importantly, a poor user experience are two things Apple tries to minimize. They'll only put up with bad press when they perceive it to be at the long-term benefit of their business, as with the iOS App Store. I assert this is not one of those cases. What seems more likely is that Apple decided device connectivity and wake-from-sleep performance is paramount, and then aggressively optimize to ensure Apple devices are awake and connected as quickly as possible. Period. Users hate waiting for a machine (or phone) to wake up and, once awake, they hate waiting for it to be usable. It seems Apple saw this pain point and decided to do something about it. And, as breaking standards compliance or introducing security risks would do nothing more than bring bad press and anger or frighten users, they almost certainly optimized in a standards-compliant and secure manner. I'm happy to be proven wrong. In the meantime, I'm going to appreciate the attention to detail and respect the work that went into providing this experience.
- known 15y ago# /etc/init.d/networking restart
- signa11 15y agoreading the title i thought this has to do with RFC-4039 a.k.a rapid-commit-option for DHCP, which basically allows clients to acquire configuration parameters in 2-message exchanges rather than the usual 4...
- e98cuenc 15y agoEverybody is discussing whether Apple is cheating and whether is it worth it, compared to the speed of connection of the Galaxy (0.03s vs 11s). Note that the Galaxy takes more than 10s to connect because is trying to be clever. If it started just doing the DHCP negotiation it will get an IP in 0.7s. Are the problems Apple devices create really worth saving 0.7 - 0.03s? BTW, 0.7s is an awful long time to get an IP. Anybody knows why a router takes so long to answer?
- TomLimoncelli 15y agoYes, 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.
- zwieback 15y agoAre 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.
- nickzoic 15y agoA second used to be a short time, now it seems like a thousand milliseconds. You might find RFC 4429 IPv6 "Optimistic Duplicate Address Detection" interesting ...