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.
replies(2):
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.
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.
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.)
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.
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?
(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.)
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.
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).
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.
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.
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.
Moving to a router that allowed them to be configured with different SSIDs resolved all my issues.
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.
It's annoying. I wonder if this rapid DHCP implementation has anything to do with that.
The DHCP will ping an address before leasing it, and if it gets a response then it will not lease that address.
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.
*I am not a security expert
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...
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.
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.
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.
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?
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.
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.
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.
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.
And that was 6 years ago on a PPC iBook.
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.
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.
http://www.net.princeton.edu/announcements/ipad-iphoneos32-s...
> They want the device to work when they turn it on.
Of course people are going to like devices that allow them to cut in line if there is a little bit of space.
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?
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.
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.
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.
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.
Once the address is given out, it is the client's for the term of the lease.
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.
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.
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.
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.
The Bloom filter was an analogy. Optimize for the common case, not the rare case.
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.
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.
Better to compare galaxy vs ipad tablets, or osx vs other unix vs windows
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.
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.
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 :-)
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.
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.
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.
"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."
"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."
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.
I think there probably was something wrong with the DHCP server configuration.
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.
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.
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...
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?
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.
* 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.
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.
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.
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.
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.
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.
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.
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
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.
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?
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?