Fork me on GitHub

Caffeinated Bitstream

Bits, bytes, and words.

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

One of life's minor annoyances is having to wait on my devices to connect to the network after I wake them from sleep. All too often, I'll open the lid on my EeePC netbook, enter a web address, and get the dreaded "This webpage is not available" message because the machine is still working on connecting to my Wi-Fi network. On some occasions, I have to twiddle my thumbs for as long as 10-15 seconds before the network is ready to be used. The frustrating thing is that I know it doesn't have to be this way. I know this because I have a Mac. When I open the lid of my MacBook Pro, it connects to the network nearly instantaneously. In fact, no matter how fast I am, the network comes up before I can even try to load a web page. My curiosity got the better of me, and I set out to investigate how Macs are able to connect to the network so quickly, and how the network connect time in other operating systems could be improved.

I figure there are three main categories of time-consuming activities that occur during network initialization:

  1. Link establishment. This is the activity of establishing communication with the network's link layer. In the case of Wi-Fi, the radio must be powered on, the access point detected, and the optional encryption layer (e.g. WPA) established. After link establishment, the device is able to send and receive Ethernet frames on the network.
  2. Dynamic Host Configuration Protocol (DHCP). Through DHCP handshaking, the device negotiates an IP address for its use on the local IP network. A DHCP server is responsible for managing the IP addresses available for use on the network.
  3. Miscellaneous overhead. The operating system may perform any number of mundane tasks during the process of network initialization, including running scripts, looking up preconfigured network settings in a local database, launching programs, etc.

My investigation thus far is primarily concerned with the DHCP phase, although the other two categories would be interesting to study in the future. I set up a packet capture environment with a spare wireless access point, and observed the network activity of a number of devices as they initialized their network connection. For a worst-case scenario, let's look at the network activity captured while an Android tablet is connecting:

Samsung Galaxy Tab 10.1 - "dhcpcd-5.2.10:Linux-"
time (seconds) direction packet description
00.0000outLLC RNR (The link is now established.)
01.1300outDHCP request The client requests its IP address on the previously connected network.
05.6022outDHCP request The client again requests this IP address.
11.0984outDHCP discover: "Okay, I give up. Maybe this is a different network after all. Is there a DHCP server out there?"
11.7189inDHCP offer The server offers an IP address to the client.
11.7234outDHCP request The client accepts the offered IP address.
11.7514inDHCP ACK: The server acknowledges the client's acceptance of the IP address.

This tablet, presumably in the interest of "optimization", is initially skipping the DHCP discovery phase and immediately requesting its previous IP address. The only problem is this is a different network, so the DHCP server ignores these requests. After about 4.5 seconds, the tablet stubbornly tries again to request its old IP address. After another 4.5 seconds, it resigns itself to starting from scratch, and performs the DHCP discovery needed to obtain an IP address on the new network. The process took a whopping 11.8 seconds to complete. (Note: This would have been faster if my DHCP server was configured to send NAKs properly—see my update below... -simmons, 2011-07-21)

In all fairness, this delay wouldn't be so bad if the device was connecting to the same network as it was previously using. However, notice that the tablet waits a full 1.13 seconds after link establishment to even think about starting the DHCP process. Engineering snappiness usually means finding lots of small opportunities to save a few milliseconds here and there, and someone definitely dropped the ball here.

In contrast, let's look at the packet dump from the machine with the lightning-fast network initialization, and see if we can uncover the magic that is happening under the hood:

MacBook Pro - MacOS 10.6.8
time (seconds) direction packet description
00.0000outLLC RNR (The link is now established.)
00.0100outARP request broadcast who-has (The client is validating its link-local address)
00.0110outARP request unicast 00:22:75:45:e3:54 who-has tell
00.0120outARP request unicast 4e:80:98:f0:35:e3 who-has tell
00.0120inARP reply unicast from DHCP server: is-at 4e:80:98:f0:35:e3
00.0130outARP request unicast 00:0d:b9:54:27:b3 who-has tell
00.0140outDHCP request
00.0180outARP broadcast who-has tell
00.0210outARP broadcast who-has tell
00.0290outARP broadcast who-has tell
00.0290inARP reply unicast: is-at 4e:80:98:f0:35:e3
00.0310outUDP to router's port 192 (AirPort detection) This implies that the IP interface is now configured.
......(More normal IP activity on the newly configured interface)
01.2680outDHCP request
01.3043inDHCP ACK

