Ubuntu 18.04 - Ethernet déconnecté après suspension

Ethernet ne reprend pas après la suspension.

sudo service network-manager restart

ne marche pas. Seul le redémarrage résout le problème.

Le bogue principal d'Ubuntu qui suit ce problème, au moins pour le module de noyau réseau r8169, semble être:

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1752772

J'encourage tous ceux qui sont concernés par ce problème à y aller et à marquer que cela vous affecte, afin que les responsables aient une meilleure idée de la gravité du problème.

J'exécute une nouvelle installation de Xubuntu 18.04, et mon interface Ethernet utilise le module de noyau r8169 , que j'ai découvert en cours d'exécution:

sudo lshw -C network

Il y aura 2 groupes d'informations, l'un commençant par description: Ethernet interfaceet l'autre avec description: Wireless interface. Sous description: Ethernet interface, recherchez une ligne commençant par configuration:, comme ceci:

configuration: autonegotiation=on broadcast=yes driver=r8169 driverversion=2.3LK-NAPI duplex=full firmware=rtl_nic/rtl8105e-1.fw ip=192.168.100.6 latency=0 link=yes multicast=yes port=MII speed=100Mbit/s

Le pilote sera ici: driver=.

Systemd exécute tous les scripts exécutables sous /lib/systemd/system-sleepavant et après suspension, passer 2 paramètres, $1est l'état ( pre, suspendre avant, ou post, suspendre après), et $2est l'action ( suspend, hibernate, hybrid-stateou suspend-then-hibernate). Ceci est documenté dans la page de manuel de systemd-suspend.service.

Nous devons recharger le module pour l'interface Ethernet lors de la reprise de la suspension, après la suspension. J'ai donc créé un script /lib/systemd/system-sleep/r8169-refresh:

#!/bin/bash

PROGNAME=$(basename "$0")
state=$1
action=$2

function log {
    logger -i -t "$PROGNAME" "$*"
}

log "Running $action $state"

if [[ $state == post ]]; then
    modprobe -r r8169 \
    && log "Removed r8169" \
    && modprobe -i r8169 \
    && log "Inserted r8169"
fi

et l'a rendu exécutable:

chmod +x /lib/systemd/system-sleep/r8169-refresh

Les messages consignés à partir du script seront /var/log/syslogétiquetés avec le nom du script et son PID. De cette façon, vous pouvez vérifier si le script a rechargé le module du noyau:

grep r8169-refresh /var/log/syslog

