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.)
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.
> If you have to reboot your router frequently, you
> should replace it
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.
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.)
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.
"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."
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?
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.
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.
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'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).
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.
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.
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.
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'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.
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?
Better to compare galaxy vs ipad tablets, or osx vs other unix vs windows
It's annoying. I wonder if this rapid DHCP implementation has anything to do with that.
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.
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...
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.
I think there probably was something wrong with the DHCP server configuration.
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?
http://www.net.princeton.edu/announcements/ipad-iphoneos32-s...
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.
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.
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.
And that was 6 years ago on a PPC iBook.
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.
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.
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.
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?
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.
You might find RFC 4429 IPv6 "Optimistic Duplicate Address Detection" interesting ...