Red Hat Bugzilla – Bug 1259908
Wired eth not connecting after reboot
Last modified: 2016-07-19 15:18:02 EDT
User-Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/45.0.2454.85 Safari/537.36
After a reboot I was no longer able to connect to my wired eth, this happens in all kernels currently on my system, however other OSs will connect to the network. I have checked to ensure that it should connect, and even attempted to manually configure the connection, but in dmesg will only see that the nic is up and then the next entry will state that it is down.
Steps to Reproduce:
1. Plug in wired eth
2. fail to connect to network
Network Manager turns the port off and will attempt to connect every few moments.
Connect to network
Linux cwelker 4.1.6-200.fc22.x86_64 #1 SMP Mon Aug 17 19:54:31 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
lspci | grep Ethernet
00:19.0 Ethernet controller: Intel Corporation Ethernet Connection I217-LM (rev 04)
[ 2.382386] e1000e 0000:00:19.0 eno1: renamed from eth0
[ 17.417893] IPv6: ADDRCONF(NETDEV_UP): eno1: link is not ready
[ 17.620920] IPv6: ADDRCONF(NETDEV_UP): eno1: link is not ready
[ 20.506491] e1000e: eno1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
[ 20.506553] IPv6: ADDRCONF(NETDEV_CHANGE): eno1: link becomes ready
[ 175.743614] e1000e: eno1 NIC Link is Down
[ 180.850462] e1000e: eno1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
[89480.115023] e1000e: eno1 NIC Link is Down
[89483.325735] IPv6: ADDRCONF(NETDEV_UP): eno1: link is not ready
[89587.173331] e1000e: eno1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
[89587.173364] IPv6: ADDRCONF(NETDEV_CHANGE): eno1: link becomes ready
[89657.984972] e1000e: eno1 NIC Link is Down
[89690.273119] e1000e: eno1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
Please provide us with more information so that we can analyze the problem.
$ rpm -q NetworkManager
$ nmcli device
$ nmcli con
* NetworkManager logs (e.g. journal -b 0 -u NetworkManager)
How did you configure the connection manually? What happens when you activate connection using an applet or 'nmcli con up <your profile name>'?
Created attachment 1070308 [details]
output from journalctl -b 0 -u NetworkManager
[cwelker@cwelker ~]$ rpm -q NetworkManager
[cwelker@cwelker ~]$ nmcli device
DEVICE TYPE STATE CONNECTION
virbr0 bridge connected virbr0
virbr0-nic tap connected virbr0-nic
tun0 tun connected tun0
wlp3s0 wifi connected Claremont-WPA
eno1 ethernet connecting (getting IP configuration) Wired connection 1
virbr1 bridge disconnected --
lo loopback unmanaged --
virbr1-nic tap unmanaged --
[cwelker@cwelker ~]$ nmcli connection
NAME UUID TYPE DEVICE
virbr0-nic 46c675bf-0f32-4971-a7ee-2dc04d34d48d generic virbr0-nic
virbr0 4ca47e12-2c95-4a29-8308-70d8c2c32e8e bridge virbr0
FoothillEye-Gldr b6fc4c0a-86bd-4691-9e13-cb21f13644cd 802-11-wireless --
The Welker's 06eab0bb-b178-4e12-823d-6c6d80148af3 802-11-wireless --
Weathertop-5G 48bc7def-224f-4766-a5de-6c434db339c7 802-11-wireless --
Starbucks WiFi b28307c3-db02-4f05-931c-e4a68e82bd89 802-11-wireless --
FoothillEye-Gldr-5G ff73c258-328b-4479-9316-b93cf4fdc48b 802-11-wireless --
tun0 e18f1b0a-acc9-4147-a5aa-3fcb308442a5 generic tun0
Claremont-WPA 827749f2-50f3-4598-96c2-c5b9052d3222 802-11-wireless wlp3s0
Wired connection 1 8e231f0b-464e-4804-a70a-386648103ad2 802-3-ethernet eno1
While troubleshooting more with a live disk (4.0.4-200) I was getting the wired eth to connect, I rebooted into the newest kernel (4.1.6-201.fc22.x86_64) on my normal install and now have my wired eth working again. Nothing more then rebooting was done to the local install.
I have rebooted daily since the issue occurred with no change.
There is a problem with DHCP. There is no answer from DHCP server for DHCPDISCOVER.
Sep 04 07:52:42 cwelker dhclient: DHCPDISCOVER on eno1 to 255.255.255.255 port 67 interval 15 (xid=0xdfb4515c)
Sep 04 07:52:46 cwelker NetworkManager: <warn> (eno1): DHCPv4 request timed out.
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
Thank you for reporting this bug and we are sorry it could not be fixed.