Hacker News new | past | comments | ask | show | jobs | submit login
Rapid DHCP: Or, how do Macs get on the network so fast? (cafbit.com)
354 points by timdoug on July 12, 2011 | hide | past | web | favorite | 180 comments

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

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.

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

Like I said, if you're uncomfortable with the trade-off, avoid Apple devices. Personally, I only see the number of devices like the iPad/iPhone increasing, and I'm relatively confident that your normal user doesn't give a damn about any of this. They want the device to work when they turn it on.

I'd also argue that any DHCP server that applies that policy of artificially limiting the IP pool by re-issuing non-expired leases is an asinine implementation.

Well, sure, but the problem is that the Apple device user doesn't suffer from the negative consequences of the non-standard action. Other users do.

Of course people are going to like devices that allow them to cut in line if there is a little bit of space.

Non-standard action? It's standardized by RFC 4436!

Not all RFCs are standards. See http://tools.ietf.org/html/rfc1796 entitled "Not all RFCs are standards" :)

> Like I said, if you're uncomfortable with the trade-off, avoid Apple devices.

Something tells me Saurik is a tad more invested at this point, it's not really as simple as "avoiding Apple devices" when you are the dev of Cydia.

I know next to nothing about iOS as it relates to Darwin, but if the DHCP stack is part of Darwin, it'll be OSS, which means someone could patch the DHCP client to not exhibit this behavior.

How many people do you think would install that patch?

* Resolves potential IP conflicts when recovering from sleep

* Adds 10s to network availability in most situations

Nobody. For the record I agree with you, I wasn't defending saurik just pointing out that your resolution was inadequate as he is overly invested at this point.

  > They want the device to work when they turn it on.
If there is a collision, then this doesn't 'just work' when the user turns it on. Just sayin'. From the user's perspective the device should never fail, in any situation, for any reason... ever. Users don't care about trade-offs because they don't want to trade anything off, they want it all, 5 minutes ago.

> If there is a collision, then this doesn't 'just work' when the user turns it on.

No, it just potentially kicks off another user. I've never been unable to acquire an IP because of this practice, I've just seen other people's wireless mysteriously give up the ghost when I connect with my iPhone or Mac. I would prefer to have the aggressive device, personally.

You're falsely attributing this behavior to your iPhone/Mac. Keep a couple of things in mind:

* If you have a valid lease, there should be no conflicting IP addresses on the network

* Even if you do have a conflicting IP address, that conflict only exists until the DHCP server issues you a new one (iOS immediately performs the DHCP request after sniffing)

IP conflicts are not voodoo magic. Once the conflicting machine gets a new IP address, everything returns to normal. The network events shown in the article show that this occurs in about 1s; between the time that the interface comes up, 0.3s, and the time the interface is active, 1.3s. If this were a full negotiation, it would take around 5s.

The key thing to remember is that this shouldn't happen at all on healthy networks. So, if anyone chooses to remain opposed to this, they're saying that waiting 10s every time you wake a portable device from sleep and want to use the network connection is a worthwhile tradeoff to accommodate DHCP servers that don't respect leases and switches that can't adequately resolve an ARP entry conflict in a timely manner.

I've said it about ten times in this discussion already, but I'll keep the ten seconds (times 15-20 sleep/wake events per day) and buy decent network equipment.

> I would prefer to have the aggressive device, personally.

So, by basic game theory, everyone implements 'asshole mode' in their devices. What happens on a technical level when every device behaves like that?

Router vendors start saving DHCP lease tables to stable storage and the issue is fixed?

> What happens on a technical level when every device behaves like that?

We start putting battery backup in routers so they won't drop their DHCP tables? This isn't asshole mode, it's "assume the network is functioning properly and hasn't been reset" mode. In the world of portable devices, it's important to look at where we waste time and compensating for errors is a frequent culprit.

This implementation will always work for the Apple device that's connecting.

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

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


> 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

   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.

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?

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

Once again, this is almost always a router misconfiguration problem. If you don't want this to happen configure your router correctly. Apple isn't to blame for other people's incompetence.

Plus, this seems to produce tangibly better results in the majority of cases. It perfectly fits Apple's style of optimizing for the common use case, even if the rarer gets worse.

I ask again: do you have any evidence that this is a problem in practice? I feel like this is something we would have heard about before, via some outraged blog post followed by Apple discussion board postings that get deleted by Apple.