The key to understanding the magic is the first three unicast ARP requests. It looks like Mac OS remembers certain information about not only the last connected network, but the last several networks. In particular, it must at least persist the following tuple for each of these networks:

  1. The Ethernet address of the DHCP server
  2. The IP address of the DHCP server
  3. Its own IP address, as assigned by the DHCP server

During network initialization, the Mac transmits carefully crafted unicast ARP requests with this stored information. For each network in its memory, it attempts to send a request to the specific Ethernet address of the DHCP server for that network, in which it asks about the server's IP address, and requests that the server reply to the IP address which the Mac was formerly using on that network. Unless network hosts have been radically shuffled around, at most only one of these ARP requests will result in a response—the request corresponding to the current network, if the current network happens to be one of the remembered networks.

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. (Well, it does perform a self-ARP for good measure, but doesn't seem to wait more than 13ms for a response.) The DHCP handshaking process begins in the background by sending a DHCP request for its assumed IP address, but the network interface is available for use during the handshaking process. If the network was not recognized, I assume the Mac would know to begin the DHCP discovery phase, instead of sending blind requests for a former IP address as the Galaxy Tab does.

The Mac's rapid network initialization can be credited to more than just the network recognition scheme. Judging by the use of ARP (which can be problematic to deal with in user-space) and the unusually regular transmission intervals (a reliable 1.0ms delay between each packet sent), I'm guessing that the Mac's DHCP client system is entirely implemented as tight kernel-mode code. The Mac began the IP interface initialization process a mere 10ms after link establishment, which is far faster than any other device I tested. Android devices such as the Galaxy Tab rely on the user-mode dhclient system (part of the dhcpcd package) dhcpcd program, which no doubt brings a lot of additional overhead such as loading the program, context switching, and perhaps even running scripts.

The next step for some daring kernel hacker is to implement a similarly aggressive DHCP client system in the Linux kernel, so that I can enjoy fast sign-on speeds on my Android tablet, Android phone, and Ubuntu netbook. There already exists a minimal DHCP client implementation in the Linux kernel, but it lacks certain features such as configuring the DNS nameservers. Perhaps it wouldn't be too much work to extend this code to support network recognition and interface with a user-mode daemon to handle such auxillary configuration information received via DHCP. If I ever get a few spare cycles, maybe I'll even take a stab at it.

Update, July 12th, 2011 1pm MT:

This post has been mentioned on Hacker News, and there's lots of lively discussion in the comments over there.

Some people have pointed out some disadvantages in putting a full-featured DHCP client in the kernel. I'm skeptical about putting the DHCP client in the kernel, myself. However, I didn't want to elaborate on that at 2:00am, since the post was getting way too lengthy as it was. If I had known it would be subject to such peer review, I might have been a bit more careful with my words. :)

The argument for putting the DHCP client in the kernel basically boils down to:

  1. Achieving speed is all about shaving a few milliseconds here and there, and you just can't launch a program, wait for it to dynamically link, load config files, etc., and get the 10ms response time that the Mac has. (10ms from link establishment to transmitting the first DHCP packet.) I'm told that the dhcpcd program is a persistent daemon, so maybe the launch overhead isn't there. But something is keeping Linux hosts from having a 10ms response time.
  2. Doing ARP tricks could be awkward in user-space. You'd need to use the raw socket interface for transmitting (which isn't a big deal), and you'd have to use something like the packet(7) interface to sniff incoming packets to observe the ARP replies. I haven't played around with the packet(7) interface, so I'm not sure what the pros and cons might be.

