Sometimes when I write DHCP clients I choose the metric as "fastest", then just choose the first answer and don't wait for any more. And it takes on average a few milliseconds to get a lease.
Sometimes when I write DHCP clients I choose the metric as "fastest", then just choose the first answer and don't wait for any more. And it takes on average a few milliseconds to get a lease.
We built a portable device that starts a DHCP client and tries to get a lease on an Ethernet plug event, and if no lease is acquired after a certain amount of time, the device assumes it has been plugged directly to a PC (or an "ad-hoc", isolated network with a switch and no router) and will kill the client and start a DHCP server itself, so you can access the device's webserver directly. I wasn't onsite, but the solution was simple - we just increased the timeout to wait for a lease before starting the server.
When the port goes active (layer 2 link) the switch inspects but doesn't forward packets to try and ensure you've not just added a loop into your ethernet network. After a minute or so, if everything looks normal, the switch then starts letting the device talk to the rest of the network.
If you don't know about it then this can be annoying at best as you seem to have a layer2 link but DHCP can seem to take an age to start working :)
Except that packets don't really get dropped for wire errors at all anymore. Not unless the bandwidth is oversubscribed and there's a collision (really a buffer overflow on a router).