Voici une autre solution simple (r?): Créer un service systemd dont la seule tâche est de décharger / recharger le module après un cycle de suspension (je l'ai nommé /etc/systemd/system/fix-r8169.service ):

[Unit]
Description=Fix RTL-8169 Driver on resume from suspend
After=suspend.target

[Service]
User=root
Type=oneshot
ExecStartPre=/sbin/modprobe -r r8169
ExecStart=/sbin/modprobe r8169
TimeoutSec=0
StandardOutput=syslog

[Install]
WantedBy=suspend.target

Ensuite systemctl enable fix-r8169.service, exécutez simplement , et vous devriez être prêt !! Systemd déchargera et rechargera automatiquement votre module au réveil de la suspension.

À votre santé!

Ça m'est aussi arrivé.

Décharger / recharger les modules / pilotes du noyau réseau fonctionne.

Le mien est r8169, donc (en tant que root): (j'ai tapé à la main, donc il y a eu un retard)

sudo modprobe -r r8169
sudo modprobe -i r8169

J'ai également supprimé mii lors de mon premier essai. Pas nécessaire cependant.

J'ai eu le même problème et j'ai trouvé cette solution.

1. run: sudo lshw -C network
   pour trouver votre module de noyau de carte réseau

   Dans * -réseau, description: interface Ethernet, dans le champ de configuration trouvé
   driver=sky2pour moi. sky2 est un module de noyau de réseau Ethernet pour mon ordinateur portable.
   

2. Je crée un fichier sky2.sh dans: /lib/systemd/system-sleep/ dossier avec

   #!/bin/bash 
   modprobe -r sky2 # unload sky2 kernel module 
   modprobe -i sky2 # reload sky2 kernel module 
   

   et modifiez les autorisations avec:

   sudo chmod a+x sky2.sh
   

Après cela, le problème a été résolu.

Il détecte la connexion Ethernet?

puis

ouvrir NetworkManager.conf

sudo nano /etc/NetworkManager/NetworkManager.conf

Commenter (Ajouter #) le dns=dnsmasq

[main]
plugins=ifupdown,keyfile,ofono
#dns=dnsmasq

[ifupdown]
managed=true

Redémarrez le gestionnaire de réseau

sudo service network-manager restart

j'ai résolu ce problème sur mon Ubuntu 18.04 Bionic en mettant à jour le noyau de 4.15 à 4.20 (la dernière le 16.01.2019) en utilisant UKUU

pour installer le dernier noyau installer Ubuntu Kernel Update Utility

sudo add-apt-repository ppa:teejee2008/ppa

sudo apt-get install ukuu

désactiver le contrôle d'accès avec la commande suivante:

sudo xhost +

puis installez avec ukuu

sudo ukuu

sudo ukuu --install-latest

et redémarrer

sudo reboot

Appuyez sur Ctrl+ Alt+ Tpour accéder à un terminal et saisissez:

sudo apt-get purge tlp

ou

éditer /etc/default/tlpet changer:

WOL_DISABLE = NO

à

WOL_DISABLE = YES

Je n'ai pas assez de réputation pour commenter ou voter pour la réponse acceptée (qui est désormais obsolète)

Si vous exécutez lsmod | grep r8169et cela montre que le module du noyau r8169 est chargé et que votre noyau est plus ancien que 4.15.0-24-generic, vous êtes très probablement affecté par le bogue lié dans la réponse acceptée https: //bugs.launchpad. net / ubuntu / + source / linux / + bug / 1752772

BTW j'ai connu ce bug et pour moi lspci | grep 'Gigabit Ethernet'montre RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller

Ce bug a été corrigé.

Si votre noyau est plus ancien que 4.15.0-24-générique, lancez simplement

apt-get update
apt-get upgrade
apt-get dist-upgrade
reboot

J'ai eu le même problème mais les solutions ici n'ont pas fonctionné pour moi. J'ai passé des jours à parcourir plusieurs forums sur ce sujet et j'ai essayé à peu près tout. Deux solutions alternatives sont mentionnées, mettez à niveau le noyau ou installez le pilote de module précédent. J'ai choisi ce dernier et installé le pilote r8168. Au départ, cela a également échoué. Cependant, j'ai découvert quelque chose qui fonctionne et je l'ai adapté à la solution de Paulo.

J'utilise (K) ubuntu 18.04 avec Kernel 4.15.0-24-generic.

La sortie du réseau lshw -C inclut ceci ...

description: Ethernet interface
   product: RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller
   vendor: Realtek Semiconductor Co., Ltd.
   physical id: 0
   bus info: pci@0000:05:00.0
   logical name: enp5s0
   version: 0c
   serial: 80:fa:5b:49:69:b3
   size: 1Gbit/s
   capacity: 1Gbit/s
   width: 64 bits
   clock: 33MHz
   capabilities: pm msi pciexpress msix vpd bus_master cap_list ethernet physical tp 10bt 10bt-fd 100bt 100bt-fd 1000bt-fd autonegotiation
   configuration: autonegotiation=on broadcast=yes driver=r8168 driverversion=8.045.08-NAPI duplex=full ip=192.168.10.213 latency=0 link=yes multicast=yes port=twisted pair speed=1Gbit/s
   resources: irq:133 ioport:e000(size=256) memory:df000000-df000fff memory:d0000000-d0003fff

J'ai installé le package r8168-dkms , mais ce n'était pas suffisant. Deux étapes supplémentaires ont été nécessaires.

Étape 1) Modifiez le fichier /etc/modprobe.d/r8168-dkms.conf et activez la ligne (c.-à-d. Supprimez le commentaire) blacklist r8169

Étape 2) Sur la base de la solution de Paulo, j'ai créé le script suivant / lib / systemd / system-sleep / r8168-refresh

#! / bin / bash

PROGNAME = $ (nom de base "$ 0")
état = 1 $
action = 2 $

journal de fonction {
    enregistreur -i -t "$ PROGNAME" "$ *"
}

journal "Exécution de $ action $ state"

if [[$ state == post]]; puis
     log "ifconfig down enp5s0"
     ifconfig enp5s0 down
     log "ifconfig up enp5s0"
     ifconfig enp5s0 192.168.10.213
Fi

Ce code est bien sûr spécifique à ma machine (nom d'appareil et adresse IP). Il pourrait certes être amélioré mais il répond à mes besoins en ce moment.

Cela fonctionne avec NetworkManager.

Cela m'est également arrivé avec une carte mère Gigabyte-B250M-DS3H après la mise à niveau d'Ubuntu 16.04 vers 18.04 le 28 juillet 2018. Le noyau est 4.15.0-29-générique.

Le résultat du sudo lshw -C networkcontrôleur Ethernet Gigabit Ethernet PCI Express RTL8111 / 8168/8411 a été montré, tandis qu'il a montré que le r8169 est le pilote utilisé.

Ce qui a finalement fonctionné, c'est l'installation du pilote spécifique au contrôleur Ethernet (grosse surprise):

sudo apt install r8168-dkms

puis redémarrer l'ordinateur (Merci etypotter). Je n'ai pas eu à mettre la liste noire r8169 en liste noire, mais j'ai quand même dû créer un script dans /lib/systemd/system-sleep/lequel j'ai appelé r8168-refresh-after-suspend(un conseil de la Paulo) qui supprimerait et réinsérerait la r8168:

#!/bin/bash

# $1 is the state (pre or post)
# $2 is the action (suspend)

case $1/$2 in
pre/suspend)
  modprobe -r r8168
;;
post/suspend)
  modprobe -i r8168
