Bug 1259908 - Wired eth not connecting after reboot
Wired eth not connecting after reboot
Status: CLOSED EOL
Product: Fedora
Classification: Fedora
Component: NetworkManager (Show other bugs)
22
x86_64 Linux
unspecified Severity high
: ---
: ---
Assigned To: Lubomir Rintel
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-09-03 14:43 EDT by Christopher Welker
Modified: 2016-07-19 15:18 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-07-19 15:18:02 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
output from journalctl -b 0 -u NetworkManager (5.49 MB, text/x-vhdl)
2015-09-04 10:58 EDT, Christopher Welker
no flags Details

  None (edit)
Description Christopher Welker 2015-09-03 14:43: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
Build Identifier: 

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. 

Reproducible: Always

Steps to Reproduce:
1. Plug in wired eth
2. fail to connect to network
3.
Actual Results:  
Network Manager turns the port off and will attempt to connect every few moments.  

Expected Results:  
Connect to network

uname -a

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)

grep eno1

[    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
Comment 1 Jirka Klimes 2015-09-04 04:35:52 EDT
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>'?
Comment 2 Christopher Welker 2015-09-04 10:58:24 EDT
Created attachment 1070308 [details]
output from journalctl -b 0 -u NetworkManager
Comment 3 Christopher Welker 2015-09-04 10:59:31 EDT
[cwelker@cwelker ~]$ rpm -q NetworkManager

NetworkManager-1.0.2-1.fc22.x86_64

[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
Comment 4 Christopher Welker 2015-09-14 13:15:34 EDT
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.
Comment 5 Jirka Klimes 2015-09-15 04:28:28 EDT
There is a problem with DHCP. There is no answer from DHCP server for DHCPDISCOVER.

Sep 04 07:52:42 cwelker dhclient[29914]: DHCPDISCOVER on eno1 to 255.255.255.255 port 67 interval 15 (xid=0xdfb4515c)
Sep 04 07:52:46 cwelker NetworkManager[1248]: <warn>  (eno1): DHCPv4 request timed out.

[1] http://www.tcpipguide.com/free/t_DHCPLeaseAllocationProcess-2.htm
Comment 6 Fedora End Of Life 2016-07-19 15:18:02 EDT
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
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.