
Rapid DHCP: Or, how do Macs get on the network so fast? - timdoug
http://cafbit.com/entry/rapid_dhcp_or_how_do
======
saurik
_> This network recognition technique allows the Mac to very rapidly discover
if it is connected to a known network. If the network is recognized (and
presumably if the Mac knows that the DHCP lease is still active), it
immediately and presumptuously configures its IP interface with the address it
knows is good for this network._

Ok, seriously? That isn't a bug in an implementation somewhere, but in fact a
feature that Apple actually is proud of? Am I the only one who finds that if
you get a room full of people sitting around with Macs at least one person
gets their IP address stolen by someone else?

(edit: I just got downvoted, and then asked the people in the room with me,
and they seemed to agree with my perceived correlation regarding the "another
computer is using 192.1.0.1" issue... instead of just downvoting, maybe reply?
It is actually quite common that DHCP leases on a network get reset for
various reasons, and if you just jump on the network without revalidating your
lease, you are actually quite likely to just "presumptuously" steal someone
else's IP address.)

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

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

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

~~~
pyre

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

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

~~~
derleth
> 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?

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

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

------
pinko
This is a great example of Apple's detail-oriented focus on real-world user
experience, and helps explain why people prefer Macs even if they can't always
explain why. Lots of little things just work better. You (where "you" ==
myself and many others, even if not /you/ personally) are left overall with an
experience of less frustration.

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

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

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

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

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

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

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

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

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

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

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

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

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

~~~
cbs
_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.

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

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

------
hardtke
I've sat in many a meeting where the Macs "steal" all of the DHCP connections
and I'm stuck watching the speaker instead of following TweetDeck.

~~~
knowtheory
I've had my wife's macbook bump mine off the network by stealing the IP my
machine is using. Definitely an inconvenience when on skype.

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

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

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

[http://www.net.princeton.edu/announcements/ipad-
iphoneos32-s...](http://www.net.princeton.edu/announcements/ipad-
iphoneos32-stops-renewing-lease-keeps-using-IP-address.html)

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

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

------
flogic
Rather than asking why the mac is so fast, the correct question is "why the
hell is dhcpcd so slow?". There's a full second before it does anything.

~~~
vacri
I think it's apples and oranges to some degree - a macbook pro with a
venerable operating system versus a tablet with one that's still heavily in
development.

Better to compare galaxy vs ipad tablets, or osx vs other unix vs windows

~~~
krakensden
The tablet is using dhcpcd, which is plenty venerable.

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

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

~~~
pohl
_...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?

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

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

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

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

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

~~~
simmons
It is unscientific. A more comprehensive study would analyze each device in a
variety of well-defined scenarios, but in the interest of time I just took a
few captures and put a couple under the microscope. I hope I didn't come
across as trying to directly compare the tablet's ~11.8s startup on a fresh
network to the Mac's ~0.03s startup on a known network. I know that the Mac is
faster than my other devices via subjective observation, so I was mostly just
interested in comparing the differences in the packets during this process.

------
secure
So, as far as I understand, the issue pointed out here is that the Mac is
sending ARP requests with a cached source IP address (which therefore could be
already in use).

I wonder why it does that, as you can also send ARP probes originating from a
source IP address 0.0.0.0 (and only having the MAC address set). I just tried
it on linux:

arping -D -c 1 -I wlan0 172.22.36.1

The computer with 172.22.36.1 will happily send me back its MAC address.

So, is Apple doing something else here? Maybe relying on the router to not
poison its cache and not reply at all if the IP is already taken.

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

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

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

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

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

------
dhess
When coming out of sleep, my Macs often get a new computer name in the form of
a " (N)" suffix; e.g., a Mac named "vision" will come out of sleep and
mysteriously change its name (as reported in System Preferences->Sharing) to
"vision (2)", then "vision (3)" after a subsequent sleep, etc.

It's annoying. I wonder if this rapid DHCP implementation has anything to do
with that.

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

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

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

------
jrsmith1279
I've always wondered why my Mac jumps right on the network, while other
devices such as my Xbox 360 take a few seconds before the connection is there.

I'd be interested to see how the Google Chrome CR-48 handles DHCP since it
seems like it takes a bit of time before getting online and allowing me to log
in to it.

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

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

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

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

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

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

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

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

------
known
# /etc/init.d/networking restart

------
smackfu
I wonder if Apple has a patent on this technique.

~~~
tlg
They do : patent 20090006635

------
swale


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

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

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

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

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

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

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

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

~~~
jarek
Thanks for your reply.

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

~~~
bradleyland
There is nothing proprietary about this.

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

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

~~~
th0ma5
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!

~~~
__david__
Which specification does it violate?

~~~
th0ma5
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

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

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

