Perte intermitent de la connection internet. Débrancher rebrancher le cable résout le probleme

Bonjour, Je viens de basculler à Debian 13, avec une full-update. Rien de notable à signaler, sauf que maintenant j’ai une panne récurrente sur la connection internet. Je la perds très souvent, sur des actions aussi simple que de lancer un second navigateur, et pas uniquement sur des moments critiques comme la mise en veille. Étonamment quand le problème arrive, le logo de connection de la connection au réseau est toujours activé, mais un ping sur le routeur ne retourne rien. Déconnecter et reconnecter à partir des icones ne résout pas le problème alors que les icones semblent bien indiquer une déconnexion puis une reconnexion.
La solution simple pour résoudre le problème est de débrancher puis rebrancher le cable…
Évidement je cherche à résoudre le problème.

Voici quelques éléments pour mieux cerner le problème.

root@Desktop:~# lspci -nnk | grep -A 3 -i ethernet
03:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168/8211/8411 PCI     Express Gigabit Ethernet Controller [10ec:8168] (rev 06)
Subsystem: ASUSTeK Computer Inc. P8P67 and other motherboards [1043:8432]
Kernel driver in use: r8169
Kernel modules: r8168
root@Desktop:~# lsmod | grep r81
r8169                 126976  0
mdio_devres            12288  1 r8169
libphy                233472  3 r8169,mdio_devres,realtek

Biensûr, je vois que le driver et le module ne coincides pas r8169 / r8168. J’imagine que c’est le coeur du problème mais je ne sais pas le résoudre. Le quel garder, comment faire un changement de module?..

Pour plus d’info, les messages d’erreur, mais rien ne me saute aux yeux
root@Desktop:~# dmesg | grep -i eth
[ 292.696710] r8169 0000:03:00.0 eth0: RTL8168e/8111e, 14:da:e9:cc:26:7a, XID 2c2, IRQ 30
[ 292.696720] r8169 0000:03:00.0 eth0: jumbo features [frames: 9194 bytes, tx checksumming: ko]
[ 292.708111] r8169 0000:03:00.0 enp3s0: renamed from eth0
[ 292.820899] RTL8211DN Gigabit Ethernet r8169-0-300:00: attached PHY driver (mii_bus:phy_addr=r8169-0-300:00, irq=MAC)
[ 2621.284614] r8169 0000:03:00.0 eth0: RTL8168e/8111e, 14:da:e9:cc:26:7a, XID 2c2, IRQ 30
[ 2621.284623] r8169 0000:03:00.0 eth0: jumbo features [frames: 9194 bytes, tx checksumming: ko]
[ 2621.286689] r8169 0000:03:00.0 enp3s0: renamed from eth0
[ 2621.343058] RTL8211DN Gigabit Ethernet r8169-0-300:00: attached PHY driver (mii_bus:phy_addr=r8169-0-300:00, irq=MAC)

Votre aide serait très appréciée. Toucher les modules risque de me faire complètement perdre la connection, et après la restaurer me semble difficile. Merci.

Bonjour,

Quel est ton firmware installé?

Je vois que tu as des erreur de checksum:

Tu as activé les jumbo frames? Car c’est totalement inutile sur un lien 1G.

Quel est ton firmware installé?

Je ne sais pas. Une commande pour vérifier exactement?

Du coup, il faudrait que j’enlève et que je réinstalle? mais du coup, si j’enlève, je perds le réseau et je ne peux plus réinstaller?

Ce n’est pas volontaire. Il faut donc probablement le désactiver. Des conseils pour cela?

Merci d’avoir prit le temps de me répondre.

dpkg -s firmware-realtek

Comment as tu paramétré ton réseau?
Avec quelles commandes et/ou application?
Tu utilises quel environnement graphique?

Merci, voilà les infos.

