web-dev-qa-db-fra.com

Problème avec la perte de connexion Ethernet irrégulièrement Ubuntu-Budgie

Je rencontrais des problèmes de connexion intermittents via Ethernet avec un système personnalisé, Ubuntu-Budgie 64.

J'ai passé tellement de temps à discuter de l'application des correctifs via NetworkManager et de diverses autres méthodes que j'ai vues au travers des threads, mais rien ne fonctionne. Mes connexions Ethernet se connectent puis, sans notification de déconnexion, la connexion est interrompue de manière aléatoire. (et aujourd'hui après une réinstallation, quelques notifications 'déconnectées' sont apparues lorsque la connexion a été interrompue de manière aléatoire).

Je n'ai plus d'idées pour passer aux configurations système. Ifconfig montre que tout fonctionne correctement (sans perte de RX), et j'ai un réseau WiFi, plus 2 ports Ethernet (un de la carte mère principale et l'autre en plus. Je n'ai pas encore vérifié le WiFi, mais les deux ports Ethernet font la même chose ... interrompre la connexion par intermittence sans notification.

Ma carte mère est une Zenith Extreme de Asus ... Elle contient un AMD Threadstripper et 2 connexions Ethernet Gigabit (l’une directement de la carte mère, l’autre est (je pense) un adaptateur pcie dans le MB, elle se branche de la même manière).

J'ai également parcouru les discussions sur les bugs connus concernant les problèmes de connexion Ethernet Ubuntu, mais j'ai fait tout ce que je pouvais faire mais je suis toujours perdu: /, les "correctifs" ne fonctionnent pas correctement.

Ma dernière solution est que mon réseau Ethernet au bureau se heurte à des problèmes. Il fonctionne parfaitement grâce à un Window Pc utilisant le même commutateur connecté à mon instalation Ubuntu-Budgie ... Mais cela semble moins probable.

Toute suggestion me serait très utile. Donnez-moi des indications. Je n’ai pas été aussi frustré par Linux depuis mes débuts et je n’ai jamais eu ce problème.

Mise à jour de la commande du terminal Sudo lshw -C network

*-network                 
       description: Wireless interface
       product: QCA6174 802.11ac Wireless Network Adapter
       vendor: Qualcomm Atheros
       physical id: 0
       bus info: pci@0000:03:00.0
       logical name: wlp3s0
       version: 32
       serial: e0:4f:43:70:c6:46
       width: 64 bits
       clock: 33MHz
       capabilities: pm msi pciexpress bus_master cap_list ethernet physical wireless
       configuration: broadcast=yes driver=ath10k_pci driverversion=4.15.0-39-generic firmware=WLAN.RM.4.4.1-00079-QCARMSWPZ-1 latency=0 link=no multicast=yes wireless=IEEE 802.11
       resources: irq:105 memory:d8c00000-d8dfffff
  *-network
       description: Wireless interface
       product: Wil6200 802.11ad Wireless Network Adapter
       vendor: Wilocity Ltd.
       physical id: 0
       bus info: pci@0000:04:00.0
       logical name: wlp4s0
       version: 02
       serial: dc:ef:ca:ff:5f:95
       width: 64 bits
       clock: 33MHz
       capabilities: pm msi pciexpress bus_master cap_list ethernet physical wireless
       configuration: broadcast=yes driver=wil6210 driverversion=4.15.0-39-generic firmware=4.1.0.55 latency=0 multicast=yes wireless=IEEE 802.11
       resources: irq:104 memory:d8a00000-d8bfffff
  *-network
       description: Ethernet interface
       product: I211 Gigabit Network Connection
       vendor: Intel Corporation
       physical id: 0
       bus info: pci@0000:05:00.0
       logical name: enp5s0
       version: 03
       serial: 10:7b:44:93:e6:70
       size: 1Gbit/s
       capacity: 1Gbit/s
       width: 32 bits
       clock: 33MHz
       capabilities: pm msi msix pciexpress bus_master cap_list ethernet physical tp 10bt 10bt-fd 100bt 100bt-fd 1000bt-fd autonegotiation
       configuration: autonegotiation=on broadcast=yes driver=igb driverversion=5.4.0-k duplex=full firmware=0. 6-1 ip=192.168.254.119 latency=0 link=yes multicast=yes port=twisted pair speed=1Gbit/s
       resources: irq:24 memory:d8f00000-d8f1ffff ioport:2000(size=32) memory:d8f20000-d8f23fff
  *-network
       description: Ethernet interface
       physical id: 0
       bus info: pci@0000:07:00.0
       logical name: enp7s0
       version: 02
       serial: 10:7b:44:93:47:5d
       size: 1Gbit/s
       capacity: 10Gbit/s
       width: 64 bits
       clock: 33MHz
       capabilities: pciexpress pm msix msi vpd bus_master cap_list rom ethernet physical tp 100bt-fd 1000bt-fd 10000bt-fd autonegotiation
       configuration: autonegotiation=on broadcast=yes driver=atlantic driverversion=2.0.2.1-kern duplex=full firmware=1.5.58 latency=0 link=yes multicast=yes port=twisted pair speed=1Gbit/s
       resources: irq:35 memory:d8840000-d884ffff memory:d8850000-d8850fff memory:d8400000-d87fffff memory:d8800000-d883ffff