Neither of these are show-stoppers to an improved user-mode DHCP client, but that was my thinking at the time. Now, I think I would certainly start with a user-mode solution, since a carefully crafted daemon should be able to achieve comparable response time, and the arping(8) program doesn't seem to have any problem using packet(7) to send and receive ARP packets in user-space.

Update, July 13th, 2011 2:48am MT:

Thanks to M. MacFaden for pointing out in the comments that this scheme is basically an implementation of RFC 4436: Detecting Network Attachment in IPv4 (DNAv4), which was co-authored by an Apple employee.

Update, July 21th, 2011 1:20pm MT:

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). Below is the revised chart of network activity for the Galaxy Tab:

Samsung Galaxy Tab 10.1 (Revised) - "dhcpcd-5.2.10:Linux-"
time (seconds) direction packet description
00.0000outLLC RNR (The link is now established.)
01.1570outDHCP request The client requests its IP address on the previously connected network.
01.1574inDHCP NAK: The server declines to allow on this network.
02.2261outDHCP discover
02.5871inDHCP offer The server offers an IP address to the client.
02.5951outDHCP request The client accepts the offered IP address.
02.6198inDHCP ACK: The server acknowledges the client's acceptance of the IP address.

These times are more in line with what I see on most non-Mac devices on my non-test networks—about 2.5-3s in DHCP, plus a bit more time for link initialization and such—long enough that I frequently get a "no connection" error in my web browsers. We'll need to find ways to shave this down in emerging consumer electronics devices. Consumers are conditioned to think of PCs as "something you wait on," but expect non-PC network devices to behave more like light switches.

I've posted a summary of the discussion in another entry.


This would seem to imply a handful of unpleasant things. Admittedly, my networking knowledge is weak, but this still interesting to me. First, if it's ARPing as soon as the link's established, this would mean that it's exposing the same information as a Windows computer to wireless attackers, who rely on ARP packets to crack WEP and WPA-TKIP. Bumping a Mac off the network would guarantee a handful of packets which can then be endlessly replayed to gather information about the wireless network. Second, is it dhcpcd or dhclient? They're two different DHCP clients, and they definitely have differing styles. I'd expect these kinds of delays from dhclient, but not dhcpcd.

Posted by Corbin Simpson on July 12, 2011 at 11:33 AM MDT #

+1 I would love to have that speed in Linux!!! You are a real hacker, I just couldn't explain why the mac was faster! I thought it was just my wifi driver. To be fair in ubuntu 11.04 it seems slightly faster than in 10.10

Posted by Dave on July 12, 2011 at 11:41 AM MDT #

Hi Corbin,

It's good that you bring up security considerations. I should definitely mull over the implications before banging out a mod_fastdhcp.ko module! I'm not knowledgeable about the various attack vectors with WEP and WPA-TKIP, but my first thought is that perhaps the problem rests with those schemes if they are susceptible to such packet replay weaknesses.

You're right -- dhclient and dhcpcd are two different programs. I glanced at an Ubuntu 10.04 machine, and saw that /sbin/dhclient was part of the dhcp3-client package, and must have seen "dhcpcd" somehow. That's what I get for posting at 2am. :)

Posted by David Simmons on July 12, 2011 at 11:48 AM MDT #

Since using Linux on a laptop for the first time a year or so ago, I've been wondering why my Mac is so much faster. Nowadays I do a fare share of waking from sleep on an Asus eee, where I run wpa_supplicant and dhcpcd in a screen session. By the way, does wpa_supplicant do _something_ the kernel can detect, if this is to be a kernel module?

Posted by August Lilleaas on July 12, 2011 at 12:09 PM MDT #

Unfortunately, given the glee with which kernel support for IP autoconfiguration was mostly removed a number of years ago and declared to be a "userspace problem" (residual support notwithstanding), it seems to me rather unlikely that Linus would accept such a patch.

None of the things e.g. the Android or Linux systems do that take so long to bring the link back up are inherently unreasonable, but taken together do result in a significantly worse user experience.

