Ubuntu 18.04 - Ethernet desconectada después de suspender

Ethernet no se reanuda después de suspender.

sudo service network-manager restart

No funciona. Solo reiniciar resuelve el problema.

El principal error de Ubuntu que rastrea este problema, al menos para el módulo de kernel de red r8169, parece ser:

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

Animo a todos los afectados por este problema a que vayan allí y marquen que lo afecta a usted, para que los encargados del mantenimiento tengan una mejor idea de lo grave que es.

Estoy ejecutando una nueva instalación de Xubuntu 18.04, y mi interfaz Ethernet utiliza el módulo de kernel r8169 , que descubrí que se ejecutaba:

sudo lshw -C network

Habrá 2 grupos de información, uno que comienza con description: Ethernet interfaceotro description: Wireless interface. Debajo description: Ethernet interface, busca una línea que comience configuration:, como esta:

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

El conductor estará aquí: driver=.

Systemd se ejecuta todos los scripts ejecutables bajo /lib/systemd/system-sleepantes y después de suspender, pasando de 2 parámetros, $1es el estado ( preantes de suspender o post, después de suspender), y $2es la acción ( suspend, hibernate, hybrid-state, o suspend-then-hibernate). Esto está documentado en la página del manual para systemd-suspend.service.

Necesitamos volver a cargar el módulo para la interfaz Ethernet cuando reanudemos la suspensión, después de suspender. Entonces creé el 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

y lo hizo ejecutable:

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

Los mensajes registrados desde el script irán a /var/log/syslogetiquetados con el nombre del script y su PID. De esta manera puede verificar si el script volvió a cargar el módulo del kernel:

grep r8169-refresh /var/log/syslog

Aquí hay otra solución simple (r?): Cree un servicio systemd cuya única tarea sea descargar / recargar el módulo después de un ciclo de suspensión (lo llamé /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

¡Entonces solo ejecuta systemctl enable fix-r8169.service, y deberías estar listo! Systemd ahora descargará y volverá a cargar automáticamente su módulo al despertar de la suspensión.

¡Aclamaciones!

También me pasó a mí.

Descargar / recargar los módulos / controladores del kernel de red funciona.

El mío es r8169, entonces (como root): (escribí a mano, así que hubo un retraso)

sudo modprobe -r r8169
sudo modprobe -i r8169

También eliminé mii durante mi primer intento. Aunque no es necesario.

Tuve el mismo problema y encontré esta solución.

1. ejecutar: sudo lshw -C network
   para encontrar su módulo de núcleo de tarjeta de red

   En * -network, descripción: interfaz Ethernet, en el campo de configuración encontrado
   driver=sky2para mí. sky2 es un módulo de kernel de red ethernet para mi computadora portátil.
   

2. Creo un archivo sky2.sh en: /lib/systemd/system-sleep/ carpeta con

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

   y cambie los permisos con:

   sudo chmod a+x sky2.sh
   

Después de eso, el problema se resolvió.

¿Detecta la conexión Ethernet?

luego

abierto NetworkManager.conf

sudo nano /etc/NetworkManager/NetworkManager.conf

Comente (agregue #) el dns=dnsmasq

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

[ifupdown]
managed=true

Reiniciar el administrador de red

sudo service network-manager restart

Resolví este problema en mi Ubuntu 18.04 Bionic actualizando el kernel de 4.15 a 4.20 (la última el 16.01.2019) usando UKUU

para instalar el último kernel instale Ubuntu Kernel Update Utility

sudo add-apt-repository ppa:teejee2008/ppa

sudo apt-get install ukuu

deshabilite el control de acceso con el siguiente comando:

sudo xhost +

luego instalar con ukuu

sudo ukuu

sudo ukuu --install-latest

y reiniciar

sudo reboot

Presione Ctrl+ Alt+ Tpara ir a una terminal y escriba:

sudo apt-get purge tlp

o

editar /etc/default/tlpy cambiar:

WOL_DISABLE = NO

a

WOL_DISABLE = YES

No tengo suficiente reputación para comentar o votar la respuesta aceptada (que ahora está desactualizada)

Si ejecuta lsmod | grep r8169y muestra que tiene el módulo de kernel r8169 cargado y su kernel es anterior a 4.15.0-24-generic, lo más probable es que se vea afectado por el error vinculado en la respuesta aceptada https: //bugs.launchpad. net / ubuntu / + source / linux / + bug / 1752772

Por cierto, experimenté este error y para mí lspci | grep 'Gigabit Ethernet'muestra RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller

Este error se ha corregido.

Si su núcleo es anterior a 4.15.0-24-genérico, simplemente ejecute

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

Tuve el mismo problema pero las soluciones aquí no funcionaron para mí. Pasé días revisando varios foros sobre este tema y probé casi todo. Se mencionan dos soluciones alternativas, actualizar el kernel o instalar el controlador del módulo anterior. Elegí este último e instalé el controlador r8168. Inicialmente, eso también falló. Sin embargo, descubrí algo que funciona y lo adapté a la solución de Paulo.

Estoy ejecutando (K) ubuntu 18.04 con Kernel 4.15.0-24-generic.

La salida de la red lshw -C incluye esto ...

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

Instalé el paquete r8168-dkms , sin embargo, eso no fue suficiente. Se requieren dos pasos adicionales.

Paso 1) Edite el archivo /etc/modprobe.d/r8168-dkms.conf y habilite la línea (es decir, elimine el comentario) lista negra r8169

Paso 2) Basado en la solución de Paulo, creé el siguiente script / lib / systemd / system-sleep / r8168-refresh