;;
esac

et, bien sûr, le rendre exécutable avec:

sudo chmod +x /lib/systemd/system-sleep/r8168-refresh-after-suspend

Cela a fonctionné comme un charme. Donc, c'est toujours un problème dans le noyau 4.15.0-29, mais le correctif de pansement fonctionne toujours.

J'ai le même problème (pilote = r8169), Ethernet ne fonctionne pas après la reprise de la suspension.

Cela fonctionne parfaitement avec le noyau 4.13.0-31. En d'autres termes, l'Ethernet continue de fonctionner après la reprise de la suspension.

Mais avec le noyau 4.15.0-32, Ethernet ne fonctionne pas après la reprise de la suspension. J'ai essayé le correctif

modprobe -r r8169
modprobe -i r8169

mais cela n'a aucun effet.

Je l'ai signalé à https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1752772

Première chose à vérifier: redémarrez le gestionnaire / service réseau:

redémarrage du gestionnaire de réseau du service sudo

Si cela ne fonctionne pas, vérifiez les autres réponses dans ce post

Je signale que le script de plusieurs fichiers Fix (modifié pour mon adaptateur Ethernet) sur /lib/systemd/system-sleep/chacun fonctionne!

Néanmoins, si le périphérique modem câble est éteint après la suspension et que celui-ci est réactivé après la reprise du système, le système basé sur Ubuntu ne peut pas se reconnecter à Internet, malgré l'icône de réseau (dans la zone de notification) indiquant la connexion activée.

Pour le réparer à nouveau, je dois cliquer sur l'icône réseau »Connexion Ethernet. Ainsi, il rafraîchit la connexion avec succès. X-

Ethernet controller: VIA Technologies, Inc. VT6105/VT6106S [Rhine-III] 
    Subsystem: D-Link System Inc DFE-520TX Fast Ethernet PCI Adapter 
    Kernel driver in use: via-rhine
    Kernel modules: via_rhine

PS Il semble que certains CLI de vpn cessent de fonctionner après leur retour de Suspension.

J'ai eu les mêmes problèmes avec mon Dell Inspiron 15: pas de réseau câblé après le redémarrage ou la suspension.

Il me semble avoir corrigé cela en changeant un paramètre dans le BIOS:

Avancé -> Technologie Intel (R) Smart Connect -> Désactivé

(par défaut est activé)

En tant qu'effet secondaire, l'élément de menu a disparu, pour réapparaître après avoir réinitialisé tous les paramètres aux valeurs par défaut.