DHCP and ping failure on e1000e

[Adam J Richardson]

Every morning I boot my two systems: one Dell Vostro 200 running 32-bit Jaunty, the other an Acer Extensa running Windows XP Professional SP3. The Extensa and the Vostro are both wired to the same consumer-grade router, a Belkin F5D8233.

The Extensa gets itself an IP through DHCP and logs onto the domain, no problem. Everything network-y (email, web, network drives etc) works fine.

The Vostro times out. It sends out lots of DHCPDISCOVER packets. Only after numerous manual "sudo /etc/init.d/networking restart" (and much foul language) does it finally see a DHCPOFFER from the Belkin. Once this happens, everything works perfectly. It's just the initial failures that irritate me. (It doesn't help that the router itself is rubbish, but I try not to stress the poor thing. Anyway the problem predates the installation of the router.) Hibernating instead of shutting down doesn't help; the network stays connected, but the link is dead on wake-up and I have to "sudo /etc/init.d/networking restart".

This problem has been with the Vostro since Gutsy (it's been upgraded to Hardy and Intrepid before Jaunty, never is there a fix). IIRC there were some driver issues with Gutsy which were finally resolved in Intrepid (no more manual driver compiling at every kernel upgrade, hurrah).

I've tried Network Manager and wicd, neither fixes the problem. I've stuck with wicd for now, because I want my boss to be able to access network services on the Vostro even when I'm not here.

I'm guessing it's a bug in the e1000e driver. I can't see what else it might be.

Here are some data regarding my setup, hopefully something obvious is wrong. Thanks for reading.

arichardson@vostro-1:~$ lspci | grep -i eth
00:19.0 Ethernet controller: Intel Corporation 82562V-2 10/100 Network Connection (rev 02)

arichardson@vostro-1:~$ sudo lshw -C network
  *-network
       description: Ethernet interface
       product: 82562V-2 10/100 Network Connection
       vendor: Intel Corporation
       physical id: 19
       bus info: pci@0000:00:19.0
       logical name: eth0
       version: 02
       serial: 00:1a:a0:8e:3b:b4
       size: 100MB/s
       capacity: 100MB/s
       width: 32 bits
       clock: 33MHz
       capabilities: pm msi bus_master cap_list ethernet physical tp 10bt 10bt-fd 100bt 100bt-fd autonegotiation
       configuration: autonegotiation=on broadcast=yes driver=e1000e driverversion=0.3.3.3-k6 duplex=full firmware=1.1-2 ip=10.22.5.104 latency=0 link=yes module=e1000e multicast=yes port=twisted pair speed=100MB/s

arichardson@vostro-1:~$ sudo ifconfig -a
eth0 Link encap:Ethernet HWaddr 00:1a:a0:8e:3b:b4
          inet addr:10.22.5.104 Bcast:10.22.5.255 Mask:255.255.255.0
          inet6 addr: fe80::21a:a0ff:fe8e:3bb4/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST MTU:1478 Metric:1
          RX packets:682199 errors:0 dropped:0 overruns:0 frame:0
          TX packets:516363 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:596725935 (596.7 MB) TX bytes:53380925 (53.3 MB)
          Memory:fdfc0000-fdfe0000

eth0:0 Link encap:Ethernet HWaddr 00:1a:a0:8e:3b:b4
          inet addr:10.22.5.3 Bcast:10.22.5.255 Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST MTU:1478 Metric:1
          Memory:fdfc0000-fdfe0000

lo Link encap:Local Loopback
          inet addr:127.0.0.1 Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING MTU:16436 Metric:1
          RX packets:13995 errors:0 dropped:0 overruns:0 frame:0
          TX packets:13995 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:7599721 (7.5 MB) TX bytes:7599721 (7.5 MB)

arichardson@vostro-1:~$ cat /etc/network/interfaces
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet dhcp
mtu 1478
timeout 5

auto eth0:0
iface eth0:0 inet static
address 10.22.5.3
netmask 255.255.255.0
gateway 10.22.5.2
mtu 1478

arichardson@vostro-1:~$ sudo lsmod | grep e1
e1000e 121136 0

arichardson@vostro-1:~$ lsb_release -rd
Description: Ubuntu 9.04
Release: 9.04

[Adam J Richardson (fatman-crackmonkey)]

Here is this morning's console output from "sudo /etc/init.d/network restart". It usually takes more than two tries, especially if I'm in a hurry to log in. I've shortened a few of the longer lines by removing whitespace only.

arichardson@vostro-1:~$ sudo /etc/init.d/networking restart
[sudo] password for arichardson:
 * Reconfiguring network interfaces...
RTNETLINK answers: No such process
There is already a pid file /var/run/dhclient.eth0.pid with pid 2751
removed stale PID file
Internet Systems Consortium DHCP Client V3.1.1
Copyright 2004-2008 Internet Systems Consortium.
All rights reserved.
For info, please visit http://www.isc.org/sw/dhcp/

Listening on LPF/eth0/00:1a:a0:8e:3b:b4
Sending on LPF/eth0/00:1a:a0:8e:3b:b4
Sending on Socket/fallback
DHCPRELEASE on eth0 to 10.22.5.2 port 67
send_packet: Network is unreachable
send_packet: please consult README file regarding broadcast address.
 * Reloading /etc/samba/smb.conf smbd only
   ...done.
RTNETLINK answers: No such process
SIOCDELRT: No such process
Moving from dhclient3,lan to if-pre-up,eth0,lan
Internet Systems Consortium DHCP Client V3.1.1
Copyright 2004-2008 Internet Systems Consortium.
All rights reserved.
For info, please visit http://www.isc.org/sw/dhcp/

Listening on LPF/eth0/00:1a:a0:8e:3b:b4
Sending on LPF/eth0/00:1a:a0:8e:3b:b4
Sending on Socket/fallback
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 7
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 15
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 21
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 14
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 4
No DHCPOFFERS received.
No working leases in persistent database - sleeping.
 * if-up.d/mountnfs[eth0]: waiting for interface eth0:0 before doing NFS mounts
Moving from if-pre-up,eth0,lan to eth0:0,if-pre-up,lan [ OK ]
arichardson@vostro-1:~$ sudo /etc/init.d/networking restart
 * Reconfiguring network interfaces...
There is already a pid file /var/run/dhclient.eth0.pid with pid 5242
killed old client process, removed PID file
Internet Systems Consortium DHCP Client V3.1.1
Copyright 2004-2008 Internet Systems Consortium.
All rights reserved.
For info, please visit http://www.isc.org/sw/dhcp/

Listening on LPF/eth0/00:1a:a0:8e:3b:b4
Sending on LPF/eth0/00:1a:a0:8e:3b:b4
Sending on Socket/fallback
DHCPRELEASE on eth0 to 10.22.5.2 port 67
 * Reloading /etc/samba/smb.conf smbd only
   ...done.
RTNETLINK answers: No such process
SIOCDELRT: No such process
Moving from eth0:0,if-pre-up,lan to if-pre-up,eth0,lan
Internet Systems Consortium DHCP Client V3.1.1
Copyright 2004-2008 Internet Systems Consortium.
All rights reserved.
For info, please visit http://www.isc.org/sw/dhcp/

Listening on LPF/eth0/00:1a:a0:8e:3b:b4
Sending on LPF/eth0/00:1a:a0:8e:3b:b4
Sending on Socket/fallback
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 4
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 4
DHCPOFFER of 10.22.5.104 from 10.22.5.2
DHCPREQUEST of 10.22.5.104 on eth0 to 255.255.255.255 port 67
DHCPACK of 10.22.5.104 from 10.22.5.2
 * Reloading /etc/samba/smb.conf smbd only
   ...done.
Mo...

[Adam J Richardson (fatman-crackmonkey)]

Today's report is a bit longer. I'll attach it rather than quoting it.

[Adam J Richardson (fatman-crackmonkey)]

Maybe a Wireshark trace will help?

[Adam J Richardson (fatman-crackmonkey)]

A complication: when the Vostro gets an IP address it is unable to ping the router. Reloading the kernel module (e1000e) fixes the problem and allows network communications to begin.

Are there still problems with e1000e NICs? Could my problem have been caused by https://bugs.launchpad.net/ubuntu/+source/linux/+bug/263555 ? I did have Intrepid on the Vostro.

[Adam J Richardson (fatman-crackmonkey)]

Tried upgrading wicd from 1.6.0 to 1.6.2. That didn't solve the problem.

[derp (dgharibi)]

I'm on Jaunty and have the same problem. I unplug and plug the ethernet until the link light turns on.

lspci:

00:19.0 Ethernet controller: Intel Corporation 82562V-2 10/100 Network Connection (rev 02)
        Subsystem: Dell Device 0238
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 0
        Interrupt: pin A routed to IRQ 2302
        Region 0: Memory at fdfc0000 (32-bit, non-prefetchable) [size=128K]
        Region 1: Memory at fdfff000 (32-bit, non-prefetchable) [size=4K]
        Region 2: I/O ports at fe00 [size=32]
        Capabilities: <access denied>
        Kernel driver in use: e1000e
        Kernel modules: e1000e

uname -a :

Linux XXXXXXX 2.6.28-14-generic #47-Ubuntu SMP Sat Jul 25 00:28:35 UTC 2009 i686 GNU/Linux

[derp (dgharibi)]

I've gone back to my original solution of using 2.6.24-21-generic. I'll test new kernel builds as they come.

[Adam J Richardson (fatman-crackmonkey)]

Going back to a previous kernel fixes this? Tempting, but I think that would break more stuff for me than it fixes... thanks anyway. :)