Conversely, I have a bit of trouble accepting the Mac behaviour as inherently superior, because I feel that they've reduced delays so much that while it undoubtedly works Just Fine™ in the vast majority of cases where installed networking operates well, it's rather fragile in that it wouldn't take much—a loose socket, a bad cable, WiFi interference—to render it completely inoperable. (Note that I have no idea what the Mac might do in the face of network problems; I would hope it has some sort of sensible "slow and steady wins the race" fallback.)

While it may be difficult to get such precise, accurate timing in userspace, I think it still should be possible. There are various kinds of real-time or high-priority scheduling available in even a stock Linux kernel, and even sending packets at a 100x slower rate (every 100 ms instead of every 1) would still produce a massive speedup over current behaviour.

Posted by Ice Karma on July 12, 2011 at 12:12 PM MDT #

It is not possible to abuse WEP layer with this. You have to be connected with WEP prior to make a dhcp request. In wired technology this is akin of saying that your ethernet cable has to be plugged in before making a dhcp request

Posted by Eric on July 12, 2011 at 12:23 PM MDT #

Caching the DHCP lease locally for particular networks is a reasonable "hack". The real problem with DHCP, however, is that DHCP Discover packets are sent to the broadcast address and do not get the benefits of MAC layer retransmissions on 802.11 networks. DHCP is not slow because it's not in the kernel (there really is no reason to put it in the kernel) -- passing packets to userspace takes less than a ms. However, one could use different hacks to mitigate its issues on 802.11 networks. For example, one research project advocated flooding DHCP packets until a reply was received, which resulted in 300ms time to configure the network. Another hack would be to set the MAC address to the AP -- the problem in that case is the coupling of 802.11 MAC layer with DHCP. The real problem, however, is that DHCP is not meant for 802.11, but because of the notion of abstractions we've basically replaced the physical and MAC layers (which has implications at higher layers), but didn't consider what happens above that.

Posted by Timur on July 12, 2011 at 12:56 PM MDT #

@Eric, Current WEP cracking techniques only need a large number of packets in order to deduce the key, and one of the methods to obtain them (besides waiting forever) is to sniff out encrypted ARP packets and reinject them into the network as fast as you can. As long as you're associated with the network (you don't have to be authenticated), this is possible if the network is using open system authentication.

Posted by James on July 12, 2011 at 12:58 PM MDT #

Timur nailed it - MAC layer retransmission is the key here to achieve fast RTTs and quick host config ... so user space is ok - context switches are microsecond kinda things ... we've got to add it to linux now! good job Apple hacking DHCP and making my things connecting super fast! i always noticed that but now i know why!

Posted by fantazio on July 12, 2011 at 03:08 PM MDT #

Might find the above RFC enlightening.

Posted by M. MacFaden on July 12, 2011 at 03:24 PM MDT #

I don't think OS X has a DHCP client in the kernel. Isn't the client part of the configd process? That lives completely in userland. You can grab the source of the version from 10.6.8 at

Posted by Stefan Arentz on July 12, 2011 at 04:11 PM MDT #

If an ARP packet is more subject to interception then perhaps it's time we find a more secure method of address resolution that clears a more secure network barrier. As to how this would be accomplished, it's beyond my scope or skill at this time to invent. The problem with current wifi standards is it's effectively throwing darts in a pitch black room waiting to hit someone and get a scream to know you hit them. If we can invent a way to circumvent this guessing game with wireless standards security would take an astronomical leap in efficiency. The only plausible ways I can think of implementation are directional antennas or limited/restricted range

Posted by Lemur on July 12, 2011 at 05:05 PM MDT #

@Ice Karma: apparently it recovers pretty quickly from any event. On a Mac Mini, i can unplug the ethernet cable, plug it back and have internet access again in <2s. Switching from ethernet to wifi takes less than a second, and the opposite way it happens instantly.

Posted by Junior on July 12, 2011 at 06:29 PM MDT #

