Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rapid DHCP: Or, how do Macs get on the network so fast?

cafbit.com

Post reply on HN
Print view View original

91–100 of 191 posts

Re: Rapid DHCP: Or, how do Macs get on the network so fast?

#91

Post by jrockway »

msbarnett wrote: post #45
troels wrote: post #14

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.

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.

There are cheapo routers that do 5GHz?

Re: Rapid DHCP: Or, how do Macs get on the network so fast?

#92

Post by shinratdr »

jarek wrote: post #46

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.

Re: Rapid DHCP: Or, how do Macs get on the network so fast?

#93

Post by to3m »

kelnos wrote: post #57
saurik wrote: post #20

Earlier quoted context omitted.

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 envir…

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 y…

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.

Re: Rapid DHCP: Or, how do Macs get on the network so fast?

#94

Post by sid0 »

shinratdr wrote: post #92
jarek wrote: post #46

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.

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

Re: Rapid DHCP: Or, how do Macs get on the network so fast?

#95

Post by tzs »

jarek wrote: post #85
sedev wrote: post #82

Earlier quoted context omitted.

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…

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…

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.

Re: Rapid DHCP: Or, how do Macs get on the network so fast?

#96

Post by deskamess »

jarek wrote: post #85
sedev wrote: post #82

Earlier quoted context omitted.

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…

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…

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.

Re: Rapid DHCP: Or, how do Macs get on the network so fast?

#97

Post by nitrogen »

kelnos wrote: post #57
saurik wrote: post #20

Earlier quoted context omitted.

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 envir…

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 y…

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

Re: Rapid DHCP: Or, how do Macs get on the network so fast?

#98

Post by saurik »

tzs wrote: post #95
jarek wrote: post #85

Earlier quoted context omitted.

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…

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.

Re: Rapid DHCP: Or, how do Macs get on the network so fast?

#99

Post by 5hoom »

troels wrote: post #14

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.

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

Re: Rapid DHCP: Or, how do Macs get on the network so fast?

#100

Post by axiak »

Locke1689 wrote: post #84
kcbanner wrote: post #34

Earlier quoted context omitted.

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.
Post reply on HN