DHCP very slow and unreliable

[Traumflug]

What I expect to happen:

When booting Ubuntu, I expect the computer to get a DHCP lease and to have networking available as soon as Gnome starts up.

What happens instead:

1 - The boot hangs at the boot splash screen for some 20 to 30 seconds (already reported as https://bugs.launchpad.net/bugs/114610).

2 - After eventually finishing the boot into Gnome, no network is available (except localhost).

3 - It needs at least one

    sudo /etc/init.d/network restart

to get the network up. Ethernet network in this case. Often, issueing the above command more than once is needed.

- - -

This is obviously a regression as this misbehaviour started with one of the updates very close to 8.10's release date. I had installed 8.10 at the alpha3 stage.

I tried to boot Jaunty's Xubuntu CD and DHCP times out there as well.

DHCP works just fine if I boot this same computer into Hardy Heron or Windows.

I tried to debug the issue by catching dhcp packages with dhcpdump. Please find the logs attached. What I found is, dhcp3 reports a vastly wrong time for the validity of the lease in case it eventually gets one. The lease is meant to be valid 14400 seconds while dhcp3 reports some 6000-odd seconds.

- - -
mah@piccard:~$ lsb_release -rd
Description: Ubuntu 8.10
Release: 8.10
mah@piccard:~$ apt-cache policy dhcp3-client
dhcp3-client:
  Installiert: 3.1.1-1ubuntu2
  Kandidat: 3.1.1-1ubuntu2
  Versions-Tabelle:
 *** 3.1.1-1ubuntu2 0
        500 http://ubuntu.intergenia.de intrepid/main Packages
        100 /var/lib/dpkg/status

[Traumflug (mah-jump-ing)]

Unfortunately, after the release of Jaunty, this is still an issue. Things get worse, as some applications (e.g. Firefox, Pidgin) obviously trust some hidden notification system on the unavailability of the network. I can bring up the network as described above and ping arbitrary hosts successfully, yet Pidgin refuses to connect anyways.

A workaround for the applications is to uninstall network-manager. This way I can at least bring up the network manually - after each reboot and after each sleep/wake cycle - and get it recognized by the apps.

[Chuck Short (zulcss)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. The issue that you reported is one that should be reproducible with the live environment of the Desktop CD of the development release - Karmic Koala. It would help us greatly if you could test with it so we can work on getting it fixed in the next release of Ubuntu. You can find out more about the development release at http://www.ubuntu.com/testing/. Thanks again and we appreciate your help.

[Traumflug (mah-jump-ing)]

Well, I don't know about the Desktop CD, but I have Karmic installed on the hard disk already.

In addition to the original report I have to re-add two lines to /etc/network/interfaces:

auto eth0
iface eth0 inet dhcp

to disable nm-applet on the ethernet card. These two lines were default at the time of the original report. After adding the lines, I can proceed as described above. On average, it takes two restarts to get the network up. I never managed to get a working network with the default setup (without these entries).

[Traumflug (mah-jump-ing)]

To get some light into the issue I've recorded the DHCP conversation done by my Mac running Mac OS X 10.4.11, and of my Ubuntu box.

Please see attached files, One for the always-successful Mac, one for a failed Ubuntu try and one for a successful Ubuntu try. They are different, while the Mac sends a "request", Ubuntu sends a "discover".

[Chuck Short (zulcss)]

What kind of network card is your ubuntu box using and can you attach the dmesg output of a clean reboot?

Thanks
chuck

[Traumflug (mah-jump-ing)]

It's Intel e1000e on board of a Dell Vostro 200 (Foxconn custom MoBo).

Please find dmesg output attached. The first 25 seconds are the boot process, around second 66 I attempted to get networking as described above. BTW., The hang in the boot process vanished somewhere at 9.04 beta, as network is now started asynchonously.