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

http://cafbit.com/entry/rapid_dhcp_or_how_do

by timdoug • 15 years ago

354 178 15 years ago

hardtke• 15 years ago

I'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• 15 years ago

I'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.

mseebach• 15 years ago

Yeah, 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.

bradleyland10• 15 years ago

The 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.

bradleyland10• 15 years ago

I'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• 15 years ago

I'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• 15 years ago

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

MostAwesomeDude• 15 years 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.

kcbanner2• 15 years ago

I think I'd still prefer the standards compliant client, even if it was a slightly slower. Kicking other users off the network isn't a good thing.

simmons4• 15 years ago

I'm the author of the original blog post. I also ran my tests with a Samsung Series 5 Chromebook. Its DHCP Vendor-Class string is "dhcpcd 5.1.4". The DHCP performance seems fair, around 2 seconds. However, the total network initialization time tends to be a bit longer. It may have some of the same link establishment delays that I'm seeing on my Ubuntu 10.04 EeePC.

dotBen• 15 years ago

There already exists a minimal DHCP client implementation in the Linux kernel, but it lacks certain features such as configuring the DNS nameservers.

I wonder if it is possible to use the kernel-level DHCP client to instantly request the IP address while asynchronously initiating the more functional user-mode dhclient?

Once dhclient is up, and the kernel DHCP client has obtained an IP address it could just pass that 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.

hristov7• 15 years ago

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

I think there probably was something wrong with the DHCP server configuration.

caf5• 15 years ago

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

kenjackson• 15 years ago

This 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.

aaronblohowiak2• 15 years ago

Not 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.

cbs4• 15 years ago

The lower level networking protocols do rely on some levels of peer trust, but carefully controlling that trust has come a long way in the last decade. If I'm correct in assuming by "actual security" you mean "physical security" you're making some pretty broad and faulty statements (even about layer 1).

There are many networking devices and techniques for hardening hostile networks at layer 2. Layer 3 is IP; to say level 3 (or 4) measures are not "real" is throwing HUGE swaths of security out the window.

cbs4• 15 years ago

This certainly smells fishy, the client is relying on ARP to assume its OK to reclaim that IP address before it actually gets the authoritative answer from the DHCP server. IP networking does not require that computers submit to dhcp, so depending on how you look at it, it probably doesn't run afoul of the spec.

I'd have to get a more detailed packet capture and reference some RFCs, but given DHCP isn't manditory, I don't think it would be harmful to the mac or network as long as the client's DHCP lease was still valid when it pulled this stunt, otherwise you could get multiple clients claiming the same IP address.

From a security standpoint rather than only revealing just your most recently DHCP-assigned address, you're revealing both the mac address of the nearest layer 2 device and gateway ip of (some nonzero number of) networks you've recently connected to. If a hostile network were to monitor the arp requests to successfully emulate a network the connecting mac had recently been connected to, the IP traffic prior to DHCP ACK that was abridged in the article would probably be sent again. Not knowing what it contained, I can't speculate as to if it would be any different than the network communication that would be done if connecting to a new network.

