No link light with fresh install

[paulzeye]

I have a Intel NUC NUC5i5RYH that I've recently done a fresh install on. Prior to fresh install networking was working as expected.

I've installed from .iso downloaded here:
https://saimei.ftp.acc.umu.se/debian-cd ... e-CD-1.iso

During the install I was not able to bring up network connection so was not able to do an update. With install complete I'm still not able to bring up my network connection. My setup is:

Cable Modem -> Router ->NUC

The router is configured to provide DHCP. Other machines plugged into the router are working fine. I've swapped cables that are working with other machines and I do not see link light on the NUC.

Here is some debugging output to help diagnose:

Code: Select all

root@lilnuc:/etc/network# lspci
00:00.0 Host bridge: Intel Corporation Broadwell-U Host Bridge -OPI (rev 09)
00:02.0 VGA compatible controller: Intel Corporation HD Graphics 6000 (rev 09)
00:03.0 Audio device: Intel Corporation Broadwell-U Audio Controller (rev 09)
00:14.0 USB controller: Intel Corporation Wildcat Point-LP USB xHCI Controller (rev 03)
00:16.0 Communication controller: Intel Corporation Wildcat Point-LP MEI Controller #1 (rev 03)
00:19.0 Ethernet controller: Intel Corporation Ethernet Connection (3) I218-V (rev 03)
00:1b.0 Audio device: Intel Corporation Wildcat Point-LP High Definition Audio Controller (rev 03)
00:1c.0 PCI bridge: Intel Corporation Wildcat Point-LP PCI Express Root Port #1 (rev e3)
00:1c.3 PCI bridge: Intel Corporation Wildcat Point-LP PCI Express Root Port #4 (rev e3)
00:1d.0 USB controller: Intel Corporation Wildcat Point-LP USB EHCI Controller (rev 03)
00:1f.0 ISA bridge: Intel Corporation Wildcat Point-LP LPC Controller (rev 03)
00:1f.2 SATA controller: Intel Corporation Wildcat Point-LP SATA Controller [AHCI Mode] (rev 03)
00:1f.3 SMBus: Intel Corporation Wildcat Point-LP SMBus Controller (rev 03)
02:00.0 Network controller: Intel Corporation Wireless 7265 (rev 59)
root@lilnuc:/etc/network# dmesg |grep 00:19
[    0.392521] pci 0000:00:19.0: [8086:15a3] type 00 class 0x020000
[    0.392533] pci 0000:00:19.0: reg 0x10: [mem 0xaa100000-0xaa11ffff]
[    0.392539] pci 0000:00:19.0: reg 0x14: [mem 0xaa13b000-0xaa13bfff]
[    0.392545] pci 0000:00:19.0: reg 0x18: [io  0x3080-0x309f]
[    0.392596] pci 0000:00:19.0: PME# supported from D0 D3hot D3cold
[    0.392648] pci 0000:00:19.0: System wakeup disabled by ACPI
[    0.835557] e1000e 0000:00:19.0: Interrupt Throttling Rate (ints/sec) set to dynamic conservative mode
[    0.929530] e1000e 0000:00:19.0 0000:00:19.0 (uninitialized): registered PHC clock
[    1.014277] e1000e 0000:00:19.0 eth0: (PCI Express:2.5GT/s:Width x1) b8:ae:ed:79:8a:92
[    1.014281] e1000e 0000:00:19.0 eth0: Intel(R) PRO/1000 Network Connection
[    1.014323] e1000e 0000:00:19.0 eth0: MAC: 11, PHY: 12, PBA No: FFFFFF-0FF
[    1.015916] e1000e 0000:00:19.0 enp0s25: renamed from eth0
root@lilnuc:/etc/network# more /etc/network/interfaces
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

auto enp0s25 
allow-hotplug enp0s25
iface enp0s25 inet dhcp
root@lilnuc:/etc/network# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp0s25: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
    link/ether b8:ae:ed:79:8a:92 brd ff:ff:ff:ff:ff:ff

Any suggestions on how to proceed?

[stevepusser]

You could try a Live session of one or more direct Debian derivative distros to see if they have it working out of the box. If so, then you know there must be a solution, and can try to duplicate it. I don't know if that Intel wired NIC requires non-free firmware, but I don't think so. The wi-fi one does, firmware-iwlwifi.

[paulzeye]

Thanks Steve,

I previously had jessie working so I know there is a solution. I'll try a live cd image to help gather info.

