[wishlist] Use Faster dhclient3 timeout settings
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
dhcp3 (Ubuntu) |
New
|
Wishlist
|
Unassigned |
Bug Description
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.
sorry but next time please respect bug repporting rules
[whislist] in your title is uselless
Tenshu