(Even if everything else was application traffic, I don't anything about the udp/192 protocol for airports, but it may be spoken with assumptions made about the connected network and a vector worth exploring).

tomlogic3• 15 years ago

Regarding your security statement, I didn't get that from the packet capture. The Mac is sending an ARP request for the IP addresses of the DHCP servers of networks it's been on recently. An attacker would need to know the correct MAC address to respond with -- the Mac is not sending that out in the request.

If the ARP comes back with the cached MAC address for that network, the Mac continues using the valid DHCP lease it was given. It sends a DHCP request to renew that lease, and I assume would reconfigure the interface if the request fails and discovery has to start over.

From my recollection of the DHCP RFC, if a server hands you a lease for one week, you're allowed to use that address for a week, even if you go offline for 3 days in the middle. In practice, this may not be the case.

bradleyland10• 15 years ago

It's not a violation of the DHCP protocol, because the requests being made aren't specifically DHCP requests. It might be a violation of network policy though, but that depends on your perspective, not an RFC.

Think of it like this. Your iOS device assumes that if it's on the same network, and it has a valid/current DHCP lease, it will use that address while it goes about the business of negotiating a proper DHCP address. The assumption is made outside the scope of negotiating an actual DHCP address.

A violation of the protocol would involve tricking the DHCP server or sending false information to the DHCP server. Neither happens here.

It's up to the network owner to decide whether or not this is acceptable. With a properly functioning network equipment, you should never encounter a failure of this assumption. If you have an unhealthy network, the assumption may fail more frequently, but then again, you're just compounding an existing issue that should probably be resolved.

In the end, we're talking about saving 10s every time you wake your device up. Ten seconds. That's significant. I use my iPad/iPhone very casually. I don't think about "grouping" my usage, because it works instantly when I pick it up. My network works properly, so I'm happy it's making these assumptions.

pinko• 15 years ago

This 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• 15 years ago

Well, in that case they might not be following the protocol. And in some cases break the connectivity for others...

rektide3• 15 years ago

DHCP (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.

kcbanner2• 15 years ago

Is this case the Mac user may get a better UX, but the user who's IP was just stolen has a worse one.

Locke16896• 15 years ago

I'd like to see evidence that this happens enough to matter. Any time you use a Bloom filter you recognize that doing great in most cases is much better than doing OK in every case.

mgkimsal2• 15 years ago

Interesting 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).

kelnos4• 15 years ago

Huh, 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.

mgkimsal2• 15 years ago

I 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.

troels• 15 years ago

Anecdotally, 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• 15 years ago

I 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.

cbs4• 15 years ago

Anecdotally, 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• 15 years 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.

Moving to a router that allowed them to be configured with different SSIDs resolved all my issues.

shinratdr13• 15 years 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• 15 years ago

There are cheapo routers that do 5GHz?

5hoom• 15 years ago

Another anecdote, I have encountered the occasional bit of strange behaviour with my macbook & various iDevices 'stealing' existing ip addresses on my home network, but it happens infrequently enough that I haven't been motivated to look into the problem. How it seems to go is that if the mac & iDevices are switched on simultaneously suddenly my PC's get connectivity issues. My interest in getting to the bottom of this phenomena has been piqued after reading this story. I will confess however that my router is a bit old & flakey & that I'm a very lazy admin ;)

saurik9• 15 years 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.)

kelnos4• 15 years ago

Why 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?

saurik9• 15 years ago

By 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.)

mike-cardwell• 15 years ago

I've experienced a few cases where I've joined somebody elses network with my Macbook and it's stolen an IP address that someone else was using.

jsz0• 15 years ago

If your DHCP server is handing out leased addresses to other clients you might have bigger problems to worry about. For example if you expect a lot of churn on the network you should be using much shorter leases times.

Groxx• 15 years ago

Correct, but Coffee House X, Y, and Z don't realize this. Which makes it the computer-owner's problem too.

windsurfer2• 15 years ago

How is this the DHCP server's fault? DHCP is designed to reassign unused leases to new clients if the subnet is all leased out.

bonch• 15 years ago

Sorry, but nobody cares what the people in your room think.

burgerbrain• 15 years ago

Wrong, I care. I don't have any way of confirming it myself so his double-checking was appreciated.

brk2• 15 years ago

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?

In 4 or 5 years of using OS X laptops in multiple locations (eg: private office, large corporate office with shared wifi, more hotels and airports and coffee shops than I can remember) I can't ever recall having this happen to me.

bradleyland10• 15 years ago

The DHCP stack in iOS does some profiling that should reliably detect whether it is, in fact, on the network that it expects. The most significant of which is the verification of the DHCP server's Ethernet address as correlated to IP.

