Ubuntu
netcfg package

DHCP timeout with netinstall/alternative/d-i...

Bug #267656 reported by Daniel J Blueman
2
Affects Status Importance Assigned to Milestone
netcfg (Ubuntu)
Fix Released
Undecided
Unassigned
Nominated for Intrepid by Daniel J Blueman

Bug Description

Binary package hint: debian-installer

When performing a netinstall or install via alternative CD, the 15 second DHCP timeout has consistently caused problems in these cases I have experienced:
 - various tg3 laptop network adapters taking time to complete link autoneg
 - non-ISC DHCP servers (eg Microsoft DHCP server)
 - ports connected to routers with advanced functionality enabled, such as VLAN and/or STP, taking some seconds before data is allowed
 - ISP cable modem with upstream DHCP server

The standard requires a 60s timeout for compliance. In the case where DHCP isn't expected to work, the user selects manual configuration, thus in the DHCP case, DHCP is expected to work, so a 60s timeout is not unreasonable.

Revision history for this message
Daniel J Blueman (danielblueman) wrote :

Attached patch fixes the behaviour. How can we get this reviewed and considered in time for Intrepid Alpha 6?

Changed in debian-installer:
status: New → In Progress
Revision history for this message
Daniel J Blueman (danielblueman) wrote :

Reviewing related bugs, we're not able to cancel the DHCP timeout, and the timeout is configurable by passing boot parameters, however this is not always easily possible when booting from PXE and/or USB (unlike when booting from CD).

Does a 30 or 45 second timeout seem reasonable?

Revision history for this message
Colin Watson (cjwatson) wrote :

I don't think RFC2131 is anywhere near that specific. It says "reasonable period of time" corresponding to the local internetworking facilities, and suggests an algorithm which is then referenced as "if using timeout suggested in section 4.1" and other such phrases. The only hard limit is section 4.4.5, which is talking about reacquisition and so doesn't apply here.

15 seconds was always known to be a compromise, and of course you can always retry. However, I'll reluctantly bump it to 30. I don't want to push it higher than that in case there are people with analogous problems cancelling the timeout (or who just don't notice that you can cancel it and complain ...) compared with your problems retrying. Note that in our default configuration static network configuration is not offered until after DHCP fails or is cancelled.

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package netcfg - 1.44ubuntu3

---------------
netcfg (1.44ubuntu3) intrepid; urgency=low

  * Bump the DHCP timeout to 30 seconds (slightly reluctantly - I still
    advise that people use netcfg/dhcp_timeout to adjust the timeout where
    necessary and possible; LP: #267656).

 -- Colin Watson <email address hidden> Tue, 16 Sep 2008 12:13:51 +0100

Changed in netcfg:
status: In Progress → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Patches

Remote bug watches

Bug watches keep track of this bug in other bug trackers.