[paulzeye]

Okay I've booted off Ubuntu 16.04 image. Initially I had the same problem. After bootup the wireless was working with non-free firmware but still no link light on wired.

I ran apt-get update &&apt-get upgrade - no change
I unplugged- replugged ethernet cable - started working!

I'm not really sure what is going on. Ubuntu also seems to be using e1000e driver.

Any thoughts on how to proceed?

[Head_on_a_Stick]

Run `rfkill list` then use `rfkill unblock all` (both as root) if the interface is shown to be "soft blocked" in the output.

Otherwise, what happens if you try

Code: Select all

# ifup enp0s25

or

Code: Select all

# dhclient enp0s25

[paulzeye]

Hi Head...,

Thanks for the reply. rfkill seems to be for wirelesss interfaces- this did not report any information on my wired interface.

When I ran ifup enp0s25 the interface was reported as already up, so I rand ifdown/ifup, here are results:

Code: Select all

root@lilnuc:~# ifdown enp0s25
Killed old client process
Internet Systems Consortium DHCP Client 4.3.5
Copyright 2004-2016 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/enp0s25/b8:ae:ed:79:8a:92
Sending on   LPF/enp0s25/b8:ae:ed:79:8a:92
Sending on   Socket/fallback
root@lilnuc:~# ifup enp0s25
Internet Systems Consortium DHCP Client 4.3.5
Copyright 2004-2016 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/enp0s25/b8:ae:ed:79:8a:92
Sending on   LPF/enp0s25/b8:ae:ed:79:8a:92
Sending on   Socket/fallback
DHCPDISCOVER on enp0s25 to 255.255.255.255 port 67 interval 7
DHCPDISCOVER on enp0s25 to 255.255.255.255 port 67 interval 20
DHCPDISCOVER on enp0s25 to 255.255.255.255 port 67 interval 13
DHCPDISCOVER on enp0s25 to 255.255.255.255 port 67 interval 9
DHCPDISCOVER on enp0s25 to 255.255.255.255 port 67 interval 7
DHCPDISCOVER on enp0s25 to 255.255.255.255 port 67 interval 5
No DHCPOFFERS received.
No working leases in persistent database - sleeping.
root@lilnuc:~# dhclient enp0s25
root@lilnuc:~# 

The dhclient command produced no output.


In the meantime I've loaded the non-free firmware to get the wireless interface working. I've ran full apt-get update && apt-get upgrade and still am not having success.
All suggestions appreciated!

Thanks
Paul

[Head_on_a_Stick]

rfkill seems to be for wirelesss interfaces

Yes, of course it is, silly me

When I ran ifup enp0s25 the interface was reported as already up, so I rand ifdown/ifup, here are results:

Code: Select all

root@lilnuc:~# ifup enp0s25
Internet Systems Consortium DHCP Client 4.3.5
Copyright 2004-2016 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/enp0s25/b8:ae:ed:79:8a:92
Sending on   LPF/enp0s25/b8:ae:ed:79:8a:92
Sending on   Socket/fallback
DHCPDISCOVER on enp0s25 to 255.255.255.255 port 67 interval 7
DHCPDISCOVER on enp0s25 to 255.255.255.255 port 67 interval 20
DHCPDISCOVER on enp0s25 to 255.255.255.255 port 67 interval 13
DHCPDISCOVER on enp0s25 to 255.255.255.255 port 67 interval 9
DHCPDISCOVER on enp0s25 to 255.255.255.255 port 67 interval 7
DHCPDISCOVER on enp0s25 to 255.255.255.255 port 67 interval 5
No DHCPOFFERS received.
No working leases in persistent database - sleeping.
root@lilnuc:~# dhclient enp0s25
root@lilnuc:~# 

Is your router configured to offer IP addresses when requested?

Can you assign the addresses manually with the `ip` command?

The output of these commands may also be useful:

Code: Select all

ip a
ip r

[paulzeye]

Hi Head...,

Yes my router is configured to assign IP addresses with DHCP. Other machines that I plug in are assigned addresses with DHCP. I've also tried another router. Manually assigning an IP address also does not work. I'm still receiving the NO CARRIER message- I think this problem resides lower than the IP layer.

Here is the result of ip a & ip r

Code: Select all

root@lilnuc:~# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
3: wlp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 94:65:9c:18:ee:2b brd ff:ff:ff:ff:ff:ff
    inet 192.168.252.17/24 brd 192.168.252.255 scope global dynamic wlp2s0
       valid_lft 188469sec preferred_lft 188469sec
    inet6 fe80::cf0e:3db0:b7b3:7e57/64 scope link 
       valid_lft forever preferred_lft forever