Affichage de ifconfig -a maintenant que des paquets RX sont supprimés sur enp5s0 et enp7s0

    enp5s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
            inet 192.168.254.119  netmask 255.255.255.0  broadcast 192.168.254.255
            inet6 fe80::98a1:7ebf:e58f:c031  prefixlen 64  scopeid 0x20<link>
            ether 10:7b:44:93:e6:70  txqueuelen 1000  (Ethernet)
            RX packets 78660  bytes 98174918 (98.1 MB)
            RX errors 0  dropped 1372  overruns 0  frame 0
            TX packets 13985  bytes 1394435 (1.3 MB)
            TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
            device memory 0xd8f00000-d8f1ffff  

    enp7s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
            ether 10:7b:44:93:47:5d  txqueuelen 1000  (Ethernet)
            RX packets 17843  bytes 3772904 (3.7 MB)
            RX errors 0  dropped 147  overruns 0  frame 0
            TX packets 1592  bytes 200963 (200.9 KB)
            TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

    lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
            inet 127.0.0.1  netmask 255.0.0.0
            inet6 ::1  prefixlen 128  scopeid 0x10<Host>
            loop  txqueuelen 1000  (Local Loopback)
            RX packets 299697  bytes 54030617 (54.0 MB)
            RX errors 0  dropped 0  overruns 0  frame 0
            TX packets 299697  bytes 54030617 (54.0 MB)
            TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

    wlp3s0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
            ether e0:4f:43:70:c6:46  txqueuelen 1000  (Ethernet)
            RX packets 276725  bytes 123455776 (123.4 MB)
            RX errors 0  dropped 0  overruns 0  frame 0
            TX packets 36957  bytes 5944516 (5.9 MB)
            TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

    wlp4s0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
            ether dc:ef:ca:ff:5f:95  txqueuelen 4000  (Ethernet)
            RX packets 0  bytes 0 (0.0 B)
            RX errors 0  dropped 0  overruns 0  frame 0
            TX packets 0  bytes 0 (0.0 B)
            TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
2
ViaTech

Le texte de présentation:

Cela ressemble beaucoup à un problème de négociation automatique Ethernet et vous devez régler la vitesse du réseau au niveau maximal que la carte d'interface réseau (NIC) peut supporter en commençant par 10 Mbits/s en semi-duplex et en allant jusqu'à 10 Mbits/s en FD, 100 Mbits/s en haute définition. .. jusqu'à ce que le problème commence. Ensuite, descendez d’un cran et laissez-le à cette vitesse.

Le correctif:

D'abord, installez ethtool (si vous êtes déjà installé, vous recevrez simplement un avertissement indiquant que la dernière version est déjà installée)

Sudo apt install ethtool

Maintenant:

  1. Tapez la commande suivante (et testez les un par un)

    Sudo ethtool --change enp5s0 speed xxx duplex yyy autoneg off
    

    xxx = 10, 100 ou 1000 et yyy = half ou full.

    Alors commencez par 10 half, 10 full, 100 half, ...

  2. Faites un ifconfig pour vérifier si vous laissez tomber des paquets.

  3. Retournez à 1 jusqu'à ce que ça cesse de fonctionner et utilisez les valeurs précédentes qui fonctionnaient encore!

  4. Pour rendre la modification permanente, exécutez la commande suivante:

    Sudo nano /etc/network/interfaces
    

    et tapez dans la section pre-up:

    pre-up /usr/sbin/ethtool --change enp5s0 speed xxx duplex yyy autoneg off 
    
  5. rincer et répéter pour enp7s0

1
Fabby

Vous avez peut-être un problème matériel et la réponse de Fabby couvre une partie de la solution pour éventuellement le diagnostiquer.

Vous pouvez avoir un problème matériel et logiciel. Difficile de savoir.

Je voudrais inspecter et remplacer le câblage, comme Fabby a dit réduire la vitesse et voir si le problème disparaît, raccourcir la longueur de votre câble et vous assurer que vous avez un câblage et des connecteurs de bonne qualité.

J'ai eu le même problème ce matin avec un mauvais câble, et Ubuntu 18.04 fermerait simplement l'Iface.

Allez comprendre.

Votre connexion WIFI n’aura probablement pas beaucoup d’importance puisque vous déconnectez les connexions filaires, comme vous l’avez dit les deux ports Gigabit. Le même type de câble sur chacun?

Je retirerais un port, le rendrais au repos et utiliserais simplement le port mobo et le ferais échouer. Essayez de réduire les vitesses car il semble que le noyau ferme votre matériel.

Que disent les journaux de votre système à propos de l'iface?

Exécuter DHCP sur eux? etc...

Vous pouvez simuler ce problème, contrairement à ce que Fabby a dit, en sollicitant le câble et les émetteurs-récepteurs aux extrémités du réseau. Faire beaucoup de trafic pour les saturer, déplacer des fichiers volumineux pendant de longues périodes, et beaucoup de brèves rafales d’utilisation ne provoqueront pas l’optimum, disons un câble trop lent, la connexion échouera.

Votre test USB aide, mais ne peut pas contester votre câble à la vitesse dont vous avez besoin, ni les mêmes points de terminaison de la couche matérielle, vous pouvez modifier votre configuration pour le faire, mais ceci indique à un niveau que vous avez travaillé dur, Ethernet, etc. Et votre noyau travaille dans une certaine mesure pour résoudre ce problème.

Les erreurs de réception me disent que vous recevez de mauvaises données envoyées à la machine Linux, et c'est ce que vous verrez. Les erreurs de Tx vont signifier autre chose et ne seront vraisemblablement vus que par le pair que la machine Linux envoie à, dans votre cas.

Vous dépassez les FIFO et/ou obtenez des données incorrectes et échouez sur les sommes CRC-32 du côté de Linux et avez probablement des problèmes de qualité de signal. Je baisserais la vitesse, en descendant très bas, et verrais s'ils partaient, et puisque vous êtes sûr d'avoir de bons câbles, et pas de pauses, etc., assurez-vous qu'ils sont courts et de bonne capacité.

Je pense toujours au câblage et/ou à d’autres matériels, sur les câbles.

1
user900446