A self-arp (as you state it) is actually called a gratuitous arp. It's intention is to not see if the IP is in use but to broadcast out the IP->MAC pair to all hosts to update everyones arp table with a new mac address. The check to see if the address was still in use is done by the first ARPs above. I complete agree with Timur on this one. The DHCP protocol itself is the issue (and the Galaxy Tab and almost all other clients) is behaving as the protocol is written in the RFC. @Lemur This has nothing to do with Wifi. The same problem exists on a wired connection as well as well as the exact same behavior. The latency for WiFi wouldn't be a concern here with the occasional exception for some advanced security (Enterprise WPA or MAC Radius authentication)

Posted by Brandon on July 12, 2011 at 11:52 PM MDT #

Is there a way to make Linux DHCP go fast, then? Is there a reasonable middle road to take that doesn't completely jeopardize the security of enterprise solutions and at the same time cut the connection delay on typical home networks (which make most of the networks used today...)?

Posted by G on July 13, 2011 at 01:35 AM MDT #

I would think that things could be a lot faster in userspace just by implementing the "ping remembered MAC addresses to see if we're on a known network and our old address is free; if so, assume the old address" step -- it would at least cut out the 10 second delay where dhcpcd doesn't realise it's on a new network. That still leaves the ~1.3 seconds of other jobs, but practically it's not far off 0.03s (both approaches would be finished by the time you've typed a URL), which is massively better than 11s.

Posted by Shish on July 13, 2011 at 07:20 AM MDT #

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? Have you tried to reproduce the experiment with a machine at the old IP address? It would be interesting to see how things change.

Posted by Tom Limoncelli on July 13, 2011 at 08:10 AM MDT #

OS X handles DHCP through IPConfiguration (in bootp package).

Posted by Toni Viemerö on July 13, 2011 at 09:08 AM MDT #

Not sure if this was asked but have you tested to see of this is the case in iOS also? (That the Apple OS reconnects so fast.) Thanks

Posted by Ty Miles on July 13, 2011 at 11:11 AM MDT #

This is most probably covered and protected by Apple's patent 20090006635. On the other hand, an implementation is published under the APSL from the link to the bootp source posted above.

Posted by Philippe Gauthier on July 13, 2011 at 01:07 PM MDT #

A dhcp server can be configured to be an authoritative server or a non authoritative server. That dhcp server is ignoring those dhcp requests when a dhcp client asks for an address out of its network range because it was told to do so by being configured to be a non authoritative dhcp server. If you only have on dhcp server on the network, make it an authoritative one. and your clients will immediately be told they are on the wrong network when they ask for an IP address and you will save yourself a few seconds when they are coming from a different network It looks like you have a badly misconfigured dhcp server on your network it should take some of the blame

Posted by mtz on July 13, 2011 at 01:18 PM MDT #

[Trackback] Rapid DHCP: Or, how do Macs get on the network so fast? : Caffeinated Bitstream:...

Posted by Small Thoughts on July 13, 2011 at 01:47 PM MDT #

For what it's worth:;a=summary;a=summary

Posted by Anon on July 13, 2011 at 02:45 PM MDT #

RFC4436 is authored by Stuart Cheshire of Apple, but also Bernard Aboba (Microsoft) and James Carlson (Sun), and was the product of the Dynamic Host Configuration WG in the IETF. Just making sure credit goes where it belongs.

Note that there are *not* any IPR disclosures for it; see this.

Posted by Mark Nottingham on July 14, 2011 at 12:28 AM MDT #

My Google Chromebook (CR-48) rapidly connects as well. I haven't looked to see what mechanism it uses, but in the time it takes me to open the lid (which wakes it from sleep), it has reconnected to my WAP with WPA2, established its IP address, and in fact Gmail has already refreshed my inbox.

Posted by Tyrel on July 14, 2011 at 09:08 AM MDT #

My Samsung Series 5 Chromebook takes a bit of time to get on the network. I wonder if it has a different Wi-Fi chipset than the CR-48. I made this YouTube video showing the Samsung Chromebook and the Mac side-by-side while the network is initializing. (This video is from before I performed the above research...)

Posted by David Simmons on July 14, 2011 at 02:29 PM MDT #

