# /etc/init.d/networking restart
Rapid DHCP: Or, how do Macs get on the network so fast?
161–170 of 191 posts
Re: Rapid DHCP: Or, how do Macs get on the network so fast?
#162Earlier quoted context omitted.
> 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.
> 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.
> 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?
Re: Rapid DHCP: Or, how do Macs get on the network so fast?
#163Earlier quoted context omitted.
How can a lease be "unused" if it hasn't expired and the client that requested it never released it? Are you saying that the DHCP server pings (ICMP or ARP) each address and re-leases the ones that don't get a response?
Are you saying that the DHCP server pings (ICMP or ARP) each address and re-leases the ones that don't get a response? The DHCP will ping an address before leasing it, and if it gets a response then it will not lease that address.
I don't think this is true at our office (running a Cisco DHCP server). We get conflicts when putting a device with a static IP in the dhcp range, and I'm almost sure that they respond to ping.
Re: Rapid DHCP: Or, how do Macs get on the network so fast?
#164When 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.
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 bec…
The hostname returned from DHCP doesn't affect the computer name in Sharing.
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...
Re: Rapid DHCP: Or, how do Macs get on the network so fast?
#165reading 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...
Re: Rapid DHCP: Or, how do Macs get on the network so fast?
#166Everybody 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?
Re: Rapid DHCP: Or, how do Macs get on the network so fast?
#167> 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…
> Ok, seriously? That isn't a bug in an implementation somewhere,
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.
Re: Rapid DHCP: Or, how do Macs get on the network so fast?
#168Earlier quoted context omitted.
> 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.
> 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?
Router vendors start saving DHCP lease tables to stable storage and the issue is fixed?
Re: Rapid DHCP: Or, how do Macs get on the network so fast?
#169> 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…
This "feature" has fucked me over so many times! If the DHCP server is configured to be strict, or even a little paranoid, every now and then my macbook would just refuse to connect. I'd have to clear DHCP caches, settings and restart.
Re: Rapid DHCP: Or, how do Macs get on the network so fast?
#170Earlier quoted context omitted.
> 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.
> 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.
You're falsely attributing this behavior to your iPhone/Mac. Keep a couple of things in mind:
* 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.