New ASUS NUC 14 Essentials doesn't see wired Ethernet NIC

jgregg · March 23, 2025 at 10:57 PM

FYI - Recently purchased a new ASUS NUC 14 Essentials (Intel N250 version) to replace my 11+ year old ASUS Chromebox that was reloaded to run Kodi. I attempted to load LibreELEC 12.0.2 on the new NUC computer but it didn't boot past the LibreELEC splash screen.

Suspected a driver issue so I loaded one of the nightly builds (LibreELEC-Genericx86_64-13.0-nightly-20250322-faee3d0.img) and the NUC booted into Kodi enough to add a TVHeadend PVR client and was able to watch and hear TV. However the Realtek r8169 NIC never loaded but WiFi could connect.

Next I loaded Fedora Workstation 41 to check that the hardware was working. After many Fedora updates, a new Realtek firmware file was downloaded and now I have wired network. Fedora reports the NIC as: Realtek Internal NBASE-T PHY r8169-0-100:00

So along with the other development work for LibreELEC, an updated Realtek firmware file may need to be included.

HomerJau · March 24, 2025 at 8:35 AM

I bought a ASUS NUC 14 Pro i7 recently (for s/w development on the road) running Windows 11 Pro and the Ethernet failed after I updated drivers etc. WiFi was good.

The fix was to update to latest NUC 14 bios.

**chewitt** · March 24, 2025 at 1:16 PM

Quote from jgregg

So along with the other development work for LibreELEC, an updated Realtek firmware file may need to be included.

Run "dmesg | paste" and share the URL. If there's a missing firmware it will probably be flagged?

If yes, the file can be manually added https://wiki.libreelec.tv/how-to/add-firmware (grab the file from the fedora image) and then tell us what's missing.

jgregg · March 24, 2025 at 7:20 PM

Uploaded the results of the dmesg command to https://paste.libreelec.tv/warm-condor.log. Log shows the file (r8169.ko.xz) I copied to the firmware directory was loaded but no joy from the wired NIC. May need other files to get the device to work:

[ 1.613431] r8169 0000:01:00.0: enabling device (0000 -> 0003)
[ 1.613505] r8169 0000:01:00.0: error -ENODEV: unknown chip XID 688, contact r8169 maintainers (see MAINTAINERS file)

**smp** · March 24, 2025 at 8:12 PM

Support for that chip revision was added by this linux commit. Kernel 6.12.x does not include it.

**chewitt** · March 25, 2025 at 11:14 AM

jgregg Update to this image: https://chewitt.libreelec.tv/testing/LibreE…_64-12.80.0.tar

Working?

jgregg · March 25, 2025 at 6:19 PM

Thanks for the reply but the file at: https://chewitt.libreelec.tv/testing/LibreE…_64-12.80.0.tar doesn't include an image.

Is there a new way to load a SD card and install?

**Da Flex** · March 25, 2025 at 6:59 PM

jgregg You can use that tar file to update from SSH:

Code

cd /storage/.update
wget https://chewitt.libreelec.tv/testing/LibreELEC-gbm.x86_64-12.80.0.tar
reboot

jgregg · March 25, 2025 at 7:05 PM

Ok . . I'm assuming you sent an update TAR file and found the process on the WIKI page.

Put the tar file in the /storage/.update/ folder and during the reboot, it shows 12.80.0 as the version but still no wired network,

After my post yesterday I had performed a BIOS update to v.021. However, there was no wired network.

Also re-applied the firmware and driver files from the Fedora build but no wired network. This update seemed to make the chipset go dark so I reloaded the OS to the nightly build v13 dated 20250322 and at least the green light came back but no amber light. Your update file was applied to the last OS load.

Thanks for the help and waiting for the next step.

**chewitt** · March 26, 2025 at 2:54 AM

I linked the .tar file because you said WiFi worked so you have a working internet connection. I assume this was used to share the previous "dmesg | paste" dump. An .img.gz version of the tweaked image is in the same webserver folder but reinstalling only results in the same state as an update (which is quicker/easier).

Please share a URL from "dmesg | paste" again, so we can see if the chip is now correctly detected and is there any attempt to load firmware? Note that r8169.ko.xz is an xz compressed kernel module (.ko) file not firmware (usually .bin or .fw) so adding that to the image via a firmware overlay will not do anything useful.

jgregg · March 26, 2025 at 12:58 PM

Here you go: https://paste.libreelec.tv/holy-trout.log

**smp** · March 26, 2025 at 4:00 PM

Looks like this change is also needed

**chewitt** · March 27, 2025 at 5:05 AM

Please update with: https://chewitt.libreelec.tv/testing/LibreE…_64-12.80.0.tar - the image now uses Linux 6.14.0 which contains a load more r8169 changes. If that works i'll revert back to 6.12.x and the extra patch that smp flagged. I'd already built the 6.14 image so you might as well test that first.

jgregg · March 27, 2025 at 11:14 AM

Awesome man! I have a working wired network chipset and the log at: https://paste.libreelec.tv/funky-phoenix.log should not reveal any new issues besides the serial ports that are not enabled.

Thanks for all your help

**chewitt** · March 30, 2025 at 11:03 AM

I've done some further build experiments with patches. In short, the second patch smp flagged does not apply to Linux 6.12.y as the function being patched doesn't exist, and the more I look into surrounding code for the change that adds it, the more I see that r8169 has seen a large amount of change in Linux 6.13.y and 6.14.y and I don't think it's worthwhile trying to add ever-more patches to see if the NIC works.

As LE13 currently plans to use Linux 6.12.y this means the release version of LE13 will not support the chip so you will either need to keep using the development build I previously shared until LE14 ships sometime in 2026 or you will need to learn how to self-build an LE image with a newer kernel. The development image will continue to work, but once LE13 ships we'll bump the LE add-on repo version to match the release version and from that point there will be no updated to the repo, and a some point we'll cleanup/delete the old development repos.