Description of problem:
updated from 126.96.36.199-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 188.8.131.52-33.fc7
Steps to Reproduce:
1. update system to kernel version 184.108.40.206-33.fc7
2. boot system using new kernel
Motherboard: ASUS P5B Deluxe WIFI, running Fedora 7 32 Bit
I can confirm this, same thing happens to me on a Dell XPS M1210, both wireless
(Intel 3945) and wired (Broadcom). Booting back to 220.127.116.11-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.
I can confirm this too, I solved setting "allow users to enable this device" in
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 18.104.22.168-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
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.
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 :-)
The latest kernel-22.214.171.124-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 ***