I had originally had slowness and other problems with my CR-48's Wi-Fi, but the last month or two the connection has been fast like this. I'm on the dev builds so that may make a difference too.

Posted by Tyrel on July 14, 2011 at 02:49 PM MDT #

Just a note: If your DHCP server behaves like this, it's improperly set up. When a DHCP server sees a DHCPREQUEST for a network it doesn't know anything about, it should immediately DHCPNAK it. Try adding “authoritative;” to dhcpd.conf—it's not set up like this by default in order to avoid DHCP servers that were set up by accident create havoc in production networks.

Posted by Steinar H. Gunderson on July 21, 2011 at 05:05 AM MDT #

Steiner -- great catch! I was using the defaults for this test network, so the dhcpd was not authoritative. I re-ran the test, and updated the post with the revised results.

Posted by David Simmons on July 21, 2011 at 01:26 PM MDT #

[Trackback] OS X is actually pretty smart about this situation, or at least as smart as the technology will allow:

Posted by Quora on July 28, 2011 at 01:56 PM MDT #

[Trackback] Great look at how do Macs get on the network so fast? Someone did some packet captures and tried to...

Posted by on August 04, 2011 at 12:18 PM MDT #

[Trackback] Great move for Google and for Android: Google to Acquire Motorola Mobility.I agree with Warren Buffett: Stop Coddling the Super-Rich.How to put your logo in a QR code.Ken Jennings has...

Posted by on August 16, 2011 at 12:03 AM MDT #

I was just wondering if you have repeated this experiment on Lion. It seems to me that this is no longer true on Lion. I'm very interested in knowing why Lion gets on the network so slowly now, but I don't have the skills to do it.

Posted by Jimmy Wong on August 31, 2011 at 09:58 PM MDT #

What a fantastic blog post, thanks! I've noticed my ethernet-wired iMac is much slower at getting online after sleep (or even during boot) than my WiFi Air, on the same network. Is there something about this fast connect system that is WiFi only?

Posted by Nelson Minar on September 10, 2011 at 12:11 PM MDT #

Nelson - I don't know any technical reasons why Wi-Fi would be faster than wired. The "Rapid DHCP" scheme certainly should be link-neutral. However, there are probably many other factors that contribute to fast network sign-on besides the DHCP handshaking. For example, the device driver's initialization of the network hardware and establishment of link-layer communications could perhaps vary a great deal between machines.

Posted by David Simmons on September 12, 2011 at 11:42 AM MDT #

This implementation has several flaws. I hadn't thought about it until now, but at my old job we had a director who had an iPhone. Whenever he connected to the wifi, would get booted off the network (which happened to be the default gateway out of the network for some reason). Turns out, his home network wifi was giving him the address. So as soon as the iPhone woke up on the work LAN, it thought it was in the same network so it just configured itself to use This caused a major headache as internet connectivity would intermittently go down. Solution? Moved the corporate LAN to a 10.*.*.* subnet that no one would use.. Problem solved. Apple needs to fix their stuff. Android may have this problem too. I think Princeton University may have documented this weirdness.

Posted by Tom Murphy on December 21, 2011 at 09:52 AM MST #

Apple might have thought they were being smart by doing this, but in reality, it's problematic when you use it in an enterprise and have more complicated switching configurations. For example any Network Access Control, where an "uncompliant" or unknown machine is shunted off to a different network, the MACs just do their own thing and resume their past IP address on the incorrect vlan. The reason is that initially the DHCP request goes to the database which verifies certificates etc... and then tells the switch to put them on X vlan for inside, or Y vlan for outside. That initial "I'm on X subnet" (to pass the initial handshake to the DB) is all the Mac needs to get in it's head that it will never change subnets, and then basically ignores any further instructions from the DHCP server to get a new address. It just further intensifies my opinion of Apple as being a our way or no way attitude. You'd think at least if you release/renew it'd realize it's now on a different subnet, but they have no logic to account for enterprise configs. Fine, use wireless, they don't even include a wired connection. These are the same people that don't include an emergency eject hole for CD-Roms... Because they're CD drives never jam!!! Such Bravado...

