Scheduled Maintenance: We are aware of an issue with Google, AOL, and Yahoo services as email providers which are blocking new registrations. We are trying to fix the issue and we have several internal and external support tickets in process to resolve the issue. Please see: viewtopic.php?t=158230
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.
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.
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.
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!
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?
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.
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.
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.
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.
I am not irrational, I'm just quantum probabilistic.
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.
paulzeye wrote: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.
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.
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.
tynman wrote: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.
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.