[xtsbdu3reyrbrmroezob (xtsbdu3reyrbrmroezob)]

I am confirming this bug. Many people report the same issue with this hardware, firmware revision, and driver. Since this issue also occurs in Windows, it is highly suspect that the Intel networking firmware is to blame, but I am unable to find any update for the firmware or workarounds in the e1000e firmware. Also note that this device is a 10/100 card, and not gigabit capable, as the driver's name e1000e may seem to suggest.

I am open to any suggestions. Who should be assigned to this bug? Perhaps it is best left to be handled by upstream Linux devs...

[sc9944 (sc9944)]

Upstream link.

http://bugzilla.kernel.org/show_bug.cgi?id=11998

And a temporary patch against the e1000e drivers on sourceforge

[Tom Hagen (5at3u)]

This problem is noted on my Dell530n, running up to date Jaunty 9.04
I shall muddle thru with a WiFi card until it is fixed.

[Vivien GUEANT (vivienfr)]

I have the same problem with my Dell Inspiron 530 with Ethernet controller: Intel Corporation 82562V-2 10/100 Network Connection (rev 02) and Ubuntu 9.10 64 bits.

[Vivien GUEANT (vivienfr)]

The bug is present with Ubuntu 10.04 Lucid Alpha2 (upgrade 17 jan 2010) with kernel 2.6.32-10-generic #14-Ubuntu SMP Thu Jan 7 17:38:08 UTC 2010 x86_64 GNU/Linux

