Bug 249950 - After updating and booting to kernel version Network adapters failed to aquire an IP Address, wired and wireless
Summary: After updating and booting to kernel version Network adapters...
Status: CLOSED DUPLICATE of bug 250003
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 7
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2007-07-28 12:23 UTC by Rico R.
Modified: 2007-11-30 22:12 UTC (History)
3 users (show)

Clone Of:
Last Closed: 2007-08-01 11:03:56 UTC

Attachments (Terms of Use)

Description Rico R. 2007-07-28 12:23:23 UTC
Description of problem:
updated from, after booting to the new kernel version, none of
the network connections would acquire an address, I tried connecting it to a
different router and even by wireless but the problem was only solve when booted
to the old Kernel. while the problem was going on, the computer would halt at
boot waiting for an IP address and would only boot when disconnected from the
LAN. knetworkmanager would be able to detect the cable being disconnected and
could even see the difference between a 100 and a 1000 based network. after a
while, the wired interface would assign itself a 169.254.xxx.xxx address but no
connectivity was gained.

Version-Release number of selected component (if applicable):
kernel version

How reproducible:

Steps to Reproduce:
1. update system to kernel version
2. boot system using new kernel
Actual results:
no connectivity

Expected results:
no connectivity

Additional info:
Motherboard: ASUS P5B Deluxe WIFI, running Fedora 7 32 Bit

Comment 1 Steven Bakker 2007-07-28 22:46:57 UTC
I can confirm this, same thing happens to me on a Dell XPS M1210, both wireless
(Intel 3945) and wired (Broadcom). Booting back to makes the problem
go away. Using tshark I can see the DHCPOFFER messages coming back into my
interface, but somehow they get dropped/ignored.

Also, when I manually assign an IP and set the default route, data transfers
happen much slower than normally (around 65Kbit/s vs. the normal 10Mbit/s).

"Something rotten in the state of Kernel" methinks.


Comment 2 Mario Torre 2007-07-30 11:21:24 UTC
I can confirm this too, I solved setting "allow users to enable this device" in

Comment 3 Steven Bakker 2007-07-30 11:46:18 UTC
Mmmh, system-config-network offers me "allow ALL users to ...". I'm not sure I
want to do that. Even so, it's a regression with respect to and it
does look like a bug to me. Also, when using this new kernel, my X session keeps
giving me a warning that I was logged in for 0 seconds whenever I logout. Could
well be a permission problem as well, but where is the difference with the
previous kernel...?

Comment 4 Mario Torre 2007-07-30 12:02:28 UTC
Yeah, right, I've noticed that too... There are at least 3 regressions that
could be somewhat related and were introduced by this kernel, the X bug (not
sure someone has already filed that), the clock bug (250049) and this one. As
for the network issue, maybe keeping -27 for now is the safest thing (I agree on
multi-user machine is not really nice to allow everybody to control the
devices), but for users that use NetworkManager (usually single user/family
machines) this can be a good workaround if -33 is needed for some other reason.

Comment 5 Steven Bakker 2007-07-31 22:43:36 UTC
There's a kernel mentioned in comment 13 of bug #249857 (250049 is a duplicate
of that one) that fixes both that bug and this one for me. As for -33? Those
bits have been de-gaused on my disk :-)

Comment 6 Milan Kerslager 2007-08-01 11:03:56 UTC
The latest kernel- solves the problem. Please reopen or create
new bugreport if your problem persist. See bug #250003 for more info.

*** This bug has been marked as a duplicate of 250003 ***

Note You need to log in before you can comment on or make changes to this bug.