root@Desktop:~# dpkg -s firmware-realtek
Package: firmware-realtek
Status: install ok installed
Priority: optional
Section: non-free-firmware/kernel
Installed-Size: 19187
Maintainer: Debian Kernel Team <debian-kernel@lists.debian.org>
Architecture: all
Multi-Arch: foreign
Source: firmware-nonfree
Version: 20250410-2
Replaces: firmware-realtek-rtl8723cs-bt
Suggests: initramfs-tools
Conflicts: firmware-realtek-rtl8723cs-bt
Description: Binary firmware for Realtek network and audio chips
 This package contains the binary firmware for Realtek Ethernet, Wi-Fi,
 Bluetooth and audio chips supported by various drivers.
Homepage: https://gitlab.com/kernel-firmware/linux-firmware

Je vois qu’in conflit est signalé. J’en déduis qu’il doit être préférable de retirer le firmware Realtek et d’utiliser initramfs-tools à la place. Mais une fois encore j’ai un peu peur d’essayer ça et de perdre complètement la connexion réseaux. Je préfèrait pouvoir mettre de coté le firmware actuel, de tester l’autre et de pouvoir faire marche arrière en cas de besoin.

Pour ce qui est de l’installation, je n’ai pas été plus loin que la config via gnome. J’avais une connection IPv4, avec une adresse ip fixe, le masque réseau pour aller sur le routeur, et idem pour le DNS.
Le première chose que j’ai fait quand j’ai commencé à avoir des problèmes c’est de passer sur en connexion on tout automatique.

Voici ce que j’imagine de plus détaillé:

root@Desktop:~# nmcli connection show Tout\ automatique 
connection.id:                          Tout automatique
connection.uuid:                        089af099-d85b-49ce-abd6-5efdcb2cbdf8
connection.stable-id:                   --
connection.type:                        802-3-ethernet
connection.interface-name:              enp3s0
connection.autoconnect:                 oui
connection.autoconnect-priority:        0
connection.autoconnect-retries:         -1 (default)
connection.multi-connect:               0 (default)
connection.auth-retries:                -1
connection.timestamp:                   1750418500
connection.permissions:                 --
connection.zone:                        --
connection.controller:                  --
connection.master:                      --
connection.slave-type:                  --
connection.port-type:                   --
connection.autoconnect-slaves:          -1 (default)
connection.autoconnect-ports:           -1 (default)
connection.down-on-poweroff:            -1 (default)
connection.secondaries:                 --
connection.gateway-ping-timeout:        0
connection.ip-ping-timeout:             0
connection.ip-ping-addresses:           --
connection.ip-ping-addresses-require-all:-1 (default)
connection.metered:                     inconnu
connection.lldp:                        default
connection.mdns:                        -1 (default)
connection.llmnr:                       -1 (default)
connection.dns-over-tls:                -1 (default)
connection.mptcp-flags:                 0x0 (default)
connection.wait-device-timeout:         -1
connection.wait-activation-delay:       -1
802-3-ethernet.port:                    --
802-3-ethernet.speed:                   0
802-3-ethernet.duplex:                  --
802-3-ethernet.auto-negotiate:          non
802-3-ethernet.mac-address:             --
802-3-ethernet.cloned-mac-address:      --
802-3-ethernet.generate-mac-address-mask:--
802-3-ethernet.mac-address-denylist:    --
802-3-ethernet.mtu:                     auto
802-3-ethernet.s390-subchannels:        --
802-3-ethernet.s390-nettype:            --
802-3-ethernet.s390-options:            --
802-3-ethernet.wake-on-lan:             default
802-3-ethernet.wake-on-lan-password:    --
802-3-ethernet.accept-all-mac-addresses:-1 (default)
ipv4.method:                            auto
ipv4.dns:                               --
ipv4.dns-search:                        --
ipv4.dns-options:                       --
ipv4.dns-priority:                      0
ipv4.addresses:                         --
ipv4.gateway:                           --
ipv4.routes:                            --
ipv4.route-metric:                      -1
ipv4.route-table:                       0 (unspec)
ipv4.routing-rules:                     --
ipv4.replace-local-rule:                -1 (default)
ipv4.dhcp-send-release:                 -1 (default)
ipv4.routed-dns:                        -1 (default)
ipv4.ignore-auto-routes:                non
ipv4.ignore-auto-dns:                   non
ipv4.dhcp-client-id:                    --
ipv4.dhcp-iaid:                         --
ipv4.dhcp-dscp:                         --
ipv4.dhcp-timeout:                      0 (default)
ipv4.dhcp-send-hostname-deprecated:     oui
ipv4.dhcp-send-hostname:                -1 (default)
ipv4.dhcp-hostname:                     --
ipv4.dhcp-fqdn:                         --
ipv4.dhcp-hostname-flags:               0x0 (none)
ipv4.never-default:                     non
ipv4.may-fail:                          oui
ipv4.required-timeout:                  -1 (default)
ipv4.dad-timeout:                       -1 (default)
ipv4.dhcp-vendor-class-identifier:      --
ipv4.dhcp-ipv6-only-preferred:          -1 (default)
ipv4.link-local:                        0 (default)
ipv4.dhcp-reject-servers:               --
ipv4.auto-route-ext-gw:                 -1 (default)
ipv4.shared-dhcp-range:                 --
ipv4.shared-dhcp-lease-time:            0 (default)

