# Dhcpcd timeout on e100 after kernel upgrade [SOLVED]

## niffs

Well, I've had this problem for a while now, but have been suppressing it by using an old (2.6.12) kernel... but it's starting to bother me now.

After corrupting my hard drive and buying a new one, I reinstalled gentoo from scratch. I had been using a fairly old kernel on the previous hard drive, and when I reinstalled I grabbed the newest version. Networking worked fine off of the livecd (2007.0 amd64 minimal install cd), but when I installed a kernel to the hard drive (I used the mm-sources variant, but I've tried gentoo-sources and vanilla-sources to no avail) networking consistantly timed out.

My ethernet card is a "Intel Corporation 82557/8/9 [Ethernet Pro 100] (rev 05)" according to lspci, and it's worked fine with the e100 driver up until this upgrade. When I attempt to run dhcpcd, I get a message in my dmesg to the effect: "e100: e100_watchdog: link up, 100Mbps, full-duplex", but I don't recieve a connection. Ifconfig states that, after running dhcpcd, I have no transmitted or recieved packets on the eth0 interface. I can manually set the address, but it does me no good. When I try to ping my router (192.168.1.1), I recieve the ever-so-ominous "Destination Host Unreachable" messages.

Now, I know it's not a problem with my network. I have a laptop and another desktop, both running gentoo with modern kernels, sitting next to the problematic system, and they both connect via dhcpcd perfectly. I've googled all over the place for this problem, and I honestly have no idea what could be causing it.

All help is appreciated, and many thanks in advance!

----------

## vaxbrat

I have an old Compaq blade (Pentium III Coppermine) running two NICs with this driver on a 2.6.21 hardened kernel without any problems.  Granted, this is 32 bit vs 64 for you and I'm running static addresses instead of dhcpd.

Are you building into the kernel or doing modules.  Is the module loading so you can do an ifconfig.  What is in your logs?

----------

## niffs

I get the feeling it might be a 64-bit problem of some kind, judging that I couldn't find any solid information elsewhere on it.

I've tried both building it in and as a module. The driver seems to register fine with the card during bootup, and the interface shows up as it should via ifconfig. When I run dhcpcd on it, the interface comes up, but it does not receive an IP and the TX / RX packets remain at zero... I've booted up with a 2.6.12 kernel as a backup for need of an internet connection, but if you need more specifics I can reboot into the 2.6.22 version... hope that helps.

----------

## vaxbrat

Can you get it working with another box and static addresses?

Also which driver variant did you use, the original Becker (which loads as eepro100) or the official Intel Pro/100+ (which loads as e100)?

Looks like when I did kernel 21 I built both modules and let em fight it out with udev.  Funny enough, it looks like they both loaded so I'm not sure which one is being used.  Maybe they decided to take a NIC each   :Razz: 

----------

## niffs

I'm using e100, but I tried eepro100 just as an assurance. With the older kernel I'm using e100 as well, but it works perfectly fine. The box next to the broken one is running a 2.6.22 mm series kernel perfectly fine, but it has a via rhine-II card. I'll try building the e100 and eepro100 modules on that and plugging the card in, just to see what happens. I'll post results in a bit. Thanks a lot for the help, by the way  :Very Happy: 

----------

## niffs

Well, I was able to use the card on the 32-bit box sitting next to the problematic 64-bit system with the e100 driver. No problems there. I did, however, find a via rhine-III pci card sitting around in the 32-bit box that wasn't fully plugged in (hence not registering on lspci), and decided to try and give it a spin on the 64-bit system. However, I ran into the same problem with the rhine-III that I did with the EtherPro (dhcpcd timeout, even after the module loads perfectly and ifconfig claims the card exists), so I'm starting to wonder if it's a problem with some network setting in the kernel other than the e100 driver...

Still, what confuses me the most is that the 2007.0 livecd (with a 2.6.19 gentoo kernel) boots perfectly... I'm wondering if that release is problem free? Or maybe there's a kernel config difference that I'm not noticing...

----------

## niffs

Oh, yes, and I have tried static addresses. They weren't any help  :Sad: 

----------

## hasues

I noticed my nic can not receive a DHCP address either with the dhcpcd timing out.  This occurs if I use /etc/init.d/net.eth0 to start the nic with the issue.  However, if I run dhcpcd manually it works.  This would suggest configuration problems in /etc/conf.d/net, but I have not changed my file, only updated to 2007.0 from 2006.0.  Have you tried running dhcpcd manually after bringing the interface by using /sbin/dhcpcd <interface name>?

J

----------

## steves

I had a similar issue some time ago. It only occurred with 4G memory.

There is a current thread at 

[url] http://news.gmane.org/group/gmane.linux.drivers.e1000.devel/last=/force_load=t

Not sure if this is the same problem as yours but may help.

Steve.

----------

## niffs

Yeah, I've tried running dhcpcd manually. It gives the same error :/

This thread: http://thread.gmane.org/gmane.linux.drivers.e1000.devel/1664 on the page steves linked looks particularly interesting... I'll have to look into that. The inability to send/recieve packets seems to be a lot like what's going on with my card... I have MSI disabled in my kernels (both the 2.6.12 and the 2.6.22), as it would be. I'm going to try enabling it and see what happens.

----------

## hasues

niffs, I just wanted to clarify.  If I ran "dhcpcd <interface>" it would NOT work (and this being a manual run).  However, if I fully qualified the path "/sbin/dhcpcd <interface>", it would in fact work.  Have you tried fully qualifying the path?

Haz

----------

## niffs

Hmm... That's peculiar. I'll try it (after rebooting to the 2.6.22 kernel...) Any ideas as to why it would work any differently than just running dhcpcd?

----------

## hasues

I have no clue.  All I know is that if I run /etc/init.d/net.<interface> it doesn't work.  If I run "dhcpcd <interface>", it does not work, but if I run /sbin/dhcpcd eth0, it does work.  If I run which dhcpcd, it shows it to be in /sbin/dhcpd.  It's strange.

Haz

----------

## niffs

Well, unfortunately using the full name (/sbin/dhcpcd) doesn't help... That is very strange, though... maybe some kind of bug?

Enabling MSI did nothing either... I'm going to try looking into various kernel command line options that might have something to do with all of this   :Confused: 

----------

## hasues

Now I'm finding that I have to run it twice??

I'm not sure if the kernel is the right place to look as the configuration options for the dhcp client.  Oh well.

Haz

----------

## niffs

Yes, but the thing is dhcpcd works perfectly fine under a 2.6.12 kernel... which makes me think it's unrelated to dhcpcd... but... perhaps there could be some kind of weird incompatibility between dhcpcd and the kernel going on. Would it potentially help to try a different dhcp client?

----------

## hasues

The short answer is "yes".  None of the dhcp clients cover every DHCP servers options from what I have read.  I do note that you have changed kernels, but I'm willing to bet you probably could have updated your entire system.  Newer versions of glibc, etc have more of an effect than that does (unless your kernel has bugs surrounding network code).  I was able to get my dhcpc client to work today, but I had to increase the time out and I told the client not to supply a hostname ( -h"" ).  You could try a newer/older version of the dhcpcd client, or as you said, try out one of the other ones.

Haz

----------

## niffs

Well, I tried a couple other clients (udhcpd/pump), which also timed out... I don't think increasing timeout length will have an effect because ifconfig claims I'm not even *transmitting* packets let alone recieving, which is a slightly scary idea. I'm pretty sure it's a fault of the kernel because the system connects perfectly fine with a 2.6.12 kernel and an inability to transmit packets would potentially imply a driver problem... I'm thinking at this point the best option might simply be to stick with the old kernel for a bit longer until everything's been updated a few releases, then emerge -e world, and see if the problem isn't fixed... I'll try downgrading the client and checking into the timeouts / no host name thing, but I get the feeling it won't do much... If that doesn't work, I think I may try building a kernel with config copied *exactly* from the livecd (same version, too), since the livecd boots perfectly, and hope that works...

----------

## niffs

Problem Solved:

Now, no need to call me stupid, i can assure everybody i've just called myself that enough right now...

but apparently "noapic" is some sort of magic kernel option that solves all manner of problems, including my ethernet problems.

So after more than a year of being stuck on an increasingly outdated kernel, losing udev support, and going through multiple ethernet cards to no avail (currently a netlink, but i'd bet the e100 would work now too), it would appear the problem is solved with a simple six letters. Well, thanks for all the help anyway  :Very Happy: 

Now I just have to figure out why my card has decided to be "eth3" instead of "eth0"... ?

----------

## Casshan

Look in 

/etc/udev/rules.d/70-persistent-net.rules

Udev sets a ethX based on MAC Address

----------

## niffs

hah, thanks, i should know these things by now   :Embarassed: 

----------

