Bug 249950

Summary:	After updating and booting to kernel version 2.6.22.1-33.fc7 Network adapters failed to aquire an IP Address, wired and wireless
Product:	[Fedora] Fedora	Reporter:	Rico R. <richempire>
Component:	kernel	Assignee:	Kernel Maintainer List <kernel-maint>
Status:	CLOSED DUPLICATE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	high	Docs Contact:
Priority:	low
Version:	7	CC:	jan.public, neugens, sb
Target Milestone:	---
Target Release:	---
Hardware:	i686
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2007-08-01 11:03:56 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Rico R. 2007-07-28 12:23:23 UTC

Description of problem:
updated from 2.6.22.1-27.fc7, 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 2.6.22.1-33.fc7

How reproducible:


Steps to Reproduce:
1. update system to kernel version 2.6.22.1-33.fc7
2. boot system using new kernel
3.
  
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 2.6.22.1-27 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.

Cheers,
Steven

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
system-config-network.

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 2.6.22.1-27 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-2.6.22.1-41.fc7 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 ***