<i>> 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.</i><p>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?<p>(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.)
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.<p>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.
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>There already exists a minimal DHCP client implementation in the Linux kernel, but it lacks certain features such as configuring the DNS nameservers.</i><p>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?<p>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.<p>This would save the time it takes to initiate dhclient to then perform the initial IP address check + request.<p>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.
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.
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"<p><a href="http://www.net.princeton.edu/announcements/ipad-iphoneos32-stops-renewing-lease-keeps-using-IP-address.html" rel="nofollow">http://www.net.princeton.edu/announcements/ipad-iphoneos32-s...</a>
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.<p>And that was 6 years ago on a PPC iBook.
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.<p>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.<p>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.<p>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.<p>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.
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.
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.
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).<p>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:<p>arping -D -c 1 -I wlan0 172.22.36.1<p>The computer with 172.22.36.1 will happily send me back its MAC address.<p>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.
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).
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.<p>It's annoying. I wonder if this rapid DHCP implementation has anything to do with that.
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.<p>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'.<p>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.<p>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.
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.<p>Am I right?<p>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).<p>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.<p>Are the problems Apple devices create really worth saving 0.7 - 0.03s?<p>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?<p>I do no use any Apple operating systems, but I have <i>never</i> had an issue with WIFI connection and address assignment times on any platform that I have used with regularity.<p>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 <i>thousand milliseconds</i>.<p>You might find RFC 4429 IPv6 "Optimistic Duplicate Address Detection" interesting ...
reading the <i>title</i> 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...
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?