[wishlist] Use Faster dhclient3 timeout settings

[Paul Sladen]

dhcp-client is a program that requests an IP address and associated details automatically when an interface is brought up.

By default it comes with excessively long and paranoid time-outs; which can be extremely frustrating for a user who may have to wait 60seconds for a failure when a reply would have likely arrived within a small amount of time (eg. 0.5s).

I've been experimenting with the following settings on 1 laptop and a slightly different (even faster) set on another laptop.

-timeout 60;
-retry 60;
-reboot 10;
-select-timeout 1;
+timeout 15;
+retry 10;
+reboot 3;
+select-timeout 2;
 initial-interval 1;

Some additional reading of the code needs to be done to see exactly how these values are used, as there is a certain amount of randomness added.

* BRAINDUMP *

Ideally, the following should likely happen:

  Fire 3 requests are 1 second intervals
  Fire 3 requests at 2, then 2 at longer intervals.

There are three main directions that hold up acquiring a an address:

  (a) Link down / No DHCP server
  (b) Lossy link; UDP packets getting missing in one/both directions
  (c) A remote DHCP server taking more than 1 second to reply.

The latter case (c) happens rarely and only on large corporate networks or when doing something daft like DHCP'ing over a congested ISDN link. This requires less packets, but waiting longer.

The Lossy link (b) needs more attention paying; this means sending *more* packets, not waiting longer.

In the case of No DHCP server of a link down, the current 60 wait is excessive; lots of inital packets quickly show if there is a DHCP server that is going to respond.

The following may violate the spec, but would offer an approved user experience:
If an OFFER is received, it should be used immediately and ACK'ed in the background. dhcp-client can frustrating often be seen receiving OFFERs but ignoring them in favour of making further REQUESTs.

If dhcp-client fails to renew a DHCP lease (eg. because of UDP packets getting lost on a dodgy link) it should not drop the interface if it cannot contact the DHCP server. Continuing background attempts to renew the lease when the DHCP server becomes reachable again should be made.

Adding an ARP ping would detect address collisions in a similar manor to MS Windows default networking.

[Gaëtan Petit (gaetanp)]

sorry but next time please respect bug repporting rules
[whislist] in your title is uselless

Tenshu

[Kristoffer Lundén (kristoffer-lunden)]

Does this also affect timouts in the GUIfied network administration? A simple mistake there can cost tons of frustration waiting forever for a timeout, when nothing will come back. A successful connect is usually over in less than a second, waiting a minute is a bit too much for something that apparently will never happen.

[Paul Sladen (sladen)]

On Fri, 10 Feb 2006, Kristoffer Lundén wrote:
> Does this also affect timouts in the GUIfied network administration?

Yes, the Network configuration panel just calls 'ifupdown' which in turns
waits for 'DHCP' with the prescribed settings.

[Matthew Lange (matthewlange)]

This is especially prevalent when booting on a wireless laptop, either it tries the wired connection, and times out after 60 seconds, or tries the wireless, and times out after 60 seconds while "Trying to bring up the network interface".

The settings described in the original bug report work effectively on my laptop.