Wired network eth0 not working with 2.6.35-22-generic and Intel e1000e driver version 1.0.2-k4

Same behaviour FIXED by upgrading to latest e100e drivers (e1000e-1.2.20), works perfectly now. Thanks!!

00:19.0 Ethernet controller: Intel Corporation 82566DC Gigabit Network Connection (rev 02)
driver: e1000e
version: 1.2.20-NAPI
firmware-version: 1.1-0
bus-info: 0000:00:19.0

@Esteban_73,

Since you experienced this issue, would you "confirm" this bug (click on the little pencil icon under Status) so that we can get the updated driver into a newer kernel release?

Still experiencing this issue with latest kernel 2.6.35-24-generic because the old driver is still included with this kernel update...

    driver: e1000e
    version: 1.0.2-k4
    firmware-version: 0.3-0

However, the latest working network driver that should be included with the kernel update is...

    driver: e1000e
    version: 1.2.20-NAPI
    firmware-version: 0.3-0

I can confirm that this issue is still present with kernel 2.6.35-25-generic. And also confirming that installing the updated driver (as per above) fixes the issue. Thanks @PJSingh - before now, I was having to sudo ifconfig eth0 up/down on repeat until it worked!

Just found this on the debian wikki network manager page. Might be applicable here and to various other NIC card issues I have seen here lately. http://wiki.debian.org/NetworkManager

Scroll down to the section marked "NetworkManager in Squeeze" and it says the following..

NetworkManager in Squeeze
Wired Networks are Unmanaged
As of Debian Squeeze, NetworkManager does not manage any interface defined in /etc/network/interfaces by default.

Unmanaged devices means NetworkManager doesn't handle those network devices. This occurs when two conditions are met:

The file /etc/network/interfaces contains anything about the interface, even:
allow-hotplug eth0
iface eth0 inet dhcp
And /etc/NetworkManager/NetworkManager.conf contains:
[main]
plugins=ifupdown,keyfile

[ifupdown]
managed=false
Since network-manager version 0.8.1-4, existing wired/wireless interfaces in /etc/network/interfaces are disabled with a #NetworkManager# prefix during package installation, then re-enabled when the network-manager package is removed (Debian bug 530024).

Enabling Interface Management
If you want NetworkManager to handle interfaces that are enabled in /etc/network/interfaces:

Set managed=true in /etc/NetworkManager/NetworkManager.conf.
Restart NetworkManager:
/etc/init.d/network-manager restart
"Auto Ethernet" and "Auto eth0"
Auto Ethernet means "Select an Ethernet interface automatically"
Auto eth0 means "autconfigure the eth0 interface".

I think its relative...

*update*

Okay I think this may not really be a linux/debian/Ubuntu et al problem or bug. Regardless of the documented bug with network manager with Debain and therefore subsequent derivatives, there is an issue that is Windows 7 related that I think will clear up a lot of these issues. Now this may get rather verbose and long, but I did this so it can be understand by anyone even us noobs or at least semi noobs.

When you have a dual boot scenario with windows 7 or vista I believe ( not sure if vista is same never used it) Windows must be first as usual. So being first it would seem logical that most of us installed win7 then installed our various linux ditros accordingly after the win7 install and initial setup. I assume most of us (me especially) setup their win7 install and got it running and in particular got the networking all arranged so we would have internet right away. And in so doing most of us set up homegroup network to share files and data amongst other pc's on the same network/router connection. When we did that we set up the home network not just in the win7 environment but in the network itself. I cannot explain it properly in technical terms but the simple mans take on it would be win7 has to make changes in the router settings or somewhere non-OS dependent to allow the homegroup magic to happen unhindered and simply as possible for the average non tech home user. This started when we chose the name of our computer at installation/setup of windows 7.

More simply what ever name you gave your PC in windows 7 you must also use for your linux install if you use a dual boot scenario of any hardrive or partition scheme. I cannot explain the particulars as to why in a simple manner quick enough here, but doing this one thing fixed all of my networking problems in linux.

So in your windows 7 install if your PC's name is "Fred's PC" or whatever, you must name your PC in the linux install the exact same name. Do not confuse your PC's name with your login or admin names. Those are different. This was not the case in XP but if you have a working win7 install you have to make sure the PC names match for both linux and win7. No matter the dual boot scenario, they must match. If not your only other option would be to somehow get both your router/server/network to see your linux install as a different PC altogether and that seems a bit of a nuisance when this is such a simple thing to do.