4: enp0s25: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
    link/ether b8:ae:ed:79:8a:92 brd ff:ff:ff:ff:ff:ff
root@lilnuc:~# ip r
default via 192.168.252.1 dev wlp2s0 proto static metric 600 
192.168.252.0/24 dev wlp2s0 proto kernel scope link src 192.168.252.17 metric 600 
root@lilnuc:~# 

The info above is for my wireless interface(192.168.252.0/24 is my wireless network, 192.168.15.0/24 is my wired)

Thanks for the suggestions please let me know if anything else to try.

Thanks,
Paul

[stevepusser]

It make me wonder if it's some regression with that driver in the 4.9 kernel. You might try adding a newer kernel, like the Liquorix 4.12 one, which currently is still stretch-compatible, and see if that makes any difference. Keep the stock kernel; you can always return to it if Liquorix doesn't work out.

[ticojohn]

I've been running Stretch on a NUC5i5RYH for over a year. The biggest issue I have had with internet is that the ethernet connector on the back of the NUC sometimes does not have a good connection (poor fit - quality control issue ?). I had everything working out of the box but went ahead and updated drivers anyway. Might check that the ethernet connector is plugged in and making good connection. I read some reports on similar issues on the Intel Support Forum https://communities.intel.com/community/tech. I've actually gotten fairly decent support from them even though they are more MS friendly.

[paulzeye]

Hi Steve,

Thanks for suggestion. I was able to install 4.12 from the unstable branch and had the same issue

[paulzeye]

Hi Ticojohn,

I was running Jessie for over a year with out issues. This was a fresh install with new hardware to start fresh with Stretch. I did unplug/replug ethernet cable in this process. I've plugged it back in MANY times and get the "click"every time. I've tried wiggling and moving the cable but don't seem to have any luck.

Thanks for suggesting the intel forums- I'll give them a try.

Thanks,
Paul

[Head_on_a_Stick]

I've booted off Ubuntu 16.04 image. Initially I had the same problem. After bootup the wireless was working with non-free firmware but still no link light on wired.

I ran apt-get update &&apt-get upgrade - no change
I unplugged- replugged ethernet cable - started working!

If you can reproduce this then it would be useful to see the `dmesg` (or `journalctl`) output during the revival of the connection, this may show what actually happened.

Also, how does the system behave in the Debian stretch "live" environment?

An intermittent failure would seem to suggest a hardware-related problem of some sort.

[v&n]

If you can install ethtool, you may try disabling auto-negotiation on the NIC and setting its speed to 100 Mb/s (1000 Mb/s does need autoneg to be 'On'). In such no-link issues, I sometimes get success with this trick, though the problem rarely happens with e1000e.

To do this with ethtool -

Code: Select all

# ethtool -s <your ethernet interface> speed 100 duplex full autoneg off

And have you tried a manual down/up of the interface with ifconfig or a similar command? If not, I recommend trying that first -

Code: Select all

# ifconfig <interface> down
# ifconfig <interface> up

Though I must admit that both these are pre-systemd era tricks. I can't be sure if they still work the same way.

[tynman]

In the original post, it says

I've swapped cables that are working with other machines and I do not see link light on the NUC.

I would tend to interpret that to mean there is a hardware problem. As long as the computer has power, then the NIC's port lights should show some life when a network cable is plugged into it. And if that's the case, all this talk about network drivers and NIC settings are for naught.

[v&n]

I would tend to interpret that to mean there is a hardware problem. As long as the computer has power, then the NIC's port lights should show some life when a network cable is plugged into it. And if that's the case, all this talk about network drivers and NIC settings are for naught.

Not necessarily. I kinda remember having faced such problems, more than once, where both the NIC lights remain completely dead, until fixed via software tweaks. "Kinda" because I don't remember whether the fix included changing BIOS/UEFI settings or just the kernel/driver tweaks. Besides, the OP here has confirmed it works with Ubuntu.

[paulzeye]

Hi Tyman,
I think you're right- this does seem to be a hardware problem. The NUC has an option for Network boot in the BIOS. I've selected this to test network connectivity and am not able to establish link with this setting either. Somehow this hardware failure happened with my reinstall so I thought they were related somehow.

Thanks everyone for help and suggestions.

Paul