Posted by Bill Gould on May 11, 2012 at 10:27 AM MDT #

I think the bigger question is why can't the DHCP server give your a IP address faster? It knows all of the information before hand all it has to do is see if it has already seen your MAC (hash) otherwise give you the next IP (which it already knows). Seems like the whole thing could be done in 10ms. Then we would not need all of the hacks.

Posted by David Moffatt on May 25, 2012 at 06:13 PM MDT #

[Trackback] Discover a selection of related articles on Pearltrees

Posted by Pearltrees on July 12, 2012 at 07:10 AM MDT #

[Trackback] Mac OS X retains some information about not only your most recently connected network but the last several networks that you've used. Upon waking, it then sends a series of messages that enable it to identify which of these recently used networks are p...

Posted by Quora on August 01, 2012 at 01:21 PM MDT #

Regarding your update "Update, July 21th, 2011 1:20pm MT:" Did you try with a setup where the mobile used to be on one network and it is moving to a different network which has the same IP subnet configuration? I think your "authoritative;" setup in your DHCP server will not help you in this case. AFAIK, you will still see ~10 seconds of silent and then the mobile would timeout and then will send DISCOVER. Here is a relevant link: Might be a bit confusing but here is a quote: If the server knows nothing about the address, it will remain silent, unless the address is incorrect for the network segment to which the client has been attached and the server is authoritative for that network segment, in which case the server will send a DHCPNAK even though it doesn’t know about the address. So the reason you could shorten it and get a NAK is because the address is "incorrect for the network segment to which the client has been attached and the server is authoritative for that network segment" This would be different if the address was "correct for the network segment". (e.g. the previous network was and the new network has the same config - At least in my tests I can see the differences and it is quite obvious.

Posted by Kobi on April 04, 2013 at 09:44 PM MDT #


Now i know why my macbook always attempted (for far longer than the 1 second implied above that it should take) to reuse its old IP when I wanted to forcibly change it in DHCP to a different IP.

What you call a feature, annoys the hell out of me.

A DHCP client should ALWAYS attempt to ask for an IP instead of presuming the old one should work if an ARP reply isn't returned, wrongly using an IP that will be NAKd soon...


Posted by Mike H on June 28, 2013 at 03:56 AM MDT #

Is this RFC 4436?

Posted by Chester T Field on April 02, 2014 at 02:10 PM MDT #

Smells like a solid provacy leak...

Posted by on December 23, 2014 at 08:30 PM MST #

I came across this after I found Apple devices booting other devices off a school network I run. There's a big problem here, though. Part of RFC4436 states: "As a performance optimization, it must not sacrifice correctness. In other words, false positives are not acceptable. DNAv4 must not conclude that a host has returned to a previously visited link where it has an operable IP address if this is not in fact the case." I have an entire week's worth of DHCP logs showing Apple devices absolutely failing at this part. One of the VLANs has the subnet I've noticed that the Apple devices causing issues, are trying to take IPs in the range. Every morning when the teachers bring these apple devices in, they each assign themselves the same IP. One for which that 1) the lease would have expired from the previous day, since they are 8 hours long, and 2) they *never* had a lease for the IPs they are stealing in the first place. As an example, every morning, an Ipad assigns itself This IP belongs to a desktop that has been on for weeks, and owns the lease for it in DHCP. Every morning it makes it throw an IP conflict, at which point the DHCP server tells the Ipad "NO" and assigns it a new one. The ipad uses the new IP for the rest of the day. The next morning, it again assigns itself Every day for the last 5 days. My theory is that if any of the last known networks have overlapping subnets, it does not take this into account. Presumably that ipad has at the user's home, and is failing at determining what lease it last had on the school network. In other words, the Apple devices are *not* fully complying with RFC4436.

Posted by Isil on May 05, 2015 at 02:54 PM MDT #

Post a Comment:
  • HTML Syntax: Allowed