#! / bin / bash

PROGNAME = $ (nombre base "$ 0")
estado = $ 1
acción = $ 2

registro de funciones {
    logger -i -t "$ PROGNAME" "$ *"
}

log "Ejecutando $ action $ state"

if [[$ state == post]]; luego
     log "ifconfig down enp5s0"
     ifconfig enp5s0 abajo
     log "ifconfig up enp5s0"
     ifconfig enp5s0 192.168.10.213
fi

Por supuesto, este código es específico de mi máquina (nombre del dispositivo y dirección IP). Ciertamente podría mejorarse, pero satisface mis necesidades en este momento.

Esto funciona con NetworkManager.

Esto también me sucedió con una placa base Gigabyte-B250M-DS3H después de actualizar Ubuntu 16.04 a 18.04 el 28 de julio de 2018. El kernel es 4.15.0-29-genérico.

El resultado sudo lshw -C networkmostró el controlador Gigabit Ethernet RTL8111 / 8168/8411 PCI Express, mientras que mostró que r8169 es el controlador utilizado.

Lo que finalmente funcionó fue instalar el controlador específico para el controlador Ethernet (gran sorpresa):

sudo apt install r8168-dkms

y luego reiniciando la computadora (Thanks andypotter). No tuve que poner en la lista negra r8169, pero aún así tuve que crear un script en el /lib/systemd/system-sleep/que llamé r8168-refresh-after-suspend(un consejo de la Paulo) que eliminaría y volvería a insertar 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

y, por supuesto, hacerlo ejecutable con:

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

Esto funcionó a las mil maravillas. Entonces, esto sigue siendo un problema en el kernel 4.15.0-29, pero la corrección de la curita todavía funciona.

Tengo el mismo problema (controlador = r8169), Ethernet no funciona después de reanudar la suspensión.

Funciona perfectamente bien con el kernel 4.13.0-31. En otras palabras, Ethernet continúa funcionando después de reanudar la suspensión.

Pero con el kernel 4.15.0-32, Ethernet no funciona después de reanudar la suspensión. He intentado la solución

modprobe -r r8169
modprobe -i r8169

Pero esto no tiene ningún efecto.

He informado esto a https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1752772

Lo primero que debe verificar: reinicie el administrador / servicio de red:

reinicio de sudo service network-manager

Si no funciona, verifique otras respuestas en esta publicación

¡Denote que las varias secuencias de comandos del archivo Fix (modificadas a mi adaptador Ethernet) en /lib/systemd/system-sleep/cada una funcionan!

Sin embargo, si el dispositivo de cable módem se apaga después de Suspender y se vuelve a encender después de Reanudar sistema, el sistema basado en Ubuntu no puede volver a conectarse a Internet, a pesar de que el icono de red (en el área de notificación) muestra la conexión Activada.

Para solucionarlo nuevamente, debo hacer clic en el icono de red »Conexión Ethernet. Por lo tanto, actualiza la conexión con éxito. 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

PD Parece que algunas CLI de vpn dejan de funcionar después de regresar de Suspension.

Tuve los mismos problemas con mi Dell Inspiron 15: no hay red cableada después de reiniciar o suspender.

Parece que he solucionado esto cambiando una configuración en el BIOS:

Avanzado -> Tecnología Intel (R) Smart Connect -> Desactivado

(el valor predeterminado es Enabled)

Como efecto secundario, el elemento del menú ha desaparecido, para aparecer nuevamente después de restablecer todas las configuraciones a los valores predeterminados.