[Robert Hollencamp (rhollencamp)]

This bug also affects me, and is highly annoying. I experienced it with 9.04 (i386), 9.10 (i386), and 10.04 (amd64). Some mornings, a single 'sudo dhclient eth0' will immediately work, and some mornings (like this one) I spend about 10 minutes trying to get on the network.

Vista does not have a problem with the card (I dual boot), and immediately gets an IP - its a pretty safe bet that the cable / switch / DHCP server etc are not to blame.

My steps to get on the network in the morning:
 * try 'sudo dhclient eth0' and pray
 * if that fails, 'ifconfig eth0 down && ifconfig eth0 up && dhclient eth0' a few times
 * if that fails, 'rmmod e1000e && modprobe e1000e' and repeat ifconfig / dhclient stuff above
 * if all else fails, unplug the networking cable and plug it back in; repeat steps above

As I mentioned earlier, I don't always have to do all of these steps; it is completely random which one will fix it first (and how long it takes). If I can provide any additional information, please let me know.

[xtsbdu3reyrbrmroezob (xtsbdu3reyrbrmroezob)]

The bug occurs in windows 7 on the same hardware so I am likely to believe
this still indicates a firmware issue...
--
Kristian Erik Hermansen

On May 12, 2010 6:05 AM, "Robert Hollencamp" <email address hidden> wrote:

This bug also affects me, and is highly annoying. I experienced it with
9.04 (i386), 9.10 (i386), and 10.04 (amd64). Some mornings, a single
'sudo dhclient eth0' will immediately work, and some mornings (like this
one) I spend about 10 minutes trying to get on the network.

Vista does not have a problem with the card (I dual boot), and
immediately gets an IP - its a pretty safe bet that the cable / switch /
DHCP server etc are not to blame.

My steps to get on the network in the morning:
 * try 'sudo dhclient eth0' and pray
 * if that fails, 'ifconfig eth0 down && ifconfig eth0 up && dhclient eth0'
a few times
 * if that fails, 'rmmod e1000e && modprobe e1000e' and repeat ifconfig /
dhclient stuff above
 * if all else fails, unplug the networking cable and plug it back in;
repeat steps above

As I mentioned earlier, I don't always have to do all of these steps; it
is completely random which one will fix it first (and how long it
takes). If I can provide any additional information, please let me know.

--
DHCP and ping failure on e1000e
https://bugs.launchpad.net/bugs/382671
You received this bug no...

[derp (dgharibi)]

> The bug occurs in windows 7 on the same hardware so I am likely to believe
> this still indicates a firmware issue...

It works fine on 2.6.24-21. One of my machines is still on Jaunty because of this.

[derp (dgharibi)]

I wanted to see if the e1000e driver was the culprit so I recompiled the e1000e kernel module for 2.6.28-19 with 2.6.24's code. The problem did not go away; I still had the same issues.

Anyone have any idea why it would work flawlessly on 2.6.24-21, but not on anything later?

[Adam J Richardson (fatman-crackmonkey)]

Unsubscribing since almost everything has changed. The router has died, we have a new location and network setup. I failed to lose the Vostro in the big move. D'oh! :P

[candtalan (aeclist)]

Ubuntu 10.04
I help a friend with a few PCs. Two are Dell Vostro 200 desktops, and both have started to randomly fail to connect when booted up. I say randomly, they *mostly* fail to connect to the network, and it does seem rather dhcp like but I am rather guessing. One machine has a bit more luck connecting than the other. I had a live CD 8.04.3 handy and I tried that in the 'bad' machine, it worked ok live session, IP address ok.

Three other machines are also on the small network, one 8.04.4, one 10.04 and an older PC with xubuntu 10.10, they work ok.

[Brad Figg (brad-figg)]

This bug was filed against a series that is no longer supported and so is being marked as Won't Fix. If this issue still exists in a supported series, please file a new bug.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.