Well I know this cured all of my network issues in linux right away. Running both Ubuntu 10.10 64 bit and Kubuntu 10.10 64 bit with out a single networking issue for two days now (knock on wood). And used a Puppy Linux Live CD to see if it worked there as well. Sure enough no connection until I set the PC name to the same as windows7 then Bingo! it worked.

Anyway thanks for reading I hope it helps someone.

@gslack,

I do not use Windows on any of the PCs on my network. They all have (single-boot) Ubuntu 10.10.

I have this issue with two different machines (that have the same on-board Intel network-adapter) each time I upgrade the Linux kernel version. The reason for this is because the non-working driver (version 1.0.2-k4 for the e1000e NIC) in the kernel updates has never been replaced with a newer working version.

((The other machines on my network use PCI NIC cards from different vendors, and do not exhibit this issue).

I have been able to consistently fix the problem by updating the network adapter driver, using the steps I described above.

I suggest you check if there are newer drivers available for your NIC.

Okay went and tried other distros over the last week or so...

First I think your problem is specific to the intel NIC/chip on your machine(s). That being said, updating the specific intel driver may work fine in your situation, but I was addressing the larger more general issues regarding ethernet connections over the last few months using the .33 - .35 kernels. I have a nvidia MCP-67 chipset ethernet controller. It actually uses realtek chips. I also went and installed a seperate PCI ethernet card, an older Linksys. I get the same problem with either NIC and it is not right away nor is it all the time. It only happens AFTER I log into windows 7 then try and login to linux. At first I can reset my router and all is working again but this is a temporary fix.

As I said I have gone with Ubuntu 10.04 which worked fine until either the updated kernel or I installed WIndows 7(no idea which because Windows 7 install was just before the kernel update). Soon after I had an issue with my NIC not connecting. I went through every forum I could find and met with varied levels of success using all kinds of methods. I updated fiirmware, and it worked. After a couple days I had to restart my router to get DHCP to work. I tried updating to 10.10 again same thing. Tried using Puppy linux and the tools there to get a connection and no luck. I tried Kubuntu 10.10, same issues, Pinguy OS, Gentoo live dvd, Debian squeeze, Slackware, and with every single one I got the same problem. Now my router is working fine, and has had no issues for over a year of use. Windows XP and WIndows 7 works with it without a single problem. Yet somehow with these linux kernels the thing has DHCP issues.

The OS's (linux) all recognize my NIC's (both of them), both are recognized fully and show no problems at all. Yet somehow after running windows7 and then logging back into linux I cannot connect with either card. And the only thing that has worked for me reliably has been to restart my router and ensure my linux OS uses the same PC name as my Win7.

Now it must be something with either DHCP and the kernels, a windows 7 problem involving home networking and such, or some other issue i am unaware of. Updating firmware worked in 10.04 for a short time only but 10.10 which shows the firmware installed in synaptic, still has the same issues. This is the same in every distro I have tried using any combination of those kernels. I can make it work by swapping the Eth cable between the two NIC's and restarting the router but as long as I have to do that I don't think I will be using the Linux drive very much...

Still experiencing this problem on kernel 2.6.35-30 in Ubuntu 11.04 x64. After each kernel upgrade, I am forced to manually install the Intel driver for my network interface chip.

PJSingh5000, thank you for reporting this and helping make Ubuntu better. This bug was reported a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue? Can you try with the latest development release of Ubuntu? ISO CD images are available from http://cdimage.ubuntu.com/releases/ .

If it remains an issue, could you run the following command from a Terminal (Applications->Accessories->Terminal). It will automatically gather and attach updated debug information to this report.

apport-collect -p linux <replace-with-bug-number>

Also, if you could test the latest upstream kernel available that would be great. It will allow additional upstream developers to examine the issue. Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Once you've tested the upstream kernel, please remove the 'needs-upstream-testing' tag. This can be done by clicking on the yellow pencil icon next to the tag located at the bottom of the bug description and deleting the 'needs-upstream-testing' text. Please let us know your results.

Thanks in advance.

I am no longer experiencing this issue with kernel 3.0.0-17 on Ubuntu 11.10 x64.

PJSingh5000, this bug report is being closed due to your last comment regarding this being fixed with an update. For future reference you can manage the status of your own bugs by clicking on the current status in the yellow line and then choosing a new status in the revealed drop down box. You can learn more about bug statuses at https://wiki.ubuntu.com/Bugs/Status. Thank you again for taking the time to report this bug and helping to make Ubuntu better. Please submit any future bugs you may find.