Red Hat Bugzilla – Bug 449841
DHCP fails to get IP info for RTL 8169 NIC
Last modified: 2008-08-04 22:25:48 EDT
Description of problem: If I configure the Network IF to get its IP info via DHCP it fails get it. The IF works fine with statically assinged IP info Version-Release number of selected component (if applicable): How reproducible: Every time. Steps to Reproduce: 1.Configure the NIC to get IP info via DHCP 2.Start or restart the network or reboot 3. Actual results: Looking in the log you can see the service trying to obtain a response from the DHCP server but it fails to get one (the DHCP server is OK) Expected results: Net work address obtained from DHCP server. Additional info: This came to light from a post on the Fedora forum regarding another issue with the RTL 8169 which was resolved. Another reader having the same original problem posted that he had tried the fix but it did not work. He was using DHCP. I advised him to try manually setting the IP address which he did and it worked. I then set my NIC to get its info via DHCP and it failed also. I think this is related to bug 439107
I don't have the RTL 8169 adapter, but if it is related to bug 439107, there's not much I can do until that is fixed. I would recommend testing under rawhide to see if recent kernels fix the problem.
Is the problem with dhcp still occuring?
Hi. I've been following this issue because I've been having the same problem. I didn't think to try a static address as a work-around until I saw this issue. The problem for me first showed up when a yum update to my Fedora 8 updated to kernel 2.6.24, and I was always able to get back to normal by dropping back to a 2.6.23 kernel. The issue is still there with 2.6.25 kernel on Fedora 9 for me. (I did a clean Fedora 9 install from scratch to be sure I didn't have any bad configuration hanging around.) I've noticed on my system, when it's misbehaving, the hardware interrupts from the NIC are basically increasing nonstop and using about 30% CPU. From some experimenting tonight, it looks like if I configure the interface with the static address and bring it up and down first, I can then get the DHCP client to work until I reboot. That's the first time I've noticed that, but I hadn't been testing it much once I found the static IP workaround. Having normally working DHCP again would be great, though.
I have tried to reproduce this problem locally after searching down an RTL 8169, but I just can't get the same behavior you are seeing. My guess is you have some faulty network hardware in your mix. Perhaps a hub or switch that needs replacing. Or maybe the adapter is simply faulty. I would suggest trying another NIC and eliminating any equipment in between your computer and the DHCP server (just to figure out if it's a hardware problem or a software problem). I have tried numerous configurations, but the device works fine for me here, so I'm not sure what I can do.
When the problem first started happening, I tried everything you mentioned with the network hardware. The problem is the built-in wired NIC on a laptop. The built-in wireless interface on the same laptop works fine. Other machines connect to the same router (using both wired and wireless connections) and work without issues. I have seen my share on NICs fail, but in my experience when they do they don't work again at all after that. In this case, however, everything works perfectly again if I run Fedora 8 and the 2.6.23 kernel. There may be something else in my configuration that causes the trouble, but I don't know where to start looking. I'm pretty happy to spend some time debugging this, but I don't know where to start digging in. I did recompile the driver, but aside from adding some logging I don't know what I can do. Just in case any of this is outside what you tried, I am running the x86-64 kernels, and I have had to boot with nohz=off or the system locks up hard a few minutes after powering on. My hunch was that this has something to do with my seeing the hardware interrupts going out of control, but I don't know where to go next.
If you are still seeing this on F-9 and rawhide, I would recommend filing a bug against the kernel. This most definitely sounds like a problem with the kernel. There's not a lot I can do with the userspace software to fix this.