Mise à jour vers 19.04 et NO ETHERNET maintenant
J'utilise une adresse IP statique pour ma connexion filaire contrôlée via Network Manager.
lien ip show enp4s0
2: enp4s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq state DOWN mode DEFAULT group default qlen 1000
NO-CARRIER semblerait indiquer un problème de pilote car je le poste sur le même PC en sélectionnant le noyau précédent 4.18.0.17 dans grub. NetworkManager.service et avahi-daemon.service sont à la fois CHARGÉS et ACTIFS.
Mais NetworkManager n'est pas content comme indiqué ...
NetworkManager[1103]: <info> [1555719488.0396] device (enp4s0): state change: secondaries -> activated (reason 'none', sys-iface-state: 'managed')
NetworkManager[1103]: <info> [1555719488.0402] manager: NetworkManager state is now CONNECTED_LOCAL
NetworkManager[1103]: <info> [1555719488.9594] manager: NetworkManager state is now CONNECTED_SITE
NetworkManager[1103]: <info> [1555719488.9595] policy: set 'LaN' (enp4s0) as default for IPv4 routing and DNS
NetworkManager[1103]: <info> [1555719488.9603] device (enp4s0): Activation: successful, device activated.
NetworkManager[1103]: <info> [1555719488.9609] manager: NetworkManager state is now CONNECTED_GLOBAL
NetworkManager[1103]: <info> [1555719488.9616] manager: startup complete
NetworkManager[1103]: <info> [1555719495.0373] device (enp4s0): state change: activated -> unavailable (reason 'carrier-changed', sys-iface-state: 'managed')
NetworkManager[1103]: <info> [1555719495.0583] manager: NetworkManager state is now DISCONNECTED
NetworkManager[1103]: <info> [1555719505.6899] agent-manager: req[0x55c9724642a0, :1.63/org.freedesktop.nm-applet/1000]: agent registered
Serait-ce le mauvais pilote phy sélectionné ou le bug Network Manager?
"ip link set enp4s0 up" n'aide pas.
MISE À JOUR: Après la mise à niveau de mon ordinateur portable d'Ubuntu 19.04 vers Ubuntu 19.10, je n'ai plus ce problème. Je ne l'avais pas pas dans la version 18.10. Il semble donc que cela ne soit présent que dans la version 19.04.
Je poste juste mes observations ici comme réponse. J'espère que je parviendrai finalement à une solution, donc je pourrai mettre à jour cette réponse de manière appropriée.
J'ai le problème exact:
Pendant la mise sous tension, ce problème pas se produit. Mais cela se produit toujours après un redémarrage du système d'exploitation ( redémarrage progressif).
Jusqu'à présent, la seule solution est la suivante: Débranchez le câble Ethernet; démarrez votre machine; rebranchez le câble une fois le démarrage terminé. La connexion Ethernet ne fonctionnera jamais si le câble réseau est branché pendant le démarrage!
J'ai suivi les suggestions dans https://ubuntu-mate.community/t/19-04-ethernet-wired-connection-refuses-to-connect-when-plugged-in-before-boot/19333/8 et comme l'affiche originale là-bas, je n'ai eu aucune amélioration. Voici mes observations et je vous demande ( once_a_NoOb_always_a ) de les vérifier:
Ce problème a commencé après la mise à niveau d'Ubuntu 18.10 vers 19.04. Initialement (lors du premier redémarrage après la mise à niveau), le problème ne s'est pas produit. Mais, plus tard (après le deuxième redémarrage), cela a commencé à se produire de manière persistante.
Si vous démarrez la machine avec le câble Ethernet déconnecté et que vous la connectez après son démarrage, le problème ne se produit pas .
Dans tous les cas, la connexion au niveau de la liaison est réussie (même après avoir déconnecté et reconnecté le câble ou après avoir fait
ip link set enp3s0f1 downetip link set enp3s0f1 up). Je peux voir sur mon routeur que le port Ethernet correspondant est actif et que les paquets voyagent dans les deux sens. Cependant, il se passe quelque chose de très étrange: j'utilise des adresses IP statiques pour ma connexion filaire et sans fil dans ma boîte Ubuntu; ceux-ci se terminent par 14 et 15 respectivement. Lorsque j'active l'interface Ethernet (filaire), mon routeur voit la même adresse IP se terminant par 14 dans les deux interfaces du boîtier Ubuntu.
Ma déduction provisoire est que la pile réseau mélange en quelque sorte les adresses MAC des deux interfaces. (Veuillez noter que normalement mon interface sans fil est désactivée par le matériel lorsque je démarre et utilise mon ordinateur; normalement, je n'utilisais que la connexion filaire. Cependant, même dans un tel scénario, ma boîte Ubuntu mise à niveau ne se connecte pas au réseau Ethernet. semble déconnecter physiquement le câble Ethernet pendant le démarrage et le connecter après le démarrage.)
- J'ai supprimé complètement la connexion câblée (Ethernet) en utilisant nm-connection-editor (avec root utilisateur), puis j'ai recréé la connexion, cette fois en utilisant DHCP au lieu d'une adresse IP statique. Lorsque j'essaie de mettre l'interface en place, mon routeur le fait donne une adresse IP à mon interface ( enp3s0f1), mais Ubuntu n'affiche pas cette IP. Les informations matérielles pour l'interface Ethernet sont les suivantes:
*-network description: Ethernet interface product: RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller vendor: Realtek Semiconductor Co., Ltd. physical id: 0.1 bus info: pci@0000:03:00.1 logical name: enp3s0f1 version: 12 serial: b0:25:aa:2d:91:22 size: 1Gbit/s capacity: 1Gbit/s width: 64 bits clock: 33MHz capabilities: pm msi pciexpress msix vpd bus_master cap_list ethernet physical tp mii 10bt 10bt-fd 100bt 100bt-fd 1000bt-fd autonegotiation configuration: autonegotiation=on broadcast=yes driver=r8169 duplex=full firmware=rtl8411-2_0.0.1 07/08/13 latency=0 link=yes multicast=yes port=MII speed=1Gbit/s resources: irq:18 ioport:3000(size=256) memory:a5c14000-a5c14fff memory:a5c10000-a5c13fff
Il me semble que le nouveau noyau 5.0.0-13 a un logiciel buggé pour cette carte (RTL8411B) :(
@drblah: votre suggestion n'a pas fonctionné pour moi. Les commandes netplan que vous avez mentionnées n'ont aucun effet et le fichier /etc/netplan/01-network-manager-all.yaml n'est pas mis à jour (la date du fichier reste en 18-Oct-2018 avec le même contenu).
J'ai eu un problème similaire (pas d'Ethernet filaire après la mise à niveau vers 19.10). J'ai vécu avec ça pendant un moment et j'ai juste utilisé ifup dans .bashrc. Mais quand j'ai approfondi ce problème, j'ai été dirigé par Google vers cette page.
Cependant, aucune des solutions ci-dessus n'a résolu mon problème. Apparemment, j'ai trouvé la solution lorsque j'ai essayé de passer de ifup à netplan. À ce moment, j'ai réalisé qu'il y avait un paramètre dans la configuration de NetworkManager (/etc/NetworkManager/NetworkManager.conf) qui permet au NetworkManager de contrôler les interfaces. J'avais managed=false Là.
Le changer simplement en:
[ifupdown]
managed=true
création d'un fichier vide:
Sudo touch /etc/NetworkManager/conf.d/10-globally-managed-devices.conf
et redémarrage de NetworkManager:
Sudo systemctl restart NetworkManager
résolu mes problèmes.
J'ai rencontré le même problème que vous. La solution de contournement que j'ai trouvée consistait à faire régénérer la configuration réseau par netplan:
Sudo netplan generate
Sudo netplan apply
Après avoir exécuté les deux commandes, vous devriez pouvoir configurer le réseau avec vos outils de configuration habituels.
Par défaut, netplan aura un fichier de configuration appelé: / etc/netplan/01-network-manager-all.yaml avec le contenu suivant:
# Let NetworkManager manage all devices on this system
network:
version: 2
renderer: NetworkManager
Cela indiquera simplement au système de laisser toutes les interfaces être contrôlées par le gestionnaire de réseau. Je ne sais pas exactement pourquoi cela a fonctionné pour moi, car netplan était déjà censé gérer l'interface réseau.
Pour référence, la sortie de lspci pour mon contrôleur Ethernet est:
$ lspci | grep -i ether
05:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 06)
Même bogue ici, il semble. Le problème est, je pense, provoqué par NetworkManager qui exécute une procédure dhclient incorrecte, et déclenchant des conflits IP dans le commutateur de mon réseau, provoquant une connexion morte pendant environ 30 minutes. Voir aussi ce bug: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/179376
MISE À JOUR: Pour contourner ce problème, vous pouvez utiliser ifplugd avec ifupdown pour gérer les connexions Ethernet, tout en utilisant NetworkManager pour les connexions sans fil. Pour faire ça:
Installez ifupdown et resolvconf:
apt install ifupdown resolvconf
désactiver la résolution de systemd
systemctl stop systemd-resolved
systemctl disable systemd-resolved.service
éditez /etc/NetworkManager/NetworkManager.conf pour laisser les périphériques ifupdown seuls, et utilisez resolvconf pour mettre à jour /etc/resolv.conf, et utilisez des serveurs DNS simples à partir du serveur dhcp au lieu du service 127.0.0.53 résolu par systemd.
[main]
# don't manage devices configured in /etc/network/interfaces
plugins=ifupdown,keyfile
# pass nameserver dhcp config to resolvconf
rc-manager=resolvconf
# use plain nameservers directly from DHCP server instead of intermediate resolved
dns=default
[ifupdown]
managed=false
Ajoutez ensuite les lignes suivantes à/etc/network/interfaces pour définir le périphérique Ethernet (dans mon cas enp0s25)
iface enp0s25 inet dhcp
iface enp0s25 inet6 auto
Assurez-vous qu'il n'y a pas de auto enp0s25 lignes dans le fichier, car ifup ne doit pas être exécuté automatiquement au démarrage, mais par ifplugd lors de la connexion d'une connexion Ethernet.
Installez ensuite ifplugd et configurez-le de sorte que le périphérique enp0s25 soit écouté pour les déclencheurs de connexion/déconnexion corrects
apt install ifplugd
Faites également le fichier /etc/dhcp/dhclient-enter-hooks.d/resolved vide, car sinon resolvconf ne fonctionnera jamais depuis ifupdown:
echo "" > /etc/dhcp/dhclient-enter-hooks.d/resolved
ne supprimez pas non plus ce fichier ou il sera réinstallé lors de la prochaine mise à jour du système.
Enfin, démarrez et activez ifplugd, redémarrez NetworkManager pour une configuration mise à jour.
systemctl restart NetworkManager
systemctl enable ifplugd
systemctl start ifplugd
et/ou redémarrez pour vérifier si tout est correctement configuré.
Disclaimer 1: Je n'ai pas relu ce script sur une nouvelle installation d'ubuntu pour vérifier s'il est complètement correct (cependant j'ai vérifié bash_history;). Veuillez répondre si quelque chose ne fonctionne pas.
Disclaimer 2 cela fonctionne pour Ubuntu LTS 18.04
Disclaimer 3: Peut-être que cela peut aussi fonctionner avec systemd-resolution ou même DNSMasq ou non lié mais je ne sais pas exactement et personnellement je ne le veux pas.
Résolu pour moi en installant dkms pour le pilote pour r8168. Certes, sous le noyau 4.18, le NIC fonctionnait très bien sous r8169, mais pas sous la version "améliorée" du noyau 5.0 utilisée avec kubuntu 19.04.
J'ai eu le même problème sur Debian Buster avec un matériel très différent.
Comme Tomcat souligné , NetworkManager a essayé de négocier une connexion de 100mpbs mais a "expiré" et a pris la connexion en économie d'énergie.
Essayez d'utiliser ethtool --set-eee enpXsX eee off pour désactiver l'Energy Efficient Ethernet (EEE).
J'ai r8169 Ubuntu 19.10 et je ne vois pas r8169-dkms sur repo
J'ai donc résolu par solution de contournement: $ Sudo systemctl edit --full rc-local
ceci active la compatibilité rc.local: $ Sudo systemctl status rc-local
rc-local.service - /etc/rc.local Compatibilité chargée: chargé (/etc/systemd/system/rc-local.service; statique; préréglage fournisseur: activé) Drop-In:/lib/systemd/system/rc- local.service.d └─debian.conf Actif: inactif (mort) Docs: man: systemd-rc-local-generator (8)
Ensuite, je crée un /etc/rc.local (en tant que root en utilisant Sudo)
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.
sleep 55 && Sudo systemctl restart network-manager.service
exit 0
Ce script s'exécute après network.target mais est trop tôt donc j'ajoute le sleep 55: mon système démarre en 2 min et ce script ne bloque pas ...
Le redémarrage fait fonctionner le pilote.
faites ceci:$ Sudo chmod 775 /etc/rc.local
En attente du travail du r8169 sur Ubuntu 19.10.
J'espère que cette aide.
cordialement,
Leonardo