If you are on a known network, your DHCP lease is still active, and network equipment is working as expected, all of these assumptions are safe. The most common failure scenario is where the DHCP server has lost its DHCP lease table. For many consumer routers, this will occur when the router is rebooted. If you have to reboot your router frequently, you should replace it. Even if you do encounter a failure mode, the error will clear a second or two later when a new address is negotiated via DHCP and the subsequent ARP update.

This is very clearly a trade-off. Devices like the iPhone and iPad are switched on and off very frequently. The difference between 10s to network ready and 0.3s to network ready is more than significant; it's monumental. This is especially true for devices whose use-pattern will involve frequent on-off usage.

If you're uncomfortable with this trade off, you should stay away from Apple devices. Personally, I'll take the 10s.

saurik9• 15 years ago

Down-thread of this comment, people have already discussed numerous issues with the assumption that DHCP leases are stable when not in use (such as that servers often choose to allocate out of an artificially small pool of addresses, and ping old addresses to determine if they are in use before simply reclaiming and reassigning them).

pyre2• 15 years ago

  > If you have to reboot your router frequently, you
  > should replace it

You are assuming that people will only ever use these devices on networks that they control.

sedev2• 15 years ago

I think that you're wrong because, basically, if that 'steal an IP address' scenario happens, it means that the DHCP server has in some way broken its promises. That _happens_ in production environments, but I'd much rather clients use behavior like this, that assumes that a DHCP server will keep its promises about things like lease length, than assume the worst about the DHCP server. The clients should first assume that the server will keep its promises, and only on evidence that it hasn't, seek alternatives.

jarek11• 15 years ago

So here's my understanding of the situation: when a DHCP server runs out of leases to assign, it will kill the oldest (in terms of use) lease. If the device that held the lease is not on, for relevant values of "on", at the time, it will not be notified about this.

The usual (perhaps standard, I'm not sure) process has the device confirming its DHCP lease when coming back on, and in this situation the device would be notified that it can't have the old lease as it's been repurposed, and the server will provide another lease (perhaps after killing some yet another lease).

If this is an Apple device and it behaves in the manner described, after coming back "on" it will not consult DHCP, but rather it will reuse the lease it held previously. If the server has given that lease to another device, the Apple device will butt in, causing an IP conflict. Perversely, the Apple device will shortly discover this, actually do a DHCP request, and switch over with no indication to the user, leaving the other device to wonder why it had an IP conflict and how to handle it.

Is this incorrect in any way?

hristov7• 15 years ago

Being a dork and a lawyer, I actually looked up the DHCP protocol. This is the relevant part:

"3.7 When clients should use DHCP

   A client SHOULD use DHCP to reacquire or verify its IP address and
   network parameters whenever the local network parameters may have
   changed; e.g., at system boot time or after a disconnection from the
   local network, as the local network configuration may change without
   the client's or user's knowledge.

   If a client has knowledge of a previous network address and is unable
   to contact a local DHCP server, the client may continue to use the
   previous network address until the lease for that address expires.
   If the lease expires before the client can contact a DHCP server, the
   client must immediately discontinue use of the previous network
   address and may inform local users of the problem."

So no there is no indication in the protocol that the clients should assume that the DHCP server will keep its promises after a disconnection from the network. Furthermore, if you use common sense there is no reason to make this assumption in most real life situations. In a coffee house somebody can always trip over the router's cable, for example.

rektide3• 15 years ago

The Mac's DHCP client is using the router's mac addresses to verify it's on the right network, and it already knows it still holds the lease. What the fuck more do you want? What are you afraid of?

The only conceivable grief you can put forward is that the ARP check isn't good enough. The client already owns the lease. If there's IP contention, it's because either a) it's not on the right network after all (arp check) or b) the server's fucked up and it's the servers fault (dhcp server allocated an IP twice).

Ok, so assuming the DHCP server isn't faulty may be a bit of a stretch. But coding your client to assume the server can do it's job does not deserve an "Ok, seriously?" hurf-burf post.

