unexplained failure to obtain DHCP address

[Seth Kinast]

I did an upgrade via aptitude on my Dell Inspiron 600m, Broadcom gigabit
Ethernet and Broadcom wireless chipset. The dhcp3-client and -common packages
were upgraded, and upon the next reboot I had lost all my network interfaces.
`ifconfig' didn't show anything but "lo" as even existing. Trying to sudo ifup
eth0 or wlan0 resulted in things like:

SIOCSIFADDR: Permission denied
SIOCSIFFLAGS: Permission denied
SIOCSIFFLAGS: Permission denied
...
receive_packet failed on eth0: Network is down
...
send_packet: Network is down

for both interfaces. I went to another computer and downloaded the
3.0.1-1ubuntu4_i386 -client and -common debs, installed them, and all is well again.

[Daniel Myall (daniel-zeno)]

Can confirm that this wasn't an isolated occurance - This also happened on my
Dell Inspiron 6000 after an apt-get upgrade. Downgrading to 3.0.1 solved the
problem.

[Mikkel Kamstrup Erlandsen (kamstrup)]

I have a very similar experience on my Breezy box. I guess it's the same problem
underneath so I'll just follow up here. Note that my Hoary installation was
working fine all the way so this was probably not ISP/router related.

After an upgrade a week or so ago my network stopped working. More precisely my
eth0 interface did not come up. It didn't show up when I ran "ifconfig",
although it showed up with a "ifconfig -a".

Poking around I tried "sudo ifup --verbose eth0", but it just stalled with no
output what so ever. Suddenly after a few days it started working again. I don't
think I really did anything to make this happen... I did a dist-upgrade and the
network failed again. From the forums somebody pointed me to "dhclient", and
"sudo dhclient" brings up my network.

As it is now, I have to run "sudo dhclient" after each boot to get my network
running.

PS: The network-admin UI does not seem to be able to handle this problem.

[Mikkel Kamstrup Erlandsen (kamstrup)]

As an added bonus to doing "sudo dhclient" after each boot, it seems that it
renders my machine unable to reboot/shutdown properly. When I log out of gnome,
it just stalls. I can move the mouse but I am not able to interact with
anything. Doing ctrl-alt-delete kills X alright but does not bring gdm back up.
I have to "sudo halt" from a console to turn of my box.

[Mikkel Kamstrup Erlandsen (kamstrup)]

Following up on my last comment.

If I "sudo dhclient" in a terminal _before_ logging in to gnome, I am not able
to log into gnome at all! I can log in with fluxbox still though (and networking
works). If I try to launch a gtk application from this fluxbox session the gtk
application just stalls with no output.
If I try to launch gnome-session from within a flux-box session I get this:

Beginning session setup...

(gnome-session:6947): Gdk-WARNING **: locale not supported by Xlib

(gnome-session:6947): Gdk-WARNING **: cannot set locale modifiers
_IceTransTransNoListen: unable to find transport: tcp
_IceTransmkdir: ERROR: euid != 0,directory /dev/X will not be created.
_IceTransmkdir: ERROR: Cannot create /dev/X
_IceTransPTSOpenServer: mkdir(/dev/X) failed, errno = 13
_IceTransOpen: transport open failed for pts/bitsplitter:
_IceTransMakeAllCOTSServerListeners: failed to open listener for pts
_IceTransISCOpenServer: Protocol is not supported by a ISC connection
_IceTransOpen: transport open failed for isc/bitsplitter:
_IceTransMakeAllCOTSServerListeners: failed to open listener for isc
_IceTransSCOOpenServer: Protocol is not supported by a SCO connection
_IceTransOpen: transport open failed for sco/bitsplitter:
_IceTransMakeAllCOTSServerListeners: failed to open listener for sco
SESSION_MANAGER=unix/bitsplitter:/tmp/.ICE-unix/6947

[Matt Zimmerman (mdz)]

(In reply to comment #3)
> As an added bonus to doing "sudo dhclient" after each boot, it seems that it
> renders my machine unable to reboot/shutdown properly. When I log out of gnome,
> it just stalls. I can move the mouse but I am not able to interact with
> anything. Doing ctrl-alt-delete kills X alright but does not bring gdm back up.
> I have to "sudo halt" from a console to turn of my box.

Don't run "sudo dhclient"; that doesn't do what you want (see
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=208605). You probably meant to
run "sudo dhclient eth0" or "sudo dhclient wlan0", but that's also unnecessary.
 Instead, use the network configuration tool
(System->Administration->Networking) to configure your network interfaces.

Is anyone still having the original problem on an up-to-date Breezy system?

[Mikkel Kamstrup Erlandsen (kamstrup)]

I was an angstrom from submitting a long explanation on how network-admin
stalled on me, but decided to check if anything was updated in the repos during
the last hours or so... Lo and behold! Now my network is back up running like it
should! - This is not the first time that it magically appears, only to
disappear after my next dist-upgrade, so I'll postpone my huge network-is-back
party a few upgrades...

Cheers!

PS: Matt, you where right "sudo dhclient eth0" allowed me to reboot nicely once
again, thanks (hope I wont need it again)!

[Mikkel Kamstrup Erlandsen (kamstrup)]

My hunch was correct. The network is failing again. First I tried reinstalling
dhcp3-{client,common} and it worked on the next boot, but did not on the following.

When I try to change anything through network-admin, na just stalls with a busy
cursor. This be trying to deactivate eth0 or disable it.

The general rule is something like this: Network comes up following upgrades of
core system packages (kernel, dhcp3, bootscripts), but only for the first boot
after the upgrade...

If I should just forget about it and reinstall Colony 3 (or wait for C4
depending), or I/we should sort things out in a "proper" way, just say so.

> Is anyone still having the original problem on an up-to-date Breezy system?

That would be yes :-)

[Scott James Remnant (Canonical) (canonical-scott)]

Mikkel: could you attach your /etc/network/interfaces file, please.

[Mikkel Kamstrup Erlandsen (kamstrup)]

Created an attachment (id=3486)
/etc/network/interfaces

Ofcourse. Here you are.

[Scott James Remnant (Canonical) (canonical-scott)]

Mikkel: you say that your network does not come up on boot, yes?

If it doesn't, what happens if you do "sudo dhclient eth0" in a
console/terminal? (paste the output here)

[Mikkel Kamstrup Erlandsen (kamstrup)]

> Mikkel: you say that your network does not come up on boot, yes?
Correct. No network.

> If it doesn't, what happens if you do "sudo dhclient eth0" in a
> console/terminal? (paste the output here)

Your will is my command:

mikkel@bitsplitter:~$ ping daimi.au.dk
ping: unknown host daimi.au.dk
mikkel@bitsplitter:~$ sudo dhclient eth0
Password:
Internet Systems Consortium DHCP Client V3.0.2
Copyright 2004 Internet Systems Consortium.
All rights reserved.
For info, please visit http://www.isc.org/products/DHCP

sit0: unknown hardware address type 776
sit0: unknown hardware address type 776
Listening on LPF/eth0/00:0b:6a:12:81:f8
Sending on LPF/eth0/00:0b:6a:12:81:f8
Sending on Socket/fallback
DHCPREQUEST on eth0 to 255.255.255.255 port 67
DHCPACK from 10.0.0.1
bound to 10.0.0.3 -- renewal in 102370 seconds.
mikkel@bitsplitter:~$ ping daimi.au.dk
PING daimi.au.dk (130.225.16.1) 56(84) bytes of data.
64 bytes from daimi.au.dk (130.225.16.1): icmp_seq=1 ttl=54 time=27.3 ms

--- daimi.au.dk ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 27.313/27.313/27.313/0.000 ms
mikkel@bitsplitter:~$

[Mikkel Kamstrup Erlandsen (kamstrup)]

 -- so yes, after doing "sudo dhclient eth0" in an xterm, my network is
functioning perfectly.

Cheers

[Scott James Remnant (Canonical) (canonical-scott)]

Could you attach the output of the following for me:

  ls -l /sys/class/net/eth0
  udevinfo -a -p /class/net/eth0

[Mikkel Kamstrup Erlandsen (kamstrup)]

Created an attachment (id=3492)
Output of "ls -l /sys/class/net/eth0" and "udevinfo -a -p /class/net/eth0" on a
WORKING configuration.

There was an update of dhcp3-{client,base} today, and it seems to be working
again now. -- Atleast for two reboots, I'll test some more though. Request
attached.

[Mikkel Kamstrup Erlandsen (kamstrup)]

Created an attachment (id=3493)
The output from a session where the network did NOT work.

After shutting down the computer and waiting ~10 min. my network did not come
up on the following boot. Output of all previously requested commands attached.

[Scott James Remnant (Canonical) (canonical-scott)]

Could you attach your syslog from that boot as well.

And your /etc/modules file.

Thanks.

[Scott James Remnant (Canonical) (canonical-scott)]

Also could you do:

dpkg -l hotplug udev initramfs-tools 'linux-image-*' > versions.txt

And attach versions.txt

[Mikkel Kamstrup Erlandsen (kamstrup)]

Created an attachment (id=3496)
/etc/modules

Catch! I could also just send you the output of "cat `find /etc/*`" :-D

[Mikkel Kamstrup Erlandsen (kamstrup)]

Created an attachment (id=3497)
/etc/modules of BREEZY this time :-)

The /etc/modules in my last post was from Hoary. Sorry.

[Mikkel Kamstrup Erlandsen (kamstrup)]

Created an attachment (id=3498)
Output of "dpkg -l hotplug udev initramfs-tools 'linux-image-*' > versions.txt"

[Mikkel Kamstrup Erlandsen (kamstrup)]

mikkel@bitsplitter:~$ uname -r
2.6.12-8-386
mikkel@bitsplitter:~$

[Scott James Remnant (Canonical) (canonical-scott)]

Hmmm... it just looks like your ethernet card isn't getting plugged at boot-time
-- could you attach /var/log/syslog

[Mikkel Kamstrup Erlandsen (kamstrup)]

Hmmm... It worked fine for a week or so after installing Colony 3. Then suddenly
after a dist-upgrade it started behaving like this.

[Mikkel Kamstrup Erlandsen (kamstrup)]

Created an attachment (id=3500)
/var/log/syslog

[Mikkel Kamstrup Erlandsen (kamstrup)]

Well my network has "survived" three dist-upgrades and boat-loads of
reboots/power-offs now, so I guess this is fixed! Yeepie!

Cheers!

[Scott James Remnant (Canonical) (canonical-scott)]

Argh, I hate it when bugs spontaneously fix themselves ... I'm going to live
this open for a week in case it appears again.

[Mikkel Kamstrup Erlandsen (kamstrup)]

Your fears where justified... My network is back to same non-functional state. :´-S

[Scott James Remnant (Canonical) (canonical-scott)]

Can you confirm that after a boot where your network is non-functional, that
"ifconfig -a" does _not_ show an eth0 device?

[Mikkel Kamstrup Erlandsen (kamstrup)]

Created an attachment (id=3594)
Output of terminal session without network running i'fconfig -a'

Attached is a small xterm session where I 'ifconfig -a' without network and
'ifconfig -a' again after I enable it.

[Scott James Remnant (Canonical) (canonical-scott)]

*** Bug 20857 has been marked as a duplicate of this bug. ***

[Scott James Remnant (Canonical) (canonical-scott)]

Yeah, could you tar up your etc and attach it here ... there's a few scripts I
want to take a look at and make sure they're all ok.

[Mikkel Kamstrup Erlandsen (kamstrup)]

You mean the output of "sudo tar cjvf etc-breezy-2005-09-08.tar.bz2 /etc"? It's
3.3MBs... Not really sure how this looks from a security POV but I'll do it if
that's what you meant.

[Scott James Remnant (Canonical) (canonical-scott)]

If you like, you can e-mail it to me privately.

<email address hidden>

you may encrypt it with GPG key C978C8AE if you wish.

[Wouter Stomp (wouterstomp-deactivatedaccount)]

I am experiencing exactly the same problems, only having internet access after
doing a 'sudo dhclient'. Have had the problem with hoary and now also with an
uptodate breezy (doesn't matter if I configure my ip address as static or dhcp).

What is kind of strange is that I can access my router's page by its ip address.
And most times releasing and renewing the network connection on the routers page
also fixes the problem.

Somehow long ago I also fixed it permanently on my hoary install after a lot of
messing around with dhcp clients and config files.

Will post more info (and see if it is the exact same problem or if I will have
to open another bug) when I am back at my own pc on monday.

[Wouter Stomp (wouterstomp-deactivatedaccount)]

I am getting different error messages, so it seems to be a different bug. Opened
one at http://bugzilla.ubuntu.com/show_bug.cgi?id=10174

[Emmanuel Rodriguez (potyl)]

(In reply to comment #8)
> Btw, you should _never_ run dhclient3 with no arguments! If it fails, do
> "dhclient eth0" ... it may be that this has corrupted the dhclient state.
>
> Try that the next time it fails, and see if that cures the problem.

Running 'dhclient3 eth0' didn't solved the problem.
Please take a look at my results here (I sent the comments to the wrong bug):
http://bugzilla.ubuntu.com/show_bug.cgi?id=14625#c11

[Scott James Remnant (Canonical) (canonical-scott)]

*** Bug 21151 has been marked as a duplicate of this bug. ***

[Scott James Remnant (Canonical) (canonical-scott)]

A status update for those playing along at home...

So far this bug seems to be a general failure of DHCP to obtain an IP address
during boot; the reason for this is unknown. There doesn't seem to be any
common hardware at fault here and I do not believe it to be a udev/hotplug
problem as the device is plugged and dhclient run.

I can't see any noteworthy changes between 3.0.1 and 3.0.2 or 3.0.2 and 3.0.3
that could fix this; if there's anyone still having problems, could they try:

1) downgrading to dhcp3-client_3.0.1-1ubuntu4 from
http://archive.ubuntu.com/ubuntu/pool/main/d/dhcp3
2) upgrading to dhcp3-client_3.0.3-3 from
http://ftp.debian.org/debian/pool/main/d/dhcp3

And find out whether one, or both, of these fixes the problem. Make sure to
test a few reboots with each one to make sure it's not a fluke.

[Mikkel Kamstrup Erlandsen (kamstrup)]

Haven't tried the packages just yet, but I had a thought... I read somewhere
that the LTSP goal needed changes to dhcp. Maybe they are at work (if they are
commited yet)?

[Emmanuel Rodriguez (potyl)]

> 1) downgrading to dhcp3-client_3.0.1-1ubuntu4 from
> http://archive.ubuntu.com/ubuntu/pool/main/d/dhcp3
I have downgraded to version 3.0.1 and it seems to work better.
I did a couple of reboots and so far so goood.

> 2) upgrading to dhcp3-client_3.0.3-3 from
> http://ftp.debian.org/debian/pool/main/d/dhcp3
>
There is no package for amd64 so I can't try the version 3.0.3.

> And find out whether one, or both, of these fixes the problem. Make sure to
> test a few reboots with each one to make sure it's not a fluke.
I hope that it will work.

[vic-quakesrc (vic-quakesrc)]

After upgrading 'netbase'to the latest version the problem seems to be gone. I
haven't tested more carefully though - three reboots so far. Here's the
ChangeLog - bug 21617

netbase (4.21ubuntu3) breezy; urgency=low

  * debian/netbase.init: Temporarily increase usplash timeout to 120 seconds
    to cope with slop DHCP server responses. (Ubuntu #15394)

 -- Martin Pitt <email address hidden> Mon, 19 Sep 2005 13:05:12 +0200

[Web-forums-ubuntu (web-forums-ubuntu)]

Breezy 5.10 Preview Release installer CD completely fails to activate DHCP on a
machine I'm trying to install it on. It doesn't actually appear to be sending
discover packets, as my DHCP server isn't logging any requests from the machine
in question -- it's almost as if the DHCP client is trying to do this without
even bringing the layer 2 link up.

[Oliver Grawert (ogra)]

hmm, i wonder why nobody notices the absence of the "auto eth0" line in
/etc/network/interfaces ... surely its not dhclients job to generate this file
correctly... i had some people reporting the same problem in #edubuntu while
using vmware... but rather saw it as a vmware bug...

[Andrew King (kingos)]

(In reply to comment #0)
> I did an upgrade via aptitude on my Dell Inspiron 600m, Broadcom gigabit

[Scott James Remnant (Canonical) (canonical-scott)]

(In reply to comment #43)
> hmm, i wonder why nobody notices the absence of the "auto eth0" line in
> /etc/network/interfaces ... surely its not dhclients job to generate this file
> correctly... i had some people reporting the same problem in #edubuntu while
> using vmware... but rather saw it as a vmware bug...
>
There's not supposed to be an "auto" line ...

auto means that the interface is bought up by S:S40networking

There's supposed to be something that looks like this:

        mapping hotplug
         script grep
         map eth0

Which means that the interface is bought up on insertion, or by S:S40hotplug

[Web-forums-ubuntu (web-forums-ubuntu)]

(In reply to comment #42)
> Breezy 5.10 Preview Release installer CD completely fails to activate DHCP on a
> machine I'm trying to install it on. It doesn't actually appear to be sending
> discover packets, as my DHCP server isn't logging any requests from the machine
> in question -- it's almost as if the DHCP client is trying to do this without
> even bringing the layer 2 link up.

I can no longer reproduce this problem; it appears that this must have been due
to a switch port going bad.
Sorry for the noise.

[Mikkel Kamstrup Erlandsen (kamstrup)]

It has worked for three boots for me now too, but please don't close the bug
anyway. This happened before with the bug mysteriously reappearing (just check
the history). *crossing fingers* :-)

[KoS (kos-ooo)]

Hi all!

I just dist-upgraded to breezy from hoary yesterday, and I'm experiencing the
same problem as above.
After my first restart with the new system DHCP doesn't work anymore (it doesn't
get an IP through DHCP during bootup). I also tried "dhclient eth0" but it
didn't work. Then I reinstalled dhcp3-client and dhclient eth0 worked, but
during bootup still no luck (I don't get any IP through DHCP).
When I run "dhclient eth0" I get this (note I removed the last 2 numbers from my
MAC address from this log):
--------------------------------------------
There is already a pid file /var/run/dhclient.pid with pid 0
Internet Systems Consortium DHCP Client V3.0.2
Copyright 2004 Internet Systems Consortium.
All rights reserved.
For info, please visit http://www.isc.org/products/DHCP

sit0: unknown hardware address type 776
sit0: unknown hardware address type 776
Listening on LPF/eth0/00:0a:48:0b:93:XX
Sending on LPF/eth0/00:0a:48:0b:93:XX
Sending on Socket/fallback
DHCPREQUEST on eth0 to 255.255.255.255 port 67
DHCPREQUEST on eth0 to 255.255.255.255 port 67
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 3
DHCPOFFER from 192.168.0.1
DHCPREQUEST on eth0 to 255.255.255.255 port 67
DHCPACK from 192.168.0.1
bound to 192.168.0.199 -- renewal in 288565 seconds.
------------------------------------

So I get an IP after DHCPDISCOVER. Unfortunately this is not too fast, as it is
first trying DHCPREQUEST...

I found an interesting thing dough, which is I accidentally booted with my older
kernel (from Hoary, 2.6.10-5-386), and with that kernel DHCP works as it
should!!! So this problem is probably not a dhcp3-client problem, but something
from the kernel??
Note that I'm managing the grub.conf by hand (I have dual Linux boot), and I'm
not giving any special flag to the kernel in the config.

Oh and I have a 3Com Corporation 3c905C-TX/TX-M [Tornado] ethernet card.

Oh and one more interesting thing!!! In the old kernel, the 3c59x ethernet
driver is working alone, but in the 2.6.12-9-386 (actual Breezy kernel) some
module called "mii" is loaded before 3c59x and 3c59x is using the mii module!!!

If you need any further informations, just ask, I will check this thread time to
time...

[Jorge Rodriguez Suarez (jorge-rodriguez-suarez)]

Hi there!

I have this problem, the dhclient3 eth0 or dhclient3 eth1 (for wireless) doesn't
work..

My system is a
- Laptop Toshiba Tecra A4 SP216
- Breezy Badger (the release)
- Marvell Yukon 88E8036 PCI-E Fast Ethernet Controller
- Intel (R) PRO/Wireless 2200BG Network Connection
- Dual Boot (Ubuntu + Windows XP Professional, where both interfaces works )

The lspci recognize both interfaces (ethernet and wireless), but there is no
activity (tcpdump -ni eth0) when i do dhclient3 eth0, there is activity (tcpdump
-ni eth1) when i do dhclient3 eth1, but nothing about receive IPs from DHCP
Server on both... :(, from windows both interfaces receives IPs...

What can be the problem with?, do i need to update the dhclient package to a new
release? (the release instaled is 3.0.2, well i didn't made changes on Breezy
packages).

[Scott James Remnant (Canonical) (canonical-scott)]

Do people still have this problem?

[Wouter Stomp (wouterstomp-deactivatedaccount)]

(In reply to comment #50)
> Do people still have this problem?

On Dapper, I still have to run 'sudo dhclient eth0' to get my internet
connection up. But it is described in a separate bugreport:
http://bugzilla.ubuntu.com/show_bug.cgi?id=15340

[Scott James Remnant (Canonical) (canonical-scott)]

(In reply to comment #51)
> (In reply to comment #50)
> > Do people still have this problem?
>
> On Dapper, I still have to run 'sudo dhclient eth0' to get my internet
> connection up. But it is described in a separate bugreport:
> http://bugzilla.ubuntu.com/show_bug.cgi?id=15340
>
Right, that's a totally different problem -- does anyone have DHCP timing out
anymore?

[Ramon de Ruiter (won)]

*raises hand*
I do unfortunatly. Since about a week or 2 maybe 3 i got this problem. So i searched bugzilla and found this
bug, though it seems to be old so i'm not sure if this is related.
Only thing i can remember that changed is the kernel, again about 2 or 3 weeks ago. now i have to do a "sudo
dhclient eth0" to make the network online again.
Then web, mail etc. work great, but when i manually mount a NFS mount (which didn't get mounted because of this
bug) it takes about a minute to work.
Should i also attach all relevant config files as told here before?

[Ramon de Ruiter (won)]

I know whining isn't gonna help fixing the bug. But i was wondering if there's
still someone looking into this since it's a quite annoying bug. Otherwise i
guess i'll just do a fresh Breezy install to have everything fixed and get it
over with. In that case this bug can be closed since probably no one else is
expierencing this bug.

[Mikkel Kamstrup Erlandsen (kamstrup)]

(In reply to comment #50)
> Do people still have this problem?

Yes. I've just installed, and dist-upgraded, a Dapper Flight 2 box. No network
before I "sudo dhclient eth0". My good ol' clean Breezy box works like a charm
though :-)

[Scott James Remnant (Canonical) (canonical-scott)]

(In reply to comment #54)
> I know whining isn't gonna help fixing the bug. But i was wondering if there's
> still someone looking into this since it's a quite annoying bug.
>
I've looked into it, but have been utterly unable to replicate it I'm afraid.
Without any clue to what's causing it, I don't know where to begin fixing it.

[Scott James Remnant (Canonical) (canonical-scott)]

(In reply to comment #55)
> (In reply to comment #50)
> > Do people still have this problem?
>
> Yes. I've just installed, and dist-upgraded, a Dapper Flight 2 box. No network
> before I "sudo dhclient eth0". My good ol' clean Breezy box works like a charm
> though :-)
>
This is unrelated.

[Ramon de Ruiter (won)]

I was going to report the problem had dissapeared after a fresh Breezy install.
However, today i upgraded to Dapper and i expierence the same problem again...

[ed-ong (ed-ong)]

I think i am having the same problem. I am using Dapper with wireless.

My work around was to add pre-up delay to interfaces file. e.g.

auto eth1
iface eth1 inet dhcp
 wireless-mode managed
 wireless-essid zbo
 wireless-key1 xxxxxxxx
 wireless-key xxxxxxxx
        pre-up sleep 10

Because it is parellizing(?) it does not affect my boot up time. Of course, if i run it later from a terminal i'll have to wait 10s.

[ed-ong (ed-ong)]

Regarding my comment above, please do not read it as a solution. Just providing more info.

[François Tissandier (baloo)]

My 2 cents to this bug report. I'm having a strange behavior here, fresh Dapper Flight 4 install, also present on my Dapper Flight3:

I have a fixed IP address on my wireless card. But no matter what, it won't work when I boot. I have to do a ifdown eth0, dhclient eth0, interrupt it with a Ctrl+C, then ifup eth0, interrupt it with a Ctrl+C, then my wireless card is connected... I don't know if it's really related to this bug, but I found it very strange that I need a dhclient to make my static connection work... Hope it will help.

[David (djst) Tenser (djst)]

I'm seeing this bug too. Using my freshly installed Dapper Flight CD4 install, I don't get any network until I do "sudo dhclient3" (or, as I have understand is better to do, "sudo dhclient eth0").

My system is a Dell Inspiron (Centrino) with both a normal ethernet adapter and Intel Pro/Wireless 2915. I only use the non-wireless eth0 and chose that as the default network adapter during install.

For the record, this worked without any problems in Breezy (final release).

[Loïc Corbasson (cnb)]

I had the same problem (Sony PCG FR285E) but I also read bug report #33968 and tried the workaround. It works for me, maybe it'd help you too... as it seems that this bug is very strange, maybe some black magic would help!

PS: I had an Acer Aspire with Breezy, but it wasn't affected by this bug at the time (in September).

[Michael Onnen (michael-onnen)]

I ran into this bug yesterday after installing dapper flight 5 on a sun fire x2100.

The x2100 has two nics: an nvidia (forcedeth) and a broadcom (tg3):
# lspci | grep Ethernet
0000:00:0a.0 Bridge: nVidia Corporation CK804 Ethernet Controller (rev a3)
0000:04:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5721 Gigabit Ethernet PCI Express (rev 11)

During installation the installer asked which one should be the primary nic, I answered tg3. Installation went fine, but after the reboot dhclient didn't get an ip for the tg3. Invoking "dhclient eth0" manually worked. Also putting "pre-up sleep 10" for eth0 in /etc/network/interfaces worked. Btw. I have UTC=yes in /etc/default/rcS.

This problem seems to be related to the renaming of interface names in /etc/iftab. The installer put
 eth0 mac mac_of_tg3
 eth1 mac mac_of_nvidia
in there, which is the opposite order of how the kernel detects the nics (nvidia first, then tg3).
Using nvidia and putting "auto eth1" in /etc/network/interfaces: works.
After swapping eth0 and eth1 in /etc/iftab:
Using nvidia with "auto eth0": works.
Using tg3 with "auto eth1": works.

So, only when tg3 is renamed to eth0 dhclient fails.

[Matt Zimmerman (mdz)]

This bug report is very confused. There are many references to unrelated problems with interfaces not being brought up during boot.

Is anyone seeing the *original problem* on current Dapper, where dhclient is run, but fails with "Network is down" errors? If not, this bug should be closed.

If you are having a different problem, please search Launchpad and subscribe to the corresponding bug report, and refrain from commenting on it here.

[Antti Salminen (antti-salminen)]

I'm seeing the exact original problem after dist-upgrading to dapper from breezy on a Thinkpad A30.

Running "ip link set eth0 up" helps dhclient to obtain a lease but it then fails to set the configuration in place and gives the following errors:

SIOCSIFADDR: Permission denied
SIOCSIFFLAGS: Permission denied
SIOCSIFNETMASK: Permission denied
SIOCSIFBRDADDR: Permission denied
SIOCSIFFLAGS: Permission denied
SIOCSADDRT: Operation not permitted

After which it hangs indefinitely.

[Antti Salminen (antti-salminen)]

It turns out that at least in my case the issue was a simple case of the dhcp3-common and dhcp-client packages being left unconfigured. One way or another my dist-upgrade had only been half-finished and a simple dpkg --configure packagename fixed the problems with dhcp.

Since the original poster also reinstalled his dhcp client (albeit an older version of it) it seems probable that his problem was similar and this "bug" doesn't exist.

[Martin Pitt (pitti)]

Indeed this would explain the 'permission denied' messages, since the postinst has to fix the permissions of /lib/dhcp3-client/call-dhclient-script.

[Martin Pitt (pitti)]

I'm closing this bug since the latest breezy->dapper upgrade tests as well as install tests do not show this problem. It may very well be that a dist-upgrade to an earlier dapper version stumbled over any broken package and left some packages unconfigured.

Please reopen if you still encounter this problem.

[Mac (mac-jones)]

How I fixed it....

have a look in /etc/iftab, my file had eth0 linked to the wrong mac address, hence the nic was being given the next available (eth1) as shown by ifconfig -a.

When I changed the mac address in /etc/iftab to have eth0 mac 00:xx:xx:xx:xx:xx (for the actual card), everything started just fine !

In laymans terms, eth1 was the only interface the machine could assign, but the /etc/network/interfaces file was still trying to play with eth0.

Another way to fix it is to change eth0 to eth1 in all places in /etc/network/interfaces.

[Mac (mac-jones)]

You can also just comment out the entries in /etc/iftab. This is the option i've used now as I want to mirror this hard disk to other machines. (And don't want to have to update iftab every time).

Mac
New Zealand

[Russell Butturini (rbutturini)]

Just wanted to add a note that I had this problem upgrading to gutsy, and my solution was similar to Antti's. An unconfigured libcap1 package had prevented dhcp3-common and dhcp3-client from being configured properly, and there was no message during the upgrade process to indicate this.

[merlinpr (merlinpr)]

I've had some of my users report this issue and I hadn't been able to replicate it on my own systems. After doing some research I found this bug and just wanted to add something very interesting that I've found in my situation.

I've noticed that if a computer can't get an address from DHCP I can plug it in to a 10/100 switch and then connect the switch to the wall and the issue goes away. That lead me to believe that the problem was caused by speed mismatch on the interface since all my core switches are configured to do auto negotiation. I tried configuring the interface speed and duplex manually but that didn't help. Since my Linux user base is small and I have plenty of 10/100 switches I've been using that as a temporary workaround until I can get this figured out.

Just wanted to post this in case someone is having similar issues and needs a temp fix.

[Chris Dunning (chris-bluenoteweb)]

I had the same problem today upgrading my laptop from Kubuntu Gutsy->Hardy. As suggested above by Antti "slux" Salminen I ran dpkg --configure on both dhcp3-common and dhcp3-client which solved the problem.