Bug 1550701

Summary: Ethernet doesn't work after sleep
Product: [Fedora] Fedora Reporter: Alexander Zaitsev <zamazan4ik>
Component: NetworkManagerAssignee: Lubomir Rintel <lkundrak>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: 28CC: alexl, bgalvani, cooperj10, dcbw, fgiudici, ilochab, john.j5live, lkundrak, mclasen, rhughes, rstrode, sandmann
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-06-21 08:41:40 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:

Description Alexander Zaitsev 2018-03-01 19:52:34 UTC 
Description of problem:
Laptop with Fedora 27 cannot connect via Ethernet to a network after sleep (not hibernation).

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


How reproducible:
Always

Steps to Reproduce:
1. With connected or disconnected Ethernet cable (in my case doesn't matter) turn on sleep mode on a laptop.
2. Turn off sleep mode.
3. Ooops: Ethernet doesn't work. 

Actual results:
There is chance to get workable Ethernet connection after sleep.

Expected results:
Fedora should be able to establish Ethernet connection after sleep.

Additional info:
Laptop model: Asus K55VJ-SX012D
Fedora 27
KDE Plasma 5.11.5
KDE Frameworks 5.43.0
Qt: 5.9.4

lspci | grep Ethernet: 04:00.2 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 0a)

uname -r: 4.15.4-300.fc27.x86_64


On Windows 10 all works fine. Ethernet cable is fine (tested on Windows and on another machine).
Comment 1 Stephen Herr 2018-05-26 20:58:24 UTC 
I also have this problem with Fedora 28. Let me know if you need any more troubleshooting information.

$ lspci | grep Ethernet
05:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 06)
Comment 2 Stephen Herr 2018-05-27 04:54:50 UTC 
A workaround seems to be to remove and reload the r8169 module after a sleep. This can be done automatically by creating a script for systemd to call:

$ sudo cat <<EOF > /usr/lib/systemd/system-sleep/fix_network
#!/bin/sh

case "$1" in
    pre)
        modprobe -r r8169
        ;;
    post)
        modprobe r8169
        ;;
esac
EOF

$ sudo chmod +x /usr/lib/systemd/system-sleep/fix_network

Thanks for the idea goes to Steven Rosenberg at:
http://stevenrosenberg.net/blog/linux/fedora/2015_0928_working_on_my_networking_after_suspend_resume_issue_in_fedora_22
Comment 3 Beniamino Galvani 2018-05-28 07:41:20 UTC 
This looks similar to bug 1580079. Can you please show the output of 'ip l' and 'dmesg' after resume from sleep?
Comment 4 Beniamino Galvani 2018-06-21 08:41:40 UTC 
Closing, please reopen if needed.

*** This bug has been marked as a duplicate of bug 1580079 ***
Comment 5 Alexander Zaitsev 2018-07-08 12:07:18 UTC 
Since 4.17 kernel workaround from Stephen Herr doesn't work and I should restart compute for Ethernet enabling.
Comment 6 John Cooper 2018-07-12 15:01:45 UTC 
I am seeing this for the first time at Fedora 28 in Kernel 4.17. Switch to 4.16 and the ethernet resumes from sleep as expected.

02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 0c)

Can you please reopen this as the duplicate is old and has been closed anyway.
Comment 7 Licia Leanza 2018-11-25 14:20:10 UTC 
I have the same problem on my:

Sony Vaio Vpcz21c5e
Fedora 29
4.19.2-301.fc29.x86_64
19:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 06)

I have a workaround that is unplug and plug again the rj45 connector but it's really boring
Comment 8 Licia Leanza 2018-11-25 22:46:04 UTC 
Followup to my previous note:

with kernel 4.18.18-300.fc29.x86_64 the problem doesn't occur.