The adapters work fine in Windows, so I would say that the problem is likely with the distro and/or the driver version that it includes. Despite this, I will mention it to the BIOS team at Intel. in the meantime, why don't you try some other (newer) distros (there are some that you can temporarily boot from USB flash disks) and see if the issue is with these particular distros (since Intel doesn't formally support Linux on the NUCs, I doubt they will be testing with these distros unless someone can demonstrate that the BIOS is the likely culprit).
Hope this helps,
Thanks for your answer.
I doubt there is a distro that is newer than Fedora 23, that is known to be bleeding edge with latest components in terms of kernel and drivers.
Keep in mind that the Linux driver for e1000e gigabit adapters is developed by Intel itself....
$ sudo modinfo e1000e | grep author
author: Intel Corporation, <firstname.lastname@example.org>
I tried with 3.2.6 and 3.3.3 Intel drivers and tomorrow I'm going to test also the 3.3.4 that has just been released on 20/5, by Intel itself as I wrote above; see:
But I doubt it will work better than the previous ones, because it refers to it as "... I217/I218 controllers under Linux", while the adapter on the NUC6 is detected as I219-V
$ sudo lspci -nnk | grep -iA2 net | grep Ethernet
00:1f.6 Ethernet controller : Intel Corporation Ethernet Connection I219-V [8086:1570] (rev 21)
Hello, please try this solution, as I've used it multiple times and works. I have a NUC6i5SYH, and tried numerous Linux distros, CentOS being one of the pickier ones.
For speeding up help, I presume you've double checked connections are indeed 1GB/s, including the cables (cat6 is the only one rated for 1GB/s while cat5e is 200MB/s, and the rest are lower).
After the above checks, check to see if you can attach gigabit controller to kernel. System - Administration - Add/Remove Software - Search: dkms
You'll see if repository has this available to you. If it does, continue with the onscreen steps to adding that to kernel. If not, continue.
Download your driver package here: Download Intel® Gigabit Network Connection Driver for Intel® NUC Kits NUC6i[x]SY and NUC6i7KYK
Download ndiswrapper: ndiswrapper download | SourceForge.net and unpack it.
System - Administration - Synaptic Package Manager
In the search box type: ndiswrapper-utils (check the box next to it)
Click next. Type in the search box: ndisgtk (same thing will appear, check box next to it)
Both parts of ndiswrapper have downloaded and will install to computer, and automatic convert to Linux environment.
Locate LAN_Win7_64_20.7.1.exe and when you install it, ndiswrapper will convert the driver for Linux to understand.
Finished. Windows driver now converted to Linux, and this works on plenty of Linux distros.
DO NOT USE A BIOS UPDATER (.exe) AND CONVERT! HIGH CHANCE OF 'BRICKING' YOUR DEVICE. If you need to update the BIOS, flash it from within the BIOS off a USB.
Hope this helps!
Just a comment regarding this last statement: Whether you initiate the BIOS update from within Windows (i.e. invoking a BIOS .EXE file), from within DOS (using .BIO file with iFlash2 utility) or from within BIOS itself (.BIO file via F7 key), the BIOS update process is performed identically: the .BIO file is placed in memory and the system is rebooted. The existing BIOS on the board will detect that there is a .BIO file image sitting in memory and will start its install. It's true that the Windows installation method does have a more involved process for retaining (in memory, without corruption) the .BIO file image across the shutdown process, but this DOES NOT mean that the .EXE method has any higher chance of bricking the BIOS. Why? Because the file has to be decompressed and decrypted and this is done after the reboot. The method that was used to place the .BIO file image in memory is completely out of the picture (over and done with) before the actual update process begins. Further, since the decompression and decryption processes are subject to record verification (like checksums but a lot more sophisticated) and, if this verification should fail, the file will be rejected (and the update process will be aborted), all methods are equal.
So, having said this, why do BIOSs brick? Well, the BIOS engineers will hate me for saying so (nothing new; I never gave them any peace), but it is bugs in the BIOS, plain and simple. It could be some unexpected upgrade interaction as a result of the combination of the existing BIOS and this new BIOS. It could be some unexpected interaction between the existing BIOS configuration file (which resides in the flash IC) and the expectations for this file (for example, position of parameters) in the new BIOS. It could simply be a new bug introduced with the new BIOS (and not caught in regression testing). I could go on and on and on. There are literally millions of lines of firmware code running on each and every system and there is the potential for bugs (yes, plural) in each and every line. Every BIOS release goes through literally thousands of hours of regression testing (that's why they don't come out that often) but things have their way of sneaking through the cracks...
So... much noise for nothing!
You are right when you stress to check cables/ports/switches..
I tried 3.3.4 driver and also 4.6.1 kernel provided by elrepo but I still had network at 100mbps.
So I directly connected the nuc with another linux pc with gb adapter and I saw speed change at 1gbps...
I went again at switch mgmt page and noticed that the page I thought was related to speed status, actually it was for speed setting... I misunderstood it;-(
So at the end I verified that with all kernels and drivers the speed was correct at 1gbps: 3.3.4, 3.2.5-k and the one provided by kernel 4.6.1.
At the end I reverted to the original latest official kernel for CentOS 7, that at time is 3.10.0-327.18.2.el7.x86_64, with its own driver for e1000e (3.2.5-k) and all i good.
Sorry again and if you come near Milan and Pavia in Italy I owe you a beer ;-)