saurik9• 15 years ago

I take it you have not read any of the rest of this thread?... all of the comments about how DHCP in the wild doesn't work that perfectly, or people saying "this happens all the time with my / my wife/friend/boss's Mac"?

smutticus• 15 years ago

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

zb• 15 years ago

> Ok, seriously? That isn't a bug in an implementation somewhere,

No.

> but in fact a feature that Apple actually is proud of?

Not just Apple, but I imagine also Microsoft and Sun. They were so proud of it that they wrote a standards-track RFC for it: http://www.ietf.org/rfc/rfc4436.txt

And yes, they were aware of this issue:

   One case where DNAv4 does increase the likelihood of an address
   conflict is when:

      o  a DHCP server hands out an address lease,

      o  the host with that lease leaves the network,

      o  the DHCP server is power-cycled or crashes and is rebooted,

      o  the DHCP server, having failed to save leases to stable
         storage, assigns that same address to another host, and

      o  the first host returns and, having a still-valid lease with
         time remaining, proceeds to use its assigned address,
         conflicting with the new host that is now using that same
         address.

   While Section 4 of the DHCP specification [RFC2131] assumes that DHCP
   servers save their leases in persistent storage, almost no consumer-
   grade NAT gateway does so.  Short DHCP lease lifetimes can mitigate
   this risk, though this also limits the operable candidate
   configurations available for DNAv4 to try.

But evidently they thought it was a good trade-off, and I am inclined to agree.

lucian1900• 15 years ago

This "feature" has fucked me over so many times! If the DHCP server is configured to be strict, or even a little paranoid, every now and then my macbook would just refuse to connect. I'd have to clear DHCP caches, settings and restart.

lurker19• 15 years ago

I 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.

thecombjelly2• 15 years ago

Interesting. 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.

simmons4• 15 years ago

Huh, 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.

thecombjelly2• 15 years ago

I have a EeePC 900A and the driver for wireless is by far the best I've experienced on Linux.

juliano_q• 15 years ago

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

pohl• 15 years 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?

caf5• 15 years ago

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

th0ma55• 15 years ago

"This whole notion of being so proprietary in every facet of what we do has really hurt us." Steve Jobs, circa 1997

bradleyland10• 15 years ago

There is nothing proprietary about this.

th0ma55• 15 years ago

Do you have any examples of other vendors using the last assigned address as a default?

jarek11• 15 years ago

Congratulations! 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?

shinratdr13• 15 years ago

The 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.

sid03• 15 years ago

And yet it is exactly as dickish and disrespectful of others. Just like Apple as a whole, it seems.

jarek11• 15 years ago

You're right. I guess it's more comparable to walking up to a checkout or a cash register without looking to see if anyone is waiting in line. Great UX if you don't look around you.

dhess2• 15 years ago

When 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• 15 years ago

DHCP 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.

dhess2• 15 years ago

I 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.

brigade2• 15 years ago

The 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• 15 years ago

It 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.

simmons4• 15 years ago

It 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• 15 years ago

So, 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.

bradleyland10• 15 years ago

There 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• 15 years ago

Another 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• 15 years ago

One 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• 15 years ago

leoh• 15 years ago

Does 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-s...

smackfu2• 15 years ago

Very interesting. It sounds like they had some troubles getting this to a properly working state.

flogic• 15 years ago

Rather 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• 15 years ago

I 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• 15 years ago

The tablet is using dhcpcd, which is plenty venerable.

tintin• 15 years ago

The 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• 15 years ago

Is 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.

smackfu2• 15 years ago

I wonder if Apple has a patent on this technique.

tlg• 15 years ago

They do : patent 20090006635

ryannielsen• 15 years ago

I'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• 15 years ago

# /etc/init.d/networking restart

signa11• 15 years ago

reading 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• 15 years ago

Everybody 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• 15 years ago

Yes, 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• 15 years ago

Are 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• 15 years ago

A 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 ...

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

Related Stories