How often do computers send out ARP requests to check on the uniqueness of their IP address? If it's less often than once per second or so (and I really hope it is), I could see how you could get away with having two devices with the same IP for a second here or there with no one the wiser.

Where I used to work actually had lots of problems with this. I vaguely recall it coming to a head a while after the iPhone 3G came out and/or about the time various staff members got macs, but I could be wrong. Anyway, it sprang immediately to mind when reading this thread.

It doesn't sound like it would be a big deal, but Windows (and Mac OS X, I've since discovered, mid-7 minute `svn commit'...) just drop the connection if there's an IP conflict. That's actually quite annoying, at the very least. You have to resubmit commits, restart getting latests, your FTP craps out halfway through, file copies go wrong, you lose your remote desktop connection, the code finishes compiling before your web page loads, etc. With any luck, you won't lose any work.

If you don't run your code on the same computer you write it on, you might be less lucky. The debugger craps out and you lose your place, or the file server goes wrong and your code gets an error and stops or whatever while you were in the middle of waiting for it to get somewhere specific. And if you use any home-written tools, they're probably going to be even less resistant to network failures of this nature than the stuff you paid for - which doesn't do a fantastic job in the first place. It all adds up.

Fortunately for me, I wasn't using Remote Desktop all that much, and the device I was working with attached via USB. And I didn't lose any work when the source control just stopped mid-operation. And I could just put headphones on, and block out my colleagues' cries of pain. So maybe that's OK then, and it's no big deal?

I'd like to be able to say what the eventual solution to the problem was, but I don't remember.

...do you have any evidence that this is a problem in practice?

When iPhone OS first came out, there was a bit of an uproar on many university campus networks that they were seriously screwing up the behavior of DHCP on networks with a very large number of transient clients.

I don't see how this has anything to do with what Apple is doing. If you reboot the router and it starts issuing addresses from the beginning of its range, it is likely to issue addresses that conflict with the existing leases on the non-Apple computers.

If a DHCP server gives out an address, and then gives it out again before the least has expired or the first client has relinquished it, it is going to cause a conflict no matter who made the clients.

Before assigning an address to a client, a DHCP server will ping the address first to make certain someone isn't already using it (this behavior is even documented in the manual page of ISC dhcpd); therefore, it is only clients that join the network and assume their old lease is still valid (sniping it from one of the new clients that accidentally ended up with the IP address that used to be leased) that will cause this behavior.

If you're having to reboot the router more often than DHCP leases expire, you may want to look into a new router.

Ah yes, the Apple solution: just buy a new one. Because that's always an option for everyone, on every network they use.

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.

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.

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

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.

How can a lease be "unused" if it hasn't expired and the client that requested it never released it? Are you saying that the DHCP server pings (ICMP or ARP) each address and re-leases the ones that don't get a response?

Well actually the result of "running out" of addresses is undefined and up to the individual hardware manufacturer, so theoretically they could do whatever they want. A high-traffic WAP might want to simply boot the oldest lease if they can't assign more than a certain number of addresses.

Keep in mind if aa client wants an IP, it is supposed to do DHCP discovery every time it connects to the network, even if it's lease isn't up. See http://en.wikipedia.org/wiki/Dynamic_Host_Configuration_Prot...

Are you saying that the DHCP server pings (ICMP or ARP) each address and re-leases the ones that don't get a response?

The DHCP will ping an address before leasing it, and if it gets a response then it will not lease that address.

I don't think this is true at our office (running a Cisco DHCP server). We get conflicts when putting a device with a static IP in the dhcp range, and I'm almost sure that they respond to ping.

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.

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.

It says "SHOULD" not "MUST", so the client can assume the server will keep its promises, it's just not recommended.

    "SHOULD   This word, or the adjective "RECOMMENDED", mean that there
    may exist valid reasons in particular circumstances to ignore a
    particular item, but the full implications must be understood and
    carefully weighed before choosing a different course."

Yes, I am aware the RFC used should and not must, but nevertheless their recommendation is clear.

And of course if that item is to be ignored "the full implications must be understood and carefully weighed before choosing a different course." Here the implications are that the device may cause other devices to drop their connections, which is a pretty severe implication, imo.

Note that it doesn't say that such verification has to be done prior to recommencing use of the leased address - just that it should be done. Arguably then the described implementation follows the letter of the recommendation. Your witness, counsel.

The small print in paragraph 2 explicitly allows reusing the previous address until the lease expires.

Paragraph 2 only allows this "If a client ... is unable to contact a local DHCP server." Note that in the present example, the client started using its old address before even trying to contact the DHCP server and eventually was able to contact the DHCP server.

This could alternately be described as "a client used its old address until it could contact the DHCP server".

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?

As far as I can see from the RFC and from Googling, there is no mechanism for a DHCP server to take back an IP address before the lease has expired, unless the client explicitly initiates relinquishing the lease.

Once the address is given out, it is the client's for the term of the lease.

Given that most routers are managing a class C network, and even then have allocated the first 100 addresses for internal use (starting the DHCP pool at .100), this would mean that it would be trivial to DoS any DHCP server in seconds by simply cycling MAC addresses and leasing all of their addresses.

Obviously, this is not realistic, and no one would ever implement a DHCP server that allowed this to happen: it is going to keep track of some fixed number of leases (probably/hopefully as many IP addresses as it is managing) and, when it runs out, it will be forced to reclaim an address from another user.

If anything, the fact that such a mechanism is not specified is simply going to make this "worse", as the specific implementation of how and when the reclamation happens is going to end up as "whatever makes sense to the guy working on that specific DHCP server implementation", and may constitute seemingly random behavior.

You don't even need to cycle MAC addresses; just send DHCPDECLINE messages for any address the server gives. DHCP requires that any address that elicits that response from a client MUST be marked unavailable, and provides no provision for it ever becoming available again.

Ignoring the client is the only automatic mechanism DHCP provides for countering this.

You have to remember that DHCP was written back when it was assumed that a competent systems administrator managed the server and could manually respond to running out of available addresses (which was considered a likely sign of misconfiguration), and didn't attempt to specify what to do in the case where it happens.

Not giving out an address and notifying the systems administrator is what the DHCP spec recommends in this case. In fact, section 2.2 claims "The allocation mechanism (the collection of DHCP servers) guarantees not to reallocate that address within the requested time" so any reclamation of IP address on the part of the server is technically in violation of RFC 2131.

I'm confused... are you therefore suggesting that this is how people like Linksys should handle this problem? I fully realize that the spec was written in another time, but I don't think tzs did: he is actually citing the spec as a reason why these leases should stay around. When you go to a coffee shop, the router does not and probably should not play a chime when it has run out of DHCP leases, causing the barista to go around the room finding laptops that have been setup incorrectly... the router should, and almost certainly does, just "figure something out", likely by reclaiming addresses.

There are sensible options available other than violating the leases.

For example, for a highly-used access point, it would make sense to give out only very short leases - say, 10 minutes. That'd support a churn of 25 clients per minute if you're giving out addresses from a /24 (and there's no reason why you couldn't use a smaller netmask, down to /8). It'd also be sensible to ignore a single MAC address once it had more than a handful of outstanding leases.

It doesn't help with a malicious client - but then neither does breaking leases. The malicious client can cause enough address flapping to make the network completely unuseable. You really can't protect a wifi network against a malicious client trying to DoS it - there's a myriad ways to do that apart from DHCP.

It's trivial to DoS any layer 2 network. This is trivial netsec.

There is a fundamental difference between sitting on the network flooding it (an activity that requires you to actually be connected to the network, although this could of course be a small and difficult to detect device), and sending 256 packets and walking away, content in the knowledge that for the next 24 hours no one will be able to use the network because you own all of the DHCP leases. "This is trivial netsec."

I never said flood, I said DoS. I don't think this is on-topic so I'm not going to go in to detail but you should Google ARP spoofing. These tactics are quite trivial and I'm teaching undergrads to do it next year.

I was, and continue to be, under the impression that this kind of attack is not possible when an access point has node isolation (a very common feature that even my MiFi router supports, despite it often being turned off in home and even office environments), yet the aforementioned protocol-level DHCP DoS I described would work on any device that implemented the DHCP specification. I therefore fail to see how ARP spoofing is relevant. Remember: we are discussing whether it is a fair belief that any reasonable implementation of DHCP would have implemented the spec as stated.

That's where I'm at with this. What Jarek describes can happen, but that's a failure case, not the normal-operation case. And as portrayed in the article, the engineers at Apple have accounted for the failure case, so all's well. They simply have made the very reasonable assumption that the DHCP server will normally be operational, not in a crisis state, and that it will honor its contracts as specified in the RFC. How hard is this?

There is that principle of "conservative in what you send, liberal in what you accept" on which UNIX and half of the internet was built.

I think your description is correct.

The problem is the impact of the false "ip conflict" that is caused by this optimization. A device that detects an ip conflict should not have to guess whether it is an ip conflict caused by an optimization on another device. As pointed out in other comments an ip conflict can cause other systems to drop existing connections.

No one likes ip conflict notifications, or to have their connections dropped. Play nice. That's all.

The problem is that the DHCP server re-issued a valid lease to a second computer. Surely this is an issue with the DHCP server not playing nice, rather than Apple?

Do you feel there is a better, more tolerant, and less error prone course of action the DHCP server could take if it runs out of leases?

If we are able to modify the DHCP server to do something sensible, why not modify default router settings to issue /16 addresses instead of /24? Or even 10/8? There's plenty of RFC1918 space to not run out.

NAT state tables won't have to stretch that far as they can time out unused connections just like they do already.

Would there be any unintended side-effects with doing this?

If you don't like the NAT, go ahead and issue IPv6 :-)

Not really. The DHCP server may have many valid reasons for reissuing a technically valid lease, such as it being restarted and losing its table of valid leases. As I pointed out in a response above, the DHCP protocol makes it clear that devices should re-verify their addresses after waking up.

This optimization does not cause IP address conflicts. If a DHCP server is not correctly keeping track of lease times and ensuring that addresses already assigned are not reused while the client still has a valid lease, you can get IP conflicts regardless of whether or not their are any Apple devices on the network.

Please name one or more DHCP server which will knowingly violate a lease it has granted, via "kill the oldest" or any other means.

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.

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.

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.

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

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.

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

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

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.

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.

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

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.

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

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

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.

What does a bloom filter have to do with this? Generally when someone uses a probabilistic data structure, they ensure its used in a manner that becomes consistent (e.g., as a caching layer). If by not following the dhcp spec, macs are breaking other peoples' connectivity, there's no recovery save them disabling/reenabling the network for them manually.

First, they don't break the DHCP spec -- everything they do is completely within spec. Second, ARP resolution doesn't require any manual resolution. Third, show me that the OS X ARP system is breaking other peoples' connectivity.

The Bloom filter was an analogy. Optimize for the common case, not the rare case.

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.

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.

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.

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.

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

There are cheapo routers that do 5GHz?

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 ;)

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.

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.

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.

I am pretty sure that request is supposed to be broadcast across the entire subnet.

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.

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.

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

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.

the Mac is not sending that out in the request.

I could be wrong about this, as I haven't analyzed actual arp requests in ages, but from the article it appears the arp requests are unicast to the (at least in the example) cached MAC for the gateway.

Ah, after a closer look at the original article, I see that now. Curious that Apple would choose to unicast those requests.

It does this to verify that the DHCP server has the same MAC address as the one that it remembers. If the server that it remembers isn't present on the current network, the unicast packet should be ignored.

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.

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.

Sorry, 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

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.

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.

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.

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.

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.


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

On 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)

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.

Does anyone remember this? Princeton Information Technology: "iPhone OS 3.2 on iPad Stops Renewing DHCP Lease, Keeps Using IP Address"


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

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.

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.

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?

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

The tablet is using dhcpcd, which is plenty venerable.

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.

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.

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

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.

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.

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.

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

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.

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.

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 (and only having the MAC address set). I just tried it on linux:

arping -D -c 1 -I wlan0

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

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.

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

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.

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.

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

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.

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.

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.

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

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.

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.

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.

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.

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.

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

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

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.

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?

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.

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

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

# /etc/init.d/networking restart

I wonder if Apple has a patent on this technique.

They do : patent 20090006635

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?

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.

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.

That's as bad as your exit lane analogy. If you want a checkout line analogy that actually somewhat fits the situation, here is one.

You pay for a cup of coffee at Starbucks, standing in line until it was your turn to pay. Then you pay and go sat down and drank some of it, while working on your laptop. You get caught up reading HN, and don't take a sip from your coffee for five minutes. You then want to take a sip.

What Apple is doing is like resuming finishing the coffee without going back to the checkout and trying to pay for it again.

Well, no, that's a bit inaccurate as well, if we want to have nice analogies, let's go with something like this:

You pay for a cup of coffee at a coffee shop. Nominally you get your own cup, and there isn't a limit on the amount of time you can keep it. However, the store occasionally and unpredictably runs out of cups. Also, at the start of a new day a new barista might occasionally come in, and they might not know which cups should still be considered owned. Because of this, everyone else has for years observed a simple procedure where you look to make sure it's your coffee you're about to sip. It's polite and it's just — what's the phrase — not a big deal. You get your coffee, leave for two days, come back and take a drink from the cup that looks like the one you got previously without as much as a glance inside or around.

Except I drink hundreds and hundreds of cups of coffee a day. When it takes 10 seconds every time to determine who's coffee it is, we need to come up with a new solution.

Yeah this analogy blows as well. What it comes down to is old world technology spends a ton of time on error correction like this and it's an easy place to increase efficiency & speed for portable devices. It's going to keep happening, get used to it.

Except it doesn't take 10 seconds. The time between the Galaxy Tab's proper DHCP discover and DHCP ACK was 0.653 seconds. You might notice a difference between that and the Mac's 0.031 seconds to DHCP-free link up if you blink fast.

This conversation makes me want to block Apple devices from any and all devices I control. Because hey, such anti-social network behaviour is going to keep happening. Because it's not a big deal. Because you're worth it. Good thing the network layer doesn't support such, uh, experience-enhacing features.

> Except it doesn't take 10 seconds. The time between the Galaxy Tab's proper DHCP discover and DHCP ACK was 0.653 seconds. You might notice a difference between that and the Mac's 0.031 seconds to DHCP-free link up if you blink fast.

I unlock my phone and launch MobileSafari in less than a second, so it matters.

> This conversation makes me want to block Apple devices from any and all devices I control.

So do it then. If it actually enhances your experience, why compromise for users that don't matter to you? That's my point. You don't need to enforce network neutrality on your own AP.

> Because hey, such anti-social network behaviour is going to keep happening.

As long as router manufacturers keep being cheap and expiring DHCP leases after a reset, yes it will.

> Because it's not a big deal. Because you're worth it.

Damn straight.

> Good thing the network layer doesn't support such, uh, experience-enhacing features.

True, they should work on that. While their at it, add the ability to save DHCP tables before a reset and solve the actual problem here.

Even for new network discovery, 10 seconds is unacceptable on a portable device. Reconnects should be as quick as possible, no exceptions.

Sorry if you are offended that companies are actually working on improving this instead of insisting that it's good enough as it is.

Thanks for your reply.

It's really not. There is no real world comparable act, frankly. It is what it is, and what it is is not a big deal.

I cannot emphasize enough how much I disagree with the idea that potentially inconveniencing other network users for a small gain of your own is not a big deal.

Good for you. It's still not a big deal and you can't "outrage" that away.

It's not a small gain, for the record. And the only users you are inconveniencing are ones that are malfunctioning. If everything is working correctly and the AP hasn't been reset, this causes no inconvenience to anyone and results in a clear direct benefit for the user.

You figure a community of developers would possibly give a shit about what matters to the UX, I guess not. You do know that the "U" stands for user, right?

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

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

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

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

You're a dick for buying products that actively negatively affect other users and that would lead to chaos if everyone bought them, yes.

It would lead to chaos if every device retained the IP it used on that AP previously? Yeah that sounds like hell, imagine the horror.

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

There is nothing proprietary about this.

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

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

Except 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!

Which specification does it violate?

rfc 2131? seems to say the client can ask for an unlimited lease, but the server can specify a finite one. this article seems to be saying that this thing will use the last one leased no matter how long it's been off the network

The DHCP client acts as expected. The behavior observed by the post author occurs before DHCP negotiation executes. I know this seems like a technicality, but it's the truth. The sniffing and assumed use of an IP address occurs outside the DHCP request/response cycle. It's used ahead of time, and discarded if the DHCP 'request' request is denied.

The only people bent about this are people who have any idea what's going on behind the scenes. In the rare cases where this is a problem, the issue is quickly resolved. If this were a "real" problem, we'd have seen a lot more issues by now. The Apple discussion boards would be lit up with complaints. They're not. This is a non-issue. Only pedants are stuck on the fact that there's no RFC for it.

And as several people have pointed out to me, it looks like there is indeed an RFC for it: RFC 4436, Detecting Network Attachment in IPv4 (DNAv4).

hrmmm! good point, i assume too much, and i guess i assumed in the cadence of 802.11 whatever, dhcp comes next because it always does, but it never has to! and apparently not here for a moment. thanks for coming back to post this.

Registration is open for Startup School 2019. Classes start July 22nd.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact