Bug 2188321

Summary: Wire bound ethernet interface staying "down" after shutting lid of laptop
Product: Red Hat Enterprise Linux 9 Reporter: Dr. Stephan Wonczak <wonczak>
Component: NetworkManagerAssignee: NetworkManager Development Team <nm-team>
Status: CLOSED UPSTREAM QA Contact: Beniamino Galvani <bgalvani>
Severity: medium Docs Contact:
Priority: unspecified    
Version: CentOS StreamCC: bgalvani, bstinson, jwboyer, lrintel, rkhan, sfaye, sukulkar, thaller, till
Target Milestone: rc   
Target Release: ---   
Hardware: x86_64   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2023-07-03 07:55:50 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
log of lid close/open cycle with NM-TRACE enabled none

Description Dr. Stephan Wonczak 2023-04-20 13:12:10 UTC 
Description of problem:

When closing the lid of my laptop (Dell Latitude 5530) to send it to sleep, and after opening and resuming, the ethernet interface stays "down" instead of being set to "up" automatically. Doing "ifconfig enp0s31f6 up" manually gives me an active connection immediately.

Version-Release number of selected component (if applicable):

NetworkManager-1.43.4-1.el9.x86_64
(nb: I am -not- quite whether NetworkManager really is the culprit here!)
Kernel 5.14.0-299.el9.x86_64

How reproducible:

Always

Steps to Reproduce:
1. Close lid of laptop, wait for half a minute
2. Open lid
3. check for connectivity status of ethernet port

Actual results:

  Port is reported "down"

Expected results:

  Port will be automatically set to "up"

Additional info:
Hardware is Dell Latitude 5530
Ethernet controller: Intel Corporation Ethernet Connection (16) I219-LM (rev 01)
Kernel: 5.14.0-299.el9.x86_64 (Problem is present for previous versions, too)
This internet connection has the checkbox for "automatically reconnect" set, but for some reason it does not do so.
Comment 1 Thomas Haller 2023-04-20 14:50:06 UTC 
after opening the lid and having the problem, what gives:

  - ip link
  - ip addr
  - nmcli device
  - nmcli connection


Also, if possible, please provide a complete `level=TRACE` log of NetworkManager. Read "DEBUGGING" section in `man NetworkManager.conf` for how to do that (or ask if something is unclear). Thanks.
Comment 2 Thomas Haller 2023-04-20 14:51:15 UTC 
(In reply to Thomas Haller from comment #1)
> Read "DEBUGGING" section in `man NetworkManager.conf` for
> how to do that

I meant `man NetworkManager`
Comment 3 Dr. Stephan Wonczak 2023-04-21 11:18:27 UTC 
Here is the output of the four commands -before- closing the lid:

[root@mycroft~]$ ip link show enp0s31f6
2: enp0s31f6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
    link/ether c8:4b:d6:05:44:d8 brd ff:ff:ff:ff:ff:ff
[root@mycroft~]$ ip addr show enp0s31f6
2: enp0s31f6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether c8:4b:d6:05:44:d8 brd ff:ff:ff:ff:ff:ff
    inet 134.95.128.44/24 brd 134.95.128.255 scope global dynamic noprefixroute enp0s31f6
       valid_lft 81747sec preferred_lft 81747sec
    inet6 2a00:a200:0:6f0:ca4b:d6ff:fe05:44d8/64 scope global dynamic noprefixroute 
       valid_lft 2591910sec preferred_lft 604710sec
    inet6 fe80::ca4b:d6ff:fe05:44d8/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
[root@mycroft~]$ nmcli device
DEVICE             TYPE      STATE                   CONNECTION 
enp0s31f6          ethernet  connected               enp0s31f6  
lo                 loopback  connected (externally)  lo         
40:4E:36:54:40:30  bt        disconnected            --         
wlp0s20f3          wifi      unavailable             --         
[root@mycroft~]$ nmcli connection
NAME               UUID                                  TYPE       DEVICE    
enp0s31f6          9adbe91b-e49c-4512-bd43-43689210257c  ethernet   enp0s31f6 
lo                 b94f9202-5880-4168-a10e-132f7467d8bf  loopback   lo        
Lestrade-Netzwerk  ae1057ea-c487-4dc4-b36d-34bb54b3b2a0  bluetooth  --        
eduroam            07eca463-0e2f-4f9f-ae4c-1af360293d4c  wifi       --        


And here is -after- closing/opening the lid:

[root@mycroft~]$ ip link show enp0s31f6
2: enp0s31f6: <BROADCAST,MULTICAST> mtu 1500 qdisc fq_codel state DOWN mode DEFAULT group default qlen 1000
    link/ether c8:4b:d6:05:44:d8 brd ff:ff:ff:ff:ff:ff
[root@mycroft~]$ ip addr show enp0s31f6
2: enp0s31f6: <BROADCAST,MULTICAST> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
    link/ether c8:4b:d6:05:44:d8 brd ff:ff:ff:ff:ff:ff
[root@mycroft~]$ nmcli device
DEVICE             TYPE      STATE                   CONNECTION 
lo                 loopback  connected (externally)  lo         
40:4E:36:54:40:30  bt        disconnected            --         
enp0s31f6          ethernet  unavailable             --         
wlp0s20f3          wifi      unavailable             --         
[root@mycroft~]$ nmcli connection
NAME               UUID                                  TYPE       DEVICE 
lo                 b94f9202-5880-4168-a10e-132f7467d8bf  loopback   lo     
Lestrade-Netzwerk  ae1057ea-c487-4dc4-b36d-34bb54b3b2a0  bluetooth  --     
eduroam            07eca463-0e2f-4f9f-ae4c-1af360293d4c  wifi       --     
enp0s31f6          9adbe91b-e49c-4512-bd43-43689210257c  ethernet   --     

I then collected a debug/trace log for a Lid close/open-cycle, as instructed (attached to this bug report).
A few comments on the log: I enabled TRACE mode for NM, closed the lid, waited a bit and opened it again. After waiting for about a minute, I set NM logging to INFO again. Shortly after I did "ifconfig enp0s31f6 up" by hand, since it did not come online automatically. All this should be captured in the log.

If there is anything else I can do to help with debugging, don't hesitate to ask!
Comment 4 Dr. Stephan Wonczak 2023-04-21 11:19:40 UTC 
Created attachment 1958795 [details]
log of lid close/open cycle with NM-TRACE enabled
Comment 5 Thomas Haller 2023-04-21 12:12:59 UTC 
(In reply to Dr. Stephan Wonczak from comment #3)
> Here is the output of the four commands -before- closing the lid:
> ...
> 2: enp0s31f6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
> ...
> And here is -after- closing/opening the lid:
> 
> [root@mycroft~]$ ip link show enp0s31f6
> 2: enp0s31f6: <BROADCAST,MULTICAST> mtu 1500 qdisc fq_codel state DOWN mode DEFAULT group default qlen 1000
> ...
> [root@mycroft~]$ nmcli device
> DEVICE             TYPE      STATE                   CONNECTION 
> enp0s31f6          ethernet  unavailable             --         


as you see, carrier (LOWER_UP) is no longer there. Kernel thinks that the cable ins unplugged, and NetworkManager won't autoconnect a profile.

That could be for example caused by wrong autonegotiation/speed/duplex settings. More likely it's a driver issue.

Can you try to find out why the interface appears unplugged?
Comment 6 Thomas Haller 2023-04-21 12:16:40 UTC 
(In reply to Thomas Haller from comment #5)
> (In reply to Dr. Stephan Wonczak from comment #3)
> > Here is the output of the four commands -before- closing the lid:
> > ...
> > 2: enp0s31f6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
> > ...
> > And here is -after- closing/opening the lid:
> > 
> > [root@mycroft~]$ ip link show enp0s31f6
> > 2: enp0s31f6: <BROADCAST,MULTICAST> mtu 1500 qdisc fq_codel state DOWN mode DEFAULT group default qlen 1000
> > ...
> > [root@mycroft~]$ nmcli device
> > DEVICE             TYPE      STATE                   CONNECTION 
> > enp0s31f6          ethernet  unavailable             --         
> 
> 
> as you see, carrier (LOWER_UP) is no longer there. Kernel thinks that the
> cable ins unplugged, and NetworkManager won't autoconnect a profile.
> 
> That could be for example caused by wrong autonegotiation/speed/duplex
> settings. More likely it's a driver issue.
> 
> Can you try to find out why the interface appears unplugged?

oh no. Sorry, totally wrong.

The interface is also down (no "UP"). Seems NetworkManager is setting it down:

  <debug> [1682075300.1228] platform-linux: link: change 2: flags: set 0x0/0x1 ([] / [up])

but not up again???
Comment 7 Dr. Stephan Wonczak 2023-04-21 12:47:18 UTC 
Yes, this behaviour looks -really- strange. Even more so, since doing nothing but "ifconfig enp0s31f6 up" brings it back online in a few moments.
(I should mention that this specific ethernet hardware did have a driver issue in older kernels. See here: https://bugzilla.redhat.com/show_bug.cgi?id=2115237)
Comment 8 Dr. Stephan Wonczak 2023-05-10 11:07:08 UTC 
Any further ideas on this issue? Or anything I can do to help with further debugging?
Since the original report there have been updates of both kernel and NetworkManager, but the issue still persists.
NetworkManager-1.43.7-1.el9.x86_64
Kernel 5.14.0-307.el9.x86_64
Comment 9 Beniamino Galvani 2023-05-10 11:36:02 UTC 
Hi, it is a regression in NM 1.43; there is a merge request to fix it at https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1624
Comment 10 Dr. Stephan Wonczak 2023-05-25 11:53:10 UTC 
To report back:
NetworkManager-1.43.8-1.el9.x86_64
arrived today. With this version the reported issue is fixed. Wire connection comes online again after closing/opening the laptop lid.

Bug can be marked as resolved.
Comment 11 sfaye 2023-07-03 07:55:50 UTC 
Closing based on comment 10.