Suivi des détails en IPv6, puis

proxy.method:                           none
proxy.browser-only:                     non
proxy.pac-url:                          --
proxy.pac-script:                       --
GENERAL.NAME:                           Tout automatique
GENERAL.UUID:                           089af099-d85b-49ce-abd6-5efdcb2cbdf8
GENERAL.DEVICES:                        enp3s0
GENERAL.IP-IFACE:                       enp3s0
GENERAL.STATE:                          activé
GENERAL.DEFAULT:                        oui
GENERAL.DEFAULT6:                       oui
GENERAL.SPEC-OBJECT:                    --
GENERAL.VPN:                            non
GENERAL.DBUS-PATH:                      /org/freedesktop/NetworkManager/ActiveConnection/6
GENERAL.CON-PATH:                       /org/freedesktop/NetworkManager/Settings/6
GENERAL.ZONE:                           --
GENERAL.MASTER-PATH:                    --
IP4.ADDRESS[1]:                         192.168.1.219/24
IP4.GATEWAY:                            192.168.1.1
IP4.ROUTE[1]:                           dst = 192.168.1.0/24, nh = 0.0.0.0, mt = 100
IP4.ROUTE[2]:                           dst = 0.0.0.0/0, nh = 192.168.1.1, mt = 100
IP4.DNS[1]:                             192.168.1.1
DHCP4.OPTION[1]:                        dhcp_client_identifier = 01:14:da:e9:cc:26:7a
DHCP4.OPTION[2]:                        dhcp_lease_time = 604800
DHCP4.OPTION[3]:                        dhcp_server_identifier = 192.168.1.1
DHCP4.OPTION[4]:                        domain_name_servers = 192.168.1.1
DHCP4.OPTION[5]:                        expiry = 1751023300
DHCP4.OPTION[6]:                        ip_address = 192.168.1.219
DHCP4.OPTION[7]:                        requested_broadcast_address = 1
DHCP4.OPTION[8]:                        requested_domain_name = 1
DHCP4.OPTION[9]:                        requested_domain_name_servers = 1
DHCP4.OPTION[10]:                       requested_domain_search = 1
DHCP4.OPTION[11]:                       requested_host_name = 1
DHCP4.OPTION[12]:                       requested_interface_mtu = 1
DHCP4.OPTION[13]:                       requested_ms_classless_static_routes = 1
DHCP4.OPTION[14]:                       requested_nis_domain = 1
DHCP4.OPTION[15]:                       requested_nis_servers = 1
DHCP4.OPTION[16]:                       requested_ntp_servers = 1
DHCP4.OPTION[17]:                       requested_rfc3442_classless_static_routes = 1
DHCP4.OPTION[18]:                       requested_root_path = 1
DHCP4.OPTION[19]:                       requested_routers = 1
DHCP4.OPTION[20]:                       requested_static_routes = 1
DHCP4.OPTION[21]:                       requested_subnet_mask = 1
DHCP4.OPTION[22]:                       requested_time_offset = 1
DHCP4.OPTION[23]:                       requested_wpad = 1
DHCP4.OPTION[24]:                       routers = 192.168.1.1
DHCP4.OPTION[25]:                       subnet_mask = 255.255.255.0

Je suppose que je début n’est pas très utile, mais sait-on jamais…

Merci

Heu non. tu as mal compris.
firmware-realtek ne peut pas être installé en même que firmware-realtek-rtl8723cs-bt.
Et initramfs-tools est une suggestion d’installation en plus.

Ca devrait etre oui.

Merci. Je viens de regarder, en fait intramfs-tools est déjà installé. Du coup je ne comprends pas bien la suggestion.

root@Desktop:~# apt install initramfs-tools
initramfs-tools est déjà la version la plus récente (0.148.2).

Étonnament, en cherchant pour comment modifier le paramètre d’auto negotiation, je suis tombé sur un autre outil l’interogation des paramètres réseaux, et celui ci me dit que l’auto-négotiation est activée.

root@Desktop:~# ethtool enp3s0
Settings for enp3s0:
Supported ports: [ TP	 MII ]
Supported link modes:   10baseT/Half 10baseT/Full
                        100baseT/Half 100baseT/Full
                        1000baseT/Half 1000baseT/Full
Supported pause frame use: Symmetric Receive-only
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes:  10baseT/Half 10baseT/Full
                        100baseT/Half 100baseT/Full
                        1000baseT/Half 1000baseT/Full
Advertised pause frame use: Symmetric Receive-only
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Link partner advertised link modes:  10baseT/Half 10baseT/Full
                                     100baseT/Half 100baseT/Full
Link partner advertised pause frame use: Symmetric Receive-only
Link partner advertised auto-negotiation: Yes
Link partner advertised FEC modes: Not reported
**Speed: 100Mb/s**
**	Duplex: Full**
**	Auto-negotiation: on**
master-slave cfg: preferred slave
master-slave status: slave
Port: Twisted Pair
PHYAD: 0
Transceiver: external
MDI-X: Unknown
Supports Wake-on: pumbg
Wake-on: d
Link detected: yes

Les étoiles sont de moi.
Je signale que je n’ai pas eu de déconnexion depuis 24 heures. Comme il y a beaucoup de mise à jours quotidiennes avec Debian 13 actuellement puisqu’il n’est pas encore complètement sortie de sa période de test, c’est peut-être la raison et le problème résolu?
Enfin, il reste ce que Zargos a signalé: des messages incohérents, des noms de drivers bizarres…

J’aurais du me taire… De nouveau une déconnexion. J’en arrive à me demander si ce n’est pas firefox qui fait tomber la connexion. Car j’utilisais Chromium depuis 24 heures, et firefox à l’instant.
Mon expérience d’aller lire les logs est nulle, donc je ne sais pas trop comment aller regarder pour infirmer cette idée bizarre.

Tu as tracer le trafic réseau pour voir si il y a une origine particulière?

# tcpdump -i eth0 -w essai.pcap

puis quand ça coince tu fais un ^C et tu regardes sur wireshark

dump.txt (3,9 Mo)
J’ai un fichier pcap… Et j’ai installé wireshark. Mais clairement il y a une courbe d’apprentissage.
Peut-être puis-je le joindre, car mes compétences réseaux se limites à comprendre ce qu’est une adresse IP…

Si vous arrivez à le lire, ce serait top.
Ma panne est vraiment intermitent. Il fait chaud et très humide ou je suis, particulièrement humide aujourd’hui et j’ai beaucoup plus de problème… Hardware?

il n’y a aucune utilité à faire de la capture de paquet pour résoudre un problème de connexion.

Ça peut montrer plus précisément le moment où a lieu la déconnexion, le type d’erreur éventuelle et si c’est un type de paquet ou un volume important qui plante la connexion.
Ce qui est étonnant c’est que la carte semble continuer de recevoir des paquets broadcast de 192.168.1.220 (paquets 6437 et 6438) et même de HuaweiTechno_50:72:87 (paquet 6514) alors même que la connexion est visiblement rompue (par de réponse aux requêtes DNS). Le routeur semble d’ailleurs ne plus répondre aux requetes DNS à partir du timestamp 85.092757 (paquet 4886) alors même que d’autres paquets arrivent. De ce qu’on voit au début, le routeur répond immédiatement aux requêtes DNS, mais à partir du temps 123 (paquet 6093), le routeur ne répond plus aux requêtes DNS, et pourtant du trafic arrive encore

6154 126.252491 218.90.205.35 192.168.1.219 TCP 117 [TCP Spurious Retransmission] 443 → 51892 [FIN, PSH, ACK] Seq=1 Ack=2 Win=83 Len=63
6159 127.135147 83.166.143.45 192.168.1.219 TCP 105 [TCP Spurious Retransmission] 143 → 48250 [PSH, ACK] Seq=405 Ack=190 Win=22 Len=39 TSval=2273496551 TSecr=27

et tous les broadcast venant de 192.168.1.220.
Cela veut sans doute dire que bien que le souci a lieu en émission mais pas en reception. As tu essayé de nettoyer le connecteur ou de changer de cable, ça ressemble furieusement à un cable foireux cette histoire

Pas certain, mais il faudrait comparer en installant r8168-dkms [non-free]

 r8168-dkms  ●  [non-free] 1,5 MB
   ↳ dkms source for the r8168 network driver

Bien vérifier lequel est activé, en désactivant celui qui donne le moins satisfaction.
→ blacklistage r8169 si nécessaire.

Toucher à un élément crucial relatif au réseau, en demandant des garanties est un exercice… sans garantie.

Merci pour cette info.
J’entends bien l’absence de guarantie. Une commande pour installer et une command pour faire marche arrière me parait déjà un très bon début pour la sécurité. Comme je ne sais pas créer la commande d’activation par moi-même, je ne sais pas non plus désactité et réactiver le vieux.
Saurais-tu me donner ça?

Merci de ton aide.

merci d’avoir regarder dans le dump. Je vais tenter le nettoyage. Pour ça je peux le faire tout seul. Pas besoin de votre aid. :grinning:

Pas si simple sans pouvoir tester.
J’estime mineur le risque d’installer r8168-dkms pour voir ce qui se passe après reboot, mais si tu n’es pas familier des commandes lsmod/modprobe/rmmod, tu peux être embêté en cas de problème.

Mon avis, si tu n’as pas de solution alternative pour te connecter pour demander de l’aide, il faudrait ajouter une possibilité de connexion réseau partage usb avec ton téléphone, ou connexion wifi avec ton routeur. Avoir une connexion de backup te sera utile un jour ou l’autre.

Bonjour fdf,

Es-tu sûr que le pb vient de ta machine et non de ta connexion ?
J’ai eu également de gros soucis du même type avec une connexion CPL, résolus grâce à la mise en place d’un routeur WIFI Mesh.
Côté hardware, j’ai également eu un problème similaire au tien sur une autre machine avec un composant RTL8822ce. Le problème est connu mais je n’ai pas trouvé la solution. Tu as fais une recherche sur ton composant ?

Bonjour à tous.
Il semble vraiment que c’était en fait un problème de hardware. Depuis que j’ai démarrer la clim (je ne suis pas en France) et donc baissé l’humidité, les problèmes de déconnexion ont disparus.

Comme mes problèmes ont démarrés en même temps que ma mise à jour, je dois dire que c’était trompeur.
Désolé, de la confusion.
Du coup, migration à Trixie sans aucun problèmes.

Bonne semaine.