La Fibre

Télécom => Logiciels et systèmes d'exploitation => Linux Linux => Discussion démarrée par: renaud07 le 16 juillet 2018 à 17:43:02

Titre: Connexion ethernet instable
Posté par: renaud07 le 16 juillet 2018 à 17:43:02
Bonjour,

Depuis que j'ai migré sur linux mint 19, ma connexion est devenue assez instable.  De manière aléatoire, la connexion se coupe puis revient quelques secondes plus tard (on le voit dans la navigation ça mouline pendant plusieurs secondes puis ça s'affiche d'un coup), voir ne revient pas du tout et je suis obligé de déconnecter/reconnecter via le gestionnaire.

Ça m'arrivais aussi avec la version 18, mais c'était plus rare du genre une fois par semaine.

Quel peut-être la cause ? noyau/pilote buggé ? network manager qui fait des siennes ?

Merci d'avance.

Le modèle de ma carte :
02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 09)

Noyau : 4.15.0-24
Titre: Connexion ethernet instable
Posté par: vivien le 16 juillet 2018 à 21:19:50
Linux mint est basé sur Ubuntu 18.04 LTS

Le kernel 4.15.0-24 n'étant ps encore mis en prod, je pense que tu as activé les mises à jour en préversion pour avoir les mises à jour avant leur mise en prod.

La version actuelle de prod est le 4.15.0-23-generic #25-Ubuntu SMP Wed May 23 18:02:16 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux


J'ai une suggestion à te faire : dans paramètres => confidentialité => Vérification de la connectivité => change pour "désactivé"
Titre: Connexion ethernet instable
Posté par: renaud07 le 16 juillet 2018 à 21:39:01
Préversion ça correspond aux paquets romeo (instable) ? Si c'est ça ce n'est pas activé...

Et dans confidentialité je n'ai rien de ce que tu m'indiques. Seulement une case "se souvenir des fichiers récemment ouverts"
Titre: Connexion ethernet instable
Posté par: renaud07 le 16 juillet 2018 à 21:44:08
Voici la liste des dépots activés :
renaud@renaud-pc:~$ inxi -r
*Repos:     Active apt sources in file: /etc/apt/sources.list.d/official-package-repositories.list
           deb http://packages.linuxmint.com tara main upstream import backport #id:linuxmint_main
           deb http://archive.ubuntu.com/ubuntu bionic main restricted universe multiverse
           deb http://archive.ubuntu.com/ubuntu bionic-updates main restricted universe multiverse
           deb http://archive.ubuntu.com/ubuntu bionic-backports main restricted universe multiverse
           deb http://security.ubuntu.com/ubuntu/ bionic-security main restricted universe multiverse
           deb http://archive.canonical.com/ubuntu/ bionic partner
           Active apt sources in file: /etc/apt/sources.list.d/spotify.list
           deb http://repository.spotify.com stable non-free

Peut-être les backports en cause ? Je précise que je n'ai rien touché, c'est le truc par défaut (hormis le dépôt spotify)
Titre: Connexion ethernet instable
Posté par: Hugues le 16 juillet 2018 à 21:51:22
Y'a rien a backporter en Bionic...
Titre: Connexion ethernet instable
Posté par: renaud07 le 16 juillet 2018 à 22:00:55
Exact, j'ai pensé trop vite...

Donc ça ne m'explique pas la provenance du noyau  ???

Vais installer le 4.15.0-23 voir si je constate une amélioration.
Titre: Connexion ethernet instable
Posté par: Marco POLO le 16 juillet 2018 à 22:04:16
L'ami qui m'a programmé Linux Mint avait installé la version 19 et l'a vite désinstallée pour revenir à la version précédente pour cause d'incompatibilité avec pas mal de programmes !  (https://lafibre.info/images/smileys/@GregLand/ed.gif)
Titre: Connexion ethernet instable
Posté par: renaud07 le 16 juillet 2018 à 22:11:06
Quel genre de programmes ?

Perso, j'ai rien constaté de gênant pour le moment...
Titre: Connexion ethernet instable
Posté par: vivien le 16 juillet 2018 à 22:11:23
C'est bionic-proposed les préversions.

Ce n'est pas le précédent noyau qui va t’apporter qq chose.

Je m'étonne juste de cette configuration.

Sinon je n'ai pas vu d'incompatibilité, il y a juste des vieux logiciels qui ne sont plus installés par défaut (comme libgconf2-4 et desktop-file-utils), ce qui pose pb quand tu installe des logiciels tiers comme molotov-tv. Il suffit de les installer à la main avant (libgconf2-4 et desktop-file-utils sont dans les dépôts Ubuntu)

Titre: Connexion ethernet instable
Posté par: Marco POLO le 16 juillet 2018 à 22:14:52
Quel genre de programmes ?

Perso, j'ai rien constaté de gênant pour le moment...
Aucune idée !  (https://lafibre.info/images/smileys/@GregLand/bk.gif)
Titre: Connexion ethernet instable
Posté par: renaud07 le 16 juillet 2018 à 22:33:09
Je viens d'installer une xubuntu en VM et il se trouve que j'ai bien le 4.15.0-24 dans la liste des paquets sans avoir activé le dépôt proposed. Et lorsque je l'installe ça le télécharge bien à partir du dépôt main. Par contre, si je demande une update du sytème il veut m'installer le 4.15.0-23. Qu'est-ce qui indique de ne pas télécharger le 24 ? La liste des paquets ?

Donc je ne suis pas fou, je n'ai rien activé de bizarre sur ma LM et elle se contente d'installer le dernier noyau dispo contrairement à ubuntu.

EDIT : avec préversion activé il me propose d'installer le 4.15.0-28 (sur ubuntu)
Titre: Connexion ethernet instable
Posté par: renaud07 le 16 juillet 2018 à 22:43:26
Aucune idée !  (https://lafibre.info/images/smileys/@GregLand/bk.gif)

Nous verrons bien à l'usage alors  ;)
Titre: Connexion ethernet instable
Posté par: vivien le 17 juillet 2018 à 08:25:04
J'ai essayé en prenant le même serveur que toi (archive.ubuntu.com) : il ne me propose pas d'installer un nouveau noyau (je reste en 4.15.0-23-generic )

Mon fichier /etc/apt/sources.list sans les lignes commentées :
$ sed -e '/^#\|^$/d' /etc/apt/sources.list
deb http://archive.ubuntu.com/ubuntu bionic main restricted
deb http://archive.ubuntu.com/ubuntu bionic-updates main restricted
deb http://archive.ubuntu.com/ubuntu bionic universe
deb http://archive.ubuntu.com/ubuntu bionic-updates universe
deb http://archive.ubuntu.com/ubuntu bionic multiverse
deb http://archive.ubuntu.com/ubuntu bionic-updates multiverse
deb http://archive.ubuntu.com/ubuntu bionic-backports main restricted universe multiverse
deb http://archive.ubuntu.com/ubuntu bionic-security main restricted
deb http://archive.ubuntu.com/ubuntu bionic-security universe
deb http://archive.ubuntu.com/ubuntu bionic-security multiverse

Au passage je t'invite à passer sur un miroir français, pour économiser du transit à Canonical.
Titre: Connexion ethernet instable
Posté par: renaud07 le 17 juillet 2018 à 13:24:28
Pareil ici. Il ne me propose pas d'installer le -24 quand je demande une MAJ :
renaud@renaud-VirtualBox:~$ sudo apt-get dist-upgrade
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances       
Lecture des informations d'état... Fait
Calcul de la mise à jour... Fait
Les NOUVEAUX paquets suivants seront installés :
  amd64-microcode intel-microcode iucode-tool linux-headers-4.15.0-23
  linux-headers-4.15.0-23-generic linux-image-4.15.0-23-generic
  linux-modules-4.15.0-23-generic linux-modules-extra-4.15.0-23-generic


Par contre je peux l'installer à la main :
renaud@renaud-VirtualBox:~$ dpkg -l | grep linux-image
ii  linux-image-4.15.0-20-generic         4.15.0-20.21                        amd64        Signed kernel image generic
ii  linux-image-4.15.0-24-generic         4.15.0-24.26                        amd64        Signed kernel image generic
ii  linux-image-generic                   4.15.0.20.23                        amd64        Generic Linux kernel image

Bref, je ne sais pas pourquoi Linux Mint installe le -24 et Ubuntu reste sur le -23...
Titre: Connexion ethernet instable
Posté par: Nh3xus le 17 juillet 2018 à 13:34:15
Parce que les politiques de mises à jour de Mint sont différentes.

Mint applique une rétention des paquets qui est plus longue que chez Ubuntu.

Les soucis liés à la sécurité chez Mint c'est un sujet qui revient souvent sur pas mal de forums malheureusement (et pas en bien).
Titre: Connexion ethernet instable
Posté par: renaud07 le 17 juillet 2018 à 13:36:45
Ah, je m'en doutais un peu effectivement. Par contre je ne pensais pas que ça affectait aussi les MAJ du noyau.

Merci pour l'explication  :)
Titre: Connexion ethernet instable
Posté par: Nh3xus le 17 juillet 2018 à 13:39:20
Tu peux nous donner la sortie de la commande suivante ?

ip -s link show
Titre: Connexion ethernet instable
Posté par: renaud07 le 17 juillet 2018 à 13:42:01
renaud@renaud-pc:~$ ip -s link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    RX: bytes  packets  errors  dropped overrun mcast   
    151740     1634     0       0       0       0       
    TX: bytes  packets  errors  dropped carrier collsns
    151740     1634     0       0       0       0       
2: enp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
    link/ether d8:50:e6:xx:xx:xx brd ff:ff:ff:ff:ff:ff
    RX: bytes  packets  errors  dropped overrun mcast   
    144328134  104057   0       0       0       133     
    TX: bytes  packets  errors  dropped carrier collsns
    5457237    58855    0       0       0       0       
Titre: Connexion ethernet instable
Posté par: Nh3xus le 17 juillet 2018 à 13:57:38
Aucune erreur et pas de drop.

Visiblement, le câblage est propre.

On dirait bien un bug du module du noyau Linux qui gère ta carte.

T'as essayé de retrouver le module qui pilote ta carte ? (via la commande lsmod)
Titre: Connexion ethernet instable
Posté par: renaud07 le 17 juillet 2018 à 14:09:43
Il s'agit du module r8169.

EDIT: Je viens de trouver ce bug : https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1752772

Apparemment corrigé, mais peut-être qu'il en reste des résidus ?

Titre: Connexion ethernet instable
Posté par: vivien le 17 juillet 2018 à 16:25:40
Mint applique une rétention des paquets qui est plus longue que chez Ubuntu.

Les soucis liés à la sécurité chez Mint c'est un sujet qui revient souvent sur pas mal de forums malheureusement (et pas en bien).

Enfin dans ce cas précis Mint a un kernel plus récent que Ubuntu 18.04.

J'ai trouvé la raison : Il est bugué et il a été retiré chez Ubuntu, mais visiblement pas chez Mint.


Une mise à jour du noyau Linux d'Ubuntu 18.04 cause un ralentissement du temps de démarrage
Sur quelques systèmes

En avril dernier, Canonical a annoncé la sortie officielle d’Ubuntu 18.04 estampillée “Bionic Beaver”. Après la publication d’une mise à jour récente du système, les utilisateurs ont constaté un ralentissement du temps de démarrage pouvant aller à 4 minutes, voire plus. Ce ralentissement serait dû à un bogue du noyau Linux se trouvant dans la mise à jour.

L’image du noyau qui a causé ce souci (version 4.15.0-24) a été publiée en tant que mise à jour d’Ubuntu 18.04 le 4 juillet, et a déjà été retirée des dépôts archives. Un correctif a été publié, mais le package mis à jour est disponible seulement sur les dépôts (proposed) d’Ubuntu 18.04.

Apparemment, même le fait de démarrer des versions antérieures du noyau ne corrige pas le problème. En attendant que le package contenant le correctif soit disponible dans les principaux dépôts, si vous êtes affectés par ce problème, vous pouvez accélérer le démarrage du système « en remuant la souris ou bien en appuyant sur shift ou ctrl durant le démarrage pour faire en sorte que le système génère l’entropie un peu plus rapidement », a écrit Oliver Grawert dans une réponse sur Google+.

Sous Linux, pour être capable de générer des nombres aléatoires, le noyau est obligé de recourir à des astuces logicielles pour les produire. Le noyau utilise un amalgame de données variables (état des disques durs, IO, date, saisies clavier…) comme source d’instabilité, ou source d’entropie, de son générateur de nombres aléatoires. Dans ce stade de démarrage, le système n’ayant pas assez d’entropie, et voyant que rien n’arrive, les processus entrent en pause en attendant que le noyau trouve un moyen de générer de l’entropie. En remuant la souris ou bien en appuyant sur le clavier, il est possible de réduire le délai d’attente, et donc le temps nécessaire pour générer l’entropie.

Des utilisateurs ont fait savoir qu’ils ont fait face au même problème sur d’autres distributions de Linux auparavant comme Linux Mint et Arch.

Source : Developpez (https://www.developpez.com/actu/213564/Une-mise-a-jour-du-noyau-Linux-d-Ubuntu-18-04-cause-un-ralentissement-du-temps-de-demarrage-sur-quelques-systemes/)Le 6 juillet 2018, par Coriolan, Chroniqueur Actualités
Titre: Connexion ethernet instable
Posté par: renaud07 le 17 juillet 2018 à 16:38:16
Visiblement le patch a été publié puisque le  4.15.0-24 est présent dans le dépôt... et je n'ai pas constaté un chargement plus long de mon côté.

Sinon, je n'ai toujours pas eu de bug réseau aujourd'hui. Comme par hasard, il suffit que je parle du problème pour qu'il ne se produise plus  ::)

EDIT : J'ai parlé un peu vite, 2 déconnexions à 5 min d'intervalle :
Citer
Jul 17 16:46:01 renaud-pc systemd-resolved[897]: Using degraded feature set (UDP) for DNS server 192.168.1.2.
Jul 17 16:46:26 renaud-pc systemd-resolved[897]: Using degraded feature set (TCP) for DNS server 192.168.1.2.
Jul 17 16:46:36 renaud-pc systemd-resolved[897]: Using degraded feature set (UDP) for DNS server 192.168.1.2.
Jul 17 16:46:41 renaud-pc gvfsd-metadata[1726]: g_udev_device_has_property: assertion 'G_UDEV_IS_DEVICE (device)' failed
Jul 17 16:46:41 renaud-pc gvfsd-metadata[1726]: message repeated 7 times: [ g_udev_device_has_property: assertion 'G_UDEV_IS_DEVICE (device)' failed]
Jul 17 16:46:56 renaud-pc systemd-resolved[897]: Using degraded feature set (TCP) for DNS server 192.168.1.2.

Jul 17 16:52:04 renaud-pc systemd-resolved[897]: Using degraded feature set (UDP) for DNS server 192.168.1.2.
Jul 17 16:52:10 renaud-pc systemd-resolved[897]: Using degraded feature set (TCP) for DNS server 192.168.1.2.
Jul 17 16:52:15 renaud-pc systemd-resolved[897]: Using degraded feature set (UDP) for DNS server 192.168.1.2.
Jul 17 16:52:19 renaud-pc systemd-resolved[897]: Using degraded feature set (TCP) for DNS server 192.168.1.2.
Jul 17 16:52:22 renaud-pc systemd-resolved[897]: Using degraded feature set (UDP) for DNS server 192.168.1.2.
Jul 17 16:52:29 renaud-pc systemd-resolved[897]: Using degraded feature set (TCP) for DNS server 192.168.1.2.
Jul 17 16:52:39 renaud-pc systemd-resolved[897]: Using degraded feature set (UDP) for DNS server 192.168.1.2.
Jul 17 16:52:49 renaud-pc systemd-resolved[897]: Using degraded feature set (TCP) for DNS server 192.168.1.2.
Jul 17 16:52:54 renaud-pc systemd-resolved[897]: Using degraded feature set (UDP) for DNS server 192.168.1.2.
Jul 17 16:53:04 renaud-pc systemd-resolved[897]: Using degraded feature set (TCP) for DNS server 192.168.1.2.

J'ai regardé les log du kernel, je ne vois rien qui ressemble à un plantage quelconque... les dernières lignes s'arrêtent lorsque j'ai démarré la machine en début d'après-midi.
Titre: Connexion ethernet instable
Posté par: vivien le 17 juillet 2018 à 17:09:29
Non, le 4.15.0-24 n'est pas bon. Il est présent dans les dépôts mais non installé automatiquement.

La correctif serait apporté par le 4.15.0-28 qui ne devrait pas tarder.
Titre: Connexion ethernet instable
Posté par: renaud07 le 17 juillet 2018 à 17:25:43
La correctif serait apporté par le 4.15.0-28 qui ne devrait pas tarder.

Croisons les doigts pour que ça règle mon problème de réseau en même temps.
Titre: Connexion ethernet instable
Posté par: renaud07 le 17 juillet 2018 à 17:33:47
À tout hasard, test en adressage manuel voir si je note une amélioration.
Titre: Connexion ethernet instable
Posté par: renaud07 le 19 juillet 2018 à 17:40:47
J'ai bien l'impression que le passage en manuel a fait disparaître le bug :D

Du coup c'est peut-être pas le driver mais networkmanager qui délire.

EDIT : J'ai repassé la commande  ip -s link show et maintenant j'ai des drop... alors que je n'ai pas touché au câblage...  Enfin ça n'a pas l'air de trop impacter le débit, il doit s'en dropper 2 toutes les 30 sec.
renaud@renaud-pc:~$ ip -s link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    RX: bytes  packets  errors  dropped overrun mcast   
    340706     3770     0       0       0       0       
    TX: bytes  packets  errors  dropped carrier collsns
    340706     3770     0       0       0       0       
2: enp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
    link/ether d8:50:e6:xx:xx:xx brd ff:ff:ff:ff:ff:ff
    RX: bytes  packets  errors  dropped overrun mcast   
    975323892  709288   0       512     0       1104   
    TX: bytes  packets  errors  dropped carrier collsns
    40321858   466451   0       0       0       0       
Titre: Connexion ethernet instable
Posté par: renaud07 le 20 juillet 2018 à 21:39:26
EDIT : J'ai repassé la commande  ip -s link show et maintenant j'ai des drop... alors que je n'ai pas touché au câblage...  Enfin ça n'a pas l'air de trop impacter le débit, il doit s'en dropper 2 toutes les 30 sec.

Je viens de trouver le coupable : il s'agissait de mon switch ! Une fois débranché/rebranché, plus de drop. Faut croire qu'il y avait un truc qui saturait ou qu'il a pris un coup de chaud (27° de moyenne la journée).

Un nouveau noyau s'est également installé le  4.15.0-29, je repasse en DHCP pour voir.
Titre: Connexion ethernet instable
Posté par: vivien le 20 juillet 2018 à 22:12:12
Le 4.15.0-29 corrige entre autre chose les problèmes de lenteur au boot quand l'entropie est faible et est insuffisant pour le générateur de nombres aléatoires.

Il est maintenant en prod et disponible aussi sous Ubuntu.
Titre: Connexion ethernet instable
Posté par: renaud07 le 20 juillet 2018 à 22:16:30
Merci pour les précisons.
Titre: Connexion ethernet instable
Posté par: renaud07 le 05 octobre 2018 à 16:09:02
Petit up du sujet.

Il semblerait que mon problème soit de retour. J'ai réinstallé ubuntu 16.04 car trop de problème avec la 18.04, mais la perte de connexion revient régulièrement, et cette fois je pense avoir trouvé une piste : le renew DHCP. Elle expire toutes les 2 heures et cette fois la coupure semble bien coïncider.

J'ai allumé mon PC vers 13h15 et je me suis rendu compte que je n'avais plus de connexion vers 15h30 donc à quelques minutes près ça ressemble au renew qui ne s'est pas fait correctement.

Mais je ne vois aucune erreur dans les logs... alors que je vois bien ma déconnexion/reconnexion manuelle...

Voici le syslog (on voit bien qu'avant mon intervention, il n'y a aucun renew DHCP de fait) :
Oct  5 13:22:18 renaud-pc anacron[1231]: Job `cron.daily' terminated
Oct  5 13:22:18 renaud-pc anacron[1231]: Normal exit (1 job run)
Oct  5 13:26:35 renaud-pc ntpd[1620]: 91.189.91.157 local addr 192.168.1.11 -> <null>
Oct  5 13:29:54 renaud-pc ntpd[1620]: 62.210.167.248 local addr 192.168.1.11 -> <null>
Oct  5 13:30:57 renaud-pc ntpd[1620]: 95.81.173.155 local addr 192.168.1.11 -> <null>
Oct  5 13:31:01 renaud-pc ntpd[1620]: 137.74.28.231 local addr 192.168.1.11 -> <null>
Oct  5 13:32:07 renaud-pc ntpd[1620]: 212.83.179.156 local addr 192.168.1.11 -> <null>
Oct  5 13:32:07 renaud-pc systemd[1]: Starting Cleanup of Temporary Directories...
Oct  5 13:32:07 renaud-pc systemd-tmpfiles[5545]: [/usr/lib/tmpfiles.d/var.conf:14] Duplicate line for path "/var/log", ignoring.
Oct  5 13:32:07 renaud-pc systemd[1]: Started Cleanup of Temporary Directories.
Oct  5 13:41:43 renaud-pc ntpd[1620]: 91.189.89.198 local addr 192.168.1.11 -> <null>
Oct  5 13:44:25 renaud-pc ntpd[1620]: 212.85.158.10 local addr 192.168.1.11 -> <null>
Oct  5 14:13:05 renaud-pc ntpd[1620]: 37.187.2.84 local addr 192.168.1.11 -> <null>
Oct  5 14:17:01 renaud-pc CRON[5911]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Oct  5 14:34:55 renaud-pc ntpd[1620]: 149.202.2.105 local addr 192.168.1.11 -> <null>
Oct  5 14:35:05 renaud-pc ntpd[1620]: 91.224.149.41 local addr 192.168.1.11 -> <null>
Oct  5 14:54:11 renaud-pc ntpd[1620]: 151.80.211.8 local addr 192.168.1.11 -> <null>
Oct  5 15:17:01 renaud-pc CRON[6147]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Oct  5 15:17:20 renaud-pc avahi-daemon[1138]: Withdrawing address record for 192.168.1.11 on enp2s0.
Oct  5 15:17:20 renaud-pc avahi-daemon[1138]: Leaving mDNS multicast group on interface enp2s0.IPv4 with address 192.168.1.11.
Oct  5 15:17:20 renaud-pc avahi-daemon[1138]: Interface enp2s0.IPv4 no longer relevant for mDNS.
Oct  5 15:17:21 renaud-pc ntpd[1620]: Deleting interface #3 enp2s0, 192.168.1.11#123, interface stats: received=575, sent=576, dropped=0, active_time=7200 secs
Oct  5 15:17:21 renaud-pc ntpd[1620]: 178.249.167.0 local addr 192.168.1.11 -> <null>
Oct  5 15:17:21 renaud-pc ntpd[1620]: 92.243.6.5 local addr 192.168.1.11 -> <null>
Oct  5 15:17:21 renaud-pc ntpd[1620]: 212.83.187.62 local addr 192.168.1.11 -> <null>
Oct  5 15:17:21 renaud-pc ntpd[1620]: 37.187.101.146 local addr 192.168.1.11 -> <null>
Oct  5 15:17:21 renaud-pc ntpd[1620]: 151.80.19.218 local addr 192.168.1.11 -> <null>
Oct  5 15:17:21 renaud-pc ntpd[1620]: 195.154.41.195 local addr 192.168.1.11 -> <null>
Oct  5 15:17:40 renaud-pc whoopsie[1588]: [15:17:40] Cannot reach: https://daisy.ubuntu.com
Oct  5 15:17:40 renaud-pc whoopsie[1588]: [15:17:40] offline
Oct  5 15:51:32 renaud-pc NetworkManager[1230]: <info>  [1538747492.1103] device (enp2s0): state change: activated -> deactivating (reason 'user-requested') [100 110 39]
Oct  5 15:51:32 renaud-pc NetworkManager[1230]: <info>  [1538747492.1105] manager: NetworkManager state is now DISCONNECTING
Oct  5 15:51:32 renaud-pc NetworkManager[1230]: <info>  [1538747492.1733] audit: op="device-disconnect" interface="enp2s0" ifindex=2 pid=2394 uid=1000 result="success"
Oct  5 15:51:32 renaud-pc NetworkManager[1230]: <info>  [1538747492.1741] device (enp2s0): state change: deactivating -> disconnected (reason 'user-requested') [110 30 39]
Oct  5 15:51:32 renaud-pc avahi-daemon[1138]: Withdrawing address record for fe80::cfdf:26bd:a020:3428 on enp2s0.
Oct  5 15:51:32 renaud-pc avahi-daemon[1138]: Leaving mDNS multicast group on interface enp2s0.IPv6 with address fe80::cfdf:26bd:a020:3428.
Oct  5 15:51:32 renaud-pc avahi-daemon[1138]: Interface enp2s0.IPv6 no longer relevant for mDNS.
Oct  5 15:51:32 renaud-pc NetworkManager[1230]: <info>  [1538747492.2066] dhcp4 (enp2s0): canceled DHCP transaction, DHCP client pid 1411
Oct  5 15:51:32 renaud-pc NetworkManager[1230]: <info>  [1538747492.2066] dhcp4 (enp2s0): state changed bound -> done
Oct  5 15:51:32 renaud-pc NetworkManager[1230]: <info>  [1538747492.2071] dns-mgr: Writing DNS information to /sbin/resolvconf
Oct  5 15:51:32 renaud-pc dnsmasq[1421]: configuration des serveurs amonts à partir de DBus
Oct  5 15:51:32 renaud-pc NetworkManager[1230]: <info>  [1538747492.2335] manager: NetworkManager state is now DISCONNECTED
Oct  5 15:51:32 renaud-pc dbus[1140]: [system] Activating via systemd: service name='org.freedesktop.nm_dispatcher' unit='dbus-org.freedesktop.nm-dispatcher.service'
Oct  5 15:51:32 renaud-pc systemd[1]: Starting Network Manager Script Dispatcher Service...
Oct  5 15:51:32 renaud-pc dbus[1140]: [system] Successfully activated service 'org.freedesktop.nm_dispatcher'
Oct  5 15:51:32 renaud-pc systemd[1]: Started Network Manager Script Dispatcher Service.
Oct  5 15:51:32 renaud-pc nm-dispatcher: req:1 'down' [enp2s0]: new request (2 scripts)
Oct  5 15:51:32 renaud-pc nm-dispatcher: req:1 'down' [enp2s0]: start running ordered scripts...
Oct  5 15:51:33 renaud-pc ntpd[1620]: Deleting interface #6 enp2s0, fe80::cfdf:26bd:a020:3428%2#123, interface stats: received=0, sent=0, dropped=0, active_time=9250 secs
Oct  5 15:51:37 renaud-pc NetworkManager[1230]: <info>  [1538747497.4791] device (enp2s0): Activation: starting connection 'Connexion filaire 1' (8bb8eaa7-4c02-39a2-9500-54e1970d3c66)
Oct  5 15:51:37 renaud-pc NetworkManager[1230]: <info>  [1538747497.4792] audit: op="connection-activate" uuid="8bb8eaa7-4c02-39a2-9500-54e1970d3c66" name="Connexion filaire 1" pid=2394 uid=1000 result="success"
Oct  5 15:51:37 renaud-pc NetworkManager[1230]: <info>  [1538747497.4794] device (enp2s0): state change: disconnected -> prepare (reason 'none') [30 40 0]
Oct  5 15:51:37 renaud-pc NetworkManager[1230]: <info>  [1538747497.4795] manager: NetworkManager state is now CONNECTING
Oct  5 15:51:37 renaud-pc NetworkManager[1230]: <info>  [1538747497.4801] device (enp2s0): state change: prepare -> config (reason 'none') [40 50 0]
Oct  5 15:51:37 renaud-pc NetworkManager[1230]: <info>  [1538747497.4804] device (enp2s0): state change: config -> ip-config (reason 'none') [50 70 0]
Oct  5 15:51:37 renaud-pc NetworkManager[1230]: <info>  [1538747497.4808] dhcp4 (enp2s0): activation: beginning transaction (timeout in 45 seconds)
Oct  5 15:51:37 renaud-pc NetworkManager[1230]: <info>  [1538747497.4826] dhcp4 (enp2s0): dhclient started with pid 6677
Oct  5 15:51:37 renaud-pc dhclient[6677]: DHCPREQUEST of 192.168.1.11 on enp2s0 to 255.255.255.255 port 67 (xid=0x766088f9)
Oct  5 15:51:37 renaud-pc dhclient[6677]: DHCPACK of 192.168.1.11 from 192.168.1.10
Oct  5 15:51:37 renaud-pc NetworkManager[1230]: <info>  [1538747497.5027]   address 192.168.1.11
Oct  5 15:51:37 renaud-pc NetworkManager[1230]: <info>  [1538747497.5028]   plen 24 (255.255.255.0)
Oct  5 15:51:37 renaud-pc NetworkManager[1230]: <info>  [1538747497.5028]   gateway 192.168.1.1
Oct  5 15:51:37 renaud-pc NetworkManager[1230]: <info>  [1538747497.5028]   server identifier 192.168.1.10
Oct  5 15:51:37 renaud-pc NetworkManager[1230]: <info>  [1538747497.5028]   lease time 7200
Oct  5 15:51:37 renaud-pc NetworkManager[1230]: <info>  [1538747497.5028]   nameserver '192.168.1.10'
Oct  5 15:51:37 renaud-pc NetworkManager[1230]: <info>  [1538747497.5029]   nameserver '192.168.1.2'
Oct  5 15:51:37 renaud-pc NetworkManager[1230]: <info>  [1538747497.5029]   domain name 'lapalisse.lan'
Oct  5 15:51:37 renaud-pc NetworkManager[1230]: <info>  [1538747497.5029] dhcp4 (enp2s0): state changed unknown -> bound
Oct  5 15:51:37 renaud-pc avahi-daemon[1138]: Joining mDNS multicast group on interface enp2s0.IPv4 with address 192.168.1.11.
Oct  5 15:51:37 renaud-pc NetworkManager[1230]: <info>  [1538747497.5043] device (enp2s0): state change: ip-config -> ip-check (reason 'none') [70 80 0]
Oct  5 15:51:37 renaud-pc NetworkManager[1230]: <info>  [1538747497.5050] device (enp2s0): state change: ip-check -> secondaries (reason 'none') [80 90 0]
Oct  5 15:51:37 renaud-pc avahi-daemon[1138]: New relevant interface enp2s0.IPv4 for mDNS.
Oct  5 15:51:37 renaud-pc avahi-daemon[1138]: Registering new address record for 192.168.1.11 on enp2s0.IPv4.
Oct  5 15:51:37 renaud-pc NetworkManager[1230]: <info>  [1538747497.5053] device (enp2s0): state change: secondaries -> activated (reason 'none') [90 100 0]
Oct  5 15:51:37 renaud-pc NetworkManager[1230]: <info>  [1538747497.5055] manager: NetworkManager state is now CONNECTED_LOCAL
Oct  5 15:51:37 renaud-pc whoopsie[1588]: [15:51:37] Cannot reach: https://daisy.ubuntu.com
Oct  5 15:51:37 renaud-pc dhclient[6677]: bound to 192.168.1.11 -- renewal in 2741 seconds.
Oct  5 15:51:37 renaud-pc NetworkManager[1230]: <info>  [1538747497.5837] manager: NetworkManager state is now CONNECTED_GLOBAL
Oct  5 15:51:37 renaud-pc NetworkManager[1230]: <info>  [1538747497.5838] policy: set 'Connexion filaire 1' (enp2s0) as default for IPv4 routing and DNS
Oct  5 15:51:37 renaud-pc NetworkManager[1230]: <info>  [1538747497.5840] dns-mgr: Writing DNS information to /sbin/resolvconf
Oct  5 15:51:37 renaud-pc dnsmasq[1421]: configuration des serveurs amonts à partir de DBus
Oct  5 15:51:37 renaud-pc dnsmasq[1421]: utilise le serveur de nom 192.168.1.10#53 (via enp2s0)
Oct  5 15:51:37 renaud-pc dnsmasq[1421]: utilise le serveur de nom 192.168.1.2#53 (via enp2s0)
Oct  5 15:51:37 renaud-pc NetworkManager[1230]: <info>  [1538747497.6529] device (enp2s0): Activation: successful, device activated.
Oct  5 15:51:37 renaud-pc nm-dispatcher: req:2 'up' [enp2s0]: new request (2 scripts)
Oct  5 15:51:37 renaud-pc nm-dispatcher: req:2 'up' [enp2s0]: start running ordered scripts...
Oct  5 15:51:37 renaud-pc whoopsie[1588]: [15:51:37] The default IPv4 route is: /org/freedesktop/NetworkManager/ActiveConnection/1
Oct  5 15:51:37 renaud-pc whoopsie[1588]: [15:51:37] Not a paid data plan: /org/freedesktop/NetworkManager/ActiveConnection/1
Oct  5 15:51:37 renaud-pc whoopsie[1588]: [15:51:37] Found usable connection: /org/freedesktop/NetworkManager/ActiveConnection/1
Oct  5 15:51:37 renaud-pc whoopsie[1588]: [15:51:37] online
Oct  5 15:51:38 renaud-pc avahi-daemon[1138]: Joining mDNS multicast group on interface enp2s0.IPv6 with address fe80::cfdf:26bd:a020:3428.
Oct  5 15:51:38 renaud-pc avahi-daemon[1138]: New relevant interface enp2s0.IPv6 for mDNS.
Oct  5 15:51:38 renaud-pc avahi-daemon[1138]: Registering new address record for fe80::cfdf:26bd:a020:3428 on enp2s0.*.
Oct  5 15:51:40 renaud-pc ntpd[1620]: Listen normally on 7 enp2s0 192.168.1.11:123
Oct  5 15:51:40 renaud-pc ntpd[1620]: Listen normally on 8 enp2s0 [fe80::cfdf:26bd:a020:3428%2]:123
Oct  5 15:51:40 renaud-pc ntpd[1620]: new interface(s) found: waking up resolver

J'ai aussi regardé les logs sur le serveur, et pas de trace de renew avant mon intervention...
Titre: Connexion ethernet instable
Posté par: vivien le 05 octobre 2018 à 20:23:56
C'est très court comme baille DHCP.

Idéalement, il faudrait faire fonctionner TCP Dump (ou wireshark si tu souhaites une interface graphique) en filtrant sur le DHCP.
Titre: Connexion ethernet instable
Posté par: renaud07 le 05 octobre 2018 à 20:35:20
Oui c'est très court, j'avais configuré ça il y a plusieurs années et je n'y avais jamais retouché depuis vu que ça fonctionnait. Du coup je vais réduire le temps genre à 1 min voir si le renew fonctionne.
Titre: Connexion ethernet instable
Posté par: renaud07 le 05 octobre 2018 à 20:44:36
Bon c'est bizarre, un renew toutes les minutes à l'air de fonctionner :
Oct  5 20:39:28 renaud-pc dhclient[11710]: bound to 192.168.1.11 -- renewal in 52 seconds.
Oct  5 20:40:20 renaud-pc dhclient[11710]: DHCPREQUEST of 192.168.1.11 on enp2s0 to 192.168.1.10 port 67 (xid=0x6917b6be)
Oct  5 20:40:20 renaud-pc dhclient[11710]: DHCPACK of 192.168.1.11 from 192.168.1.10
Oct  5 20:40:20 renaud-pc NetworkManager[1230]: <info>  [1538764820.7052]   address 192.168.1.11
Oct  5 20:40:20 renaud-pc NetworkManager[1230]: <info>  [1538764820.7052]   plen 24 (255.255.255.0)
Oct  5 20:40:20 renaud-pc dbus[1140]: [system] Activating via systemd: service name='org.freedesktop.nm_dispatcher' unit='dbus-org.freedesktop.nm-dispatcher.service'
Oct  5 20:40:20 renaud-pc NetworkManager[1230]: <info>  [1538764820.7052]   gateway 192.168.1.1
Oct  5 20:40:20 renaud-pc NetworkManager[1230]: <info>  [1538764820.7052]   server identifier 192.168.1.10
Oct  5 20:40:20 renaud-pc NetworkManager[1230]: <info>  [1538764820.7052]   lease time 120
Oct  5 20:40:20 renaud-pc NetworkManager[1230]: <info>  [1538764820.7053]   nameserver '192.168.1.10'
Oct  5 20:40:20 renaud-pc NetworkManager[1230]: <info>  [1538764820.7053]   nameserver '192.168.1.2'
Oct  5 20:40:20 renaud-pc NetworkManager[1230]: <info>  [1538764820.7053]   domain name 'lapalisse.lan'
Oct  5 20:40:20 renaud-pc NetworkManager[1230]: <info>  [1538764820.7053] dhcp4 (enp2s0): state changed bound -> bound
Oct  5 20:40:20 renaud-pc systemd[1]: Starting Network Manager Script Dispatcher Service...
Oct  5 20:40:20 renaud-pc dbus[1140]: [system] Successfully activated service 'org.freedesktop.nm_dispatcher'
Oct  5 20:40:20 renaud-pc systemd[1]: Started Network Manager Script Dispatcher Service.
Oct  5 20:40:20 renaud-pc nm-dispatcher: req:1 'dhcp4-change' [enp2s0]: new request (2 scripts)
Oct  5 20:40:20 renaud-pc nm-dispatcher: req:1 'dhcp4-change' [enp2s0]: start running ordered scripts...
Oct  5 20:40:20 renaud-pc dhclient[11710]: bound to 192.168.1.11 -- renewal in 54 seconds.
Oct  5 20:41:14 renaud-pc dhclient[11710]: DHCPREQUEST of 192.168.1.11 on enp2s0 to 192.168.1.10 port 67 (xid=0x6917b6be)
Oct  5 20:41:14 renaud-pc dhclient[11710]: DHCPACK of 192.168.1.11 from 192.168.1.10
Oct  5 20:41:14 renaud-pc NetworkManager[1230]: <info>  [1538764874.4872]   address 192.168.1.11
Oct  5 20:41:14 renaud-pc NetworkManager[1230]: <info>  [1538764874.4872]   plen 24 (255.255.255.0)
Oct  5 20:41:14 renaud-pc NetworkManager[1230]: <info>  [1538764874.4872]   gateway 192.168.1.1
Oct  5 20:41:14 renaud-pc NetworkManager[1230]: <info>  [1538764874.4873]   server identifier 192.168.1.10
Oct  5 20:41:14 renaud-pc NetworkManager[1230]: <info>  [1538764874.4873]   lease time 120
Oct  5 20:41:14 renaud-pc NetworkManager[1230]: <info>  [1538764874.4873]   nameserver '192.168.1.10'
Oct  5 20:41:14 renaud-pc NetworkManager[1230]: <info>  [1538764874.4873]   nameserver '192.168.1.2'
Oct  5 20:41:14 renaud-pc NetworkManager[1230]: <info>  [1538764874.4873]   domain name 'lapalisse.lan'
Oct  5 20:41:14 renaud-pc NetworkManager[1230]: <info>  [1538764874.4874] dhcp4 (enp2s0): state changed bound -> bound
Oct  5 20:41:14 renaud-pc dbus[1140]: [system] Activating via systemd: service name='org.freedesktop.nm_dispatcher' unit='dbus-org.freedesktop.nm-dispatcher.service'
Oct  5 20:41:14 renaud-pc systemd[1]: Starting Network Manager Script Dispatcher Service...
Oct  5 20:41:14 renaud-pc dbus[1140]: [system] Successfully activated service 'org.freedesktop.nm_dispatcher'
Oct  5 20:41:14 renaud-pc systemd[1]: Started Network Manager Script Dispatcher Service.
Oct  5 20:41:14 renaud-pc nm-dispatcher: req:1 'dhcp4-change' [enp2s0]: new request (2 scripts)
Oct  5 20:41:14 renaud-pc nm-dispatcher: req:1 'dhcp4-change' [enp2s0]: start running ordered scripts...
Oct  5 20:41:14 renaud-pc dhclient[11710]: bound to 192.168.1.11 -- renewal in 56 seconds.
Oct  5 20:42:10 renaud-pc dhclient[11710]: DHCPREQUEST of 192.168.1.11 on enp2s0 to 192.168.1.10 port 67 (xid=0x6917b6be)
Oct  5 20:42:10 renaud-pc dhclient[11710]: DHCPACK of 192.168.1.11 from 192.168.1.10
Oct  5 20:42:10 renaud-pc NetworkManager[1230]: <info>  [1538764930.9074]   address 192.168.1.11
Oct  5 20:42:10 renaud-pc NetworkManager[1230]: <info>  [1538764930.9074]   plen 24 (255.255.255.0)
Oct  5 20:42:10 renaud-pc NetworkManager[1230]: <info>  [1538764930.9074]   gateway 192.168.1.1
Oct  5 20:42:10 renaud-pc NetworkManager[1230]: <info>  [1538764930.9075]   server identifier 192.168.1.10
Oct  5 20:42:10 renaud-pc NetworkManager[1230]: <info>  [1538764930.9075]   lease time 120
Oct  5 20:42:10 renaud-pc NetworkManager[1230]: <info>  [1538764930.9075]   nameserver '192.168.1.10'
Oct  5 20:42:10 renaud-pc NetworkManager[1230]: <info>  [1538764930.9075]   nameserver '192.168.1.2'
Oct  5 20:42:10 renaud-pc NetworkManager[1230]: <info>  [1538764930.9075]   domain name 'lapalisse.lan'
Oct  5 20:42:10 renaud-pc NetworkManager[1230]: <info>  [1538764930.9075] dhcp4 (enp2s0): state changed bound -> bound
Oct  5 20:42:10 renaud-pc dbus[1140]: [system] Activating via systemd: service name='org.freedesktop.nm_dispatcher' unit='dbus-org.freedesktop.nm-dispatcher.service'
Oct  5 20:42:10 renaud-pc systemd[1]: Starting Network Manager Script Dispatcher Service...
Oct  5 20:42:10 renaud-pc dbus[1140]: [system] Successfully activated service 'org.freedesktop.nm_dispatcher'
Oct  5 20:42:10 renaud-pc systemd[1]: Started Network Manager Script Dispatcher Service.
Oct  5 20:42:10 renaud-pc nm-dispatcher: req:1 'dhcp4-change' [enp2s0]: new request (2 scripts)
Oct  5 20:42:10 renaud-pc nm-dispatcher: req:1 'dhcp4-change' [enp2s0]: start running ordered scripts...
Oct  5 20:42:10 renaud-pc dhclient[11710]: bound to 192.168.1.11 -- renewal in 58 seconds.

Visiblement ça ne plante donc pas à chaque fois. Tout à l'air correct côté wireshark également :
Titre: Connexion ethernet instable
Posté par: Nh3xus le 05 octobre 2018 à 20:52:53
Il me semble que les "errors" et les "drops" ne signifient pas la même chose.

Le compteur "errors" permet effectivement de voir les erreurs de trames liées à un câblage défectueux.

Le compteur "drops" compte le nombre de paquets reçus correctement mais que le système ne sait pas traiter.

Par exemple, un système Linux avec IPv6 désactivé va classer les paquets multicast IPv6 (NDP, ICMPv6, RA,...) dans la catégorie "drops".
Titre: Connexion ethernet instable
Posté par: renaud07 le 05 octobre 2018 à 21:24:02
A priori ce n'est pas un problème de câblage. Les drops ont disparu dès que j'ai rebooté le switch. Et même avec les drops la connexion fonctionnait je ne me suis aperçu de rien.

Je viens de me rappeler que j'ai eu aussi un soucis  similaire sur mon portable qui perd la connexion en wifi. Vu que le pilote n'est pas le même, il y a un seul élèment commun : network manager. Me demande s'il y aurait pas un bug qui traîne depuis longtemps.

Du coup je vais tester en passant directement par le fichier /etc/network/interfaces pendant une semaine, et si pas de déconnexion, on aura trouvé le coupable.

Oct  5 21:19:23 renaud-pc dhclient[1503]: DHCPREQUEST of 192.168.1.11 on enp2s0 to 192.168.1.10 port 67 (xid=0x35b3c6e5)
Oct  5 21:19:23 renaud-pc dhclient[1503]: DHCPACK of 192.168.1.11 from 192.168.1.10
Oct  5 21:19:23 renaud-pc root: /etc/dhcp/dhclient-enter-hooks.d/avahi-autoipd returned non-zero exit status 1
Oct  5 21:19:23 renaud-pc root: /etc/dhcp/dhclient-enter-hooks.d/samba returned non-zero exit status 1
Oct  5 21:19:23 renaud-pc dhclient[1503]: bound to 192.168.1.11 -- renewal in 57 seconds.
Oct  5 21:20:20 renaud-pc dhclient[1503]: DHCPREQUEST of 192.168.1.11 on enp2s0 to 192.168.1.10 port 67 (xid=0x35b3c6e5)
Oct  5 21:20:20 renaud-pc dhclient[1503]: DHCPACK of 192.168.1.11 from 192.168.1.10
Oct  5 21:20:20 renaud-pc root: /etc/dhcp/dhclient-enter-hooks.d/avahi-autoipd returned non-zero exit status 1
Oct  5 21:20:20 renaud-pc root: /etc/dhcp/dhclient-enter-hooks.d/samba returned non-zero exit status 1
Oct  5 21:20:20 renaud-pc dhclient[1503]: bound to 192.168.1.11 -- renewal in 59 seconds.
Oct  5 21:20:42 renaud-pc systemd[1]: Starting Daily apt download activities...
Oct  5 21:20:43 renaud-pc systemd[1]: Started Daily apt download activities.
Oct  5 21:21:20 renaud-pc dhclient[1503]: DHCPREQUEST of 192.168.1.11 on enp2s0 to 192.168.1.10 port 67 (xid=0x35b3c6e5)
Oct  5 21:21:20 renaud-pc dhclient[1503]: DHCPACK of 192.168.1.11 from 192.168.1.10
Oct  5 21:21:20 renaud-pc root: /etc/dhcp/dhclient-enter-hooks.d/avahi-autoipd returned non-zero exit status 1
Oct  5 21:21:20 renaud-pc root: /etc/dhcp/dhclient-enter-hooks.d/samba returned non-zero exit status 1
Oct  5 21:21:20 renaud-pc dhclient[1503]: bound to 192.168.1.11 -- renewal in 53 seconds.
Oct  5 21:22:13 renaud-pc dhclient[1503]: DHCPREQUEST of 192.168.1.11 on enp2s0 to 192.168.1.10 port 67 (xid=0x35b3c6e5)
Oct  5 21:22:13 renaud-pc dhclient[1503]: DHCPACK of 192.168.1.11 from 192.168.1.10
Oct  5 21:22:13 renaud-pc root: /etc/dhcp/dhclient-enter-hooks.d/avahi-autoipd returned non-zero exit status 1
Oct  5 21:22:13 renaud-pc root: /etc/dhcp/dhclient-enter-hooks.d/samba returned non-zero exit status 1
Oct  5 21:22:13 renaud-pc dhclient[1503]: bound to 192.168.1.11 -- renewal in 47 seconds.
Oct  5 21:23:01 renaud-pc dhclient[1503]: DHCPREQUEST of 192.168.1.11 on enp2s0 to 192.168.1.10 port 67 (xid=0x35b3c6e5)
Oct  5 21:23:01 renaud-pc dhclient[1503]: DHCPACK of 192.168.1.11 from 192.168.1.10
Oct  5 21:23:01 renaud-pc root: /etc/dhcp/dhclient-enter-hooks.d/avahi-autoipd returned non-zero exit status 1
Oct  5 21:23:01 renaud-pc root: /etc/dhcp/dhclient-enter-hooks.d/samba returned non-zero exit status 1
Oct  5 21:23:01 renaud-pc dhclient[1503]: bound to 192.168.1.11 -- renewal in 53 seconds.
Oct  5 21:23:55 renaud-pc dhclient[1503]: DHCPREQUEST of 192.168.1.11 on enp2s0 to 192.168.1.10 port 67 (xid=0x35b3c6e5)
Oct  5 21:23:55 renaud-pc dhclient[1503]: DHCPACK of 192.168.1.11 from 192.168.1.10
Oct  5 21:23:55 renaud-pc root: /etc/dhcp/dhclient-enter-hooks.d/avahi-autoipd returned non-zero exit status 1
Oct  5 21:23:55 renaud-pc root: /etc/dhcp/dhclient-enter-hooks.d/samba returned non-zero exit status 1
Oct  5 21:23:55 renaud-pc dhclient[1503]: bound to 192.168.1.11 -- renewal in 53 seconds.

On voit bien que c'est dhclient et non plus network manager qui gère le renew  :) Par contre effet de bord, la commade ip a renvoie un valid_lft forever

renaud@renaud-pc:~$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: enp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether d8:50:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.11/24 brd 192.168.1.255 scope global enp2s0
       valid_lft forever preferred_lft forever
    inet6 fe80::da50:e6ff:fe56:xxxx/64 scope link
       valid_lft forever preferred_lft forever
Titre: Connexion ethernet instable
Posté par: vivien le 05 octobre 2018 à 21:26:43
Sinon met un bail plus long.

Je vois souvent des bails d'une semaine.

Normalement tu renouvelle quand tu arrives à la moitié du bail.
Titre: Connexion ethernet instable
Posté par: renaud07 le 05 octobre 2018 à 21:36:01
Oui c'est ce que j'ai pensé. Mais faut bien que je valide ma théorie.

De toute façon c'est une ip statique lié à la MAC donc je pourrais tout aussi bien me mettre en manuel; ce que j'ai fait un temps d'ailleurs, mais ça n'a pas empêché que ça bug, moins certes, mais j'ai eu quand même droit à des coupures. C'est en partie pour cela que je suis retourné en 16.04 pensant résourde le problème...
Titre: Connexion ethernet instable
Posté par: renaud07 le 09 octobre 2018 à 19:57:18
Un bug de networkmanager semble bien se confirmer. 3 jours que la gestion se fait par dhclient directement, 3 jours que je n'ai eu aucune coupure ni "raté" ce que j'entends par là c'est : je suis sur une page, je clique sur un lien, ça m'affiche adresse introuvable, j'actualise la page dans la seconde et ça remarche. Ça me le faisait très souvent sur le forum d'ailleurs.

J'ai également retesté la 18.04 et tout fonctionne également, alors que c'était sur cette version que j'avais le plus de problèmes, sur celle-ci on peut dire que dans les 10 mintutes j'avais une coupure qui se résolvait qu'en déco/reco manuellement, elle pouvait même se répéter plusieurs fois par minute ! Le seul moyen d'arranger la situation était de passer en adressage manuel et encore il y avait parfois des loupés.

Maintenant le tout est de savoir ce qui provoque ça, et j'avoue que j'en ai aucune idée. D’autant plus que les logs sont vides...  :-\
Titre: Connexion ethernet instable
Posté par: eupalynos le 15 novembre 2018 à 21:16:44
Hello,

Le modèle de ma carte :
02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 09)

Ce qui suit est valable sous Debian Stretch mais peut-être que ça peut aider...

Vérifier avec lspci -n que c'est bien une 8168 (on sait jamais). Ça devrait te donner : 10ec:8168.

Ensuite vérifie quel est le pilote utilisé, par exemple avec ethtool :
# ethtool -i enp1s0 | grep driver
driver: r8169

Si tu vois r8169 (comme ici), il faut sans doute que tu installes le pilote r8168 (qui n'est pas libre).

Et donc, toujours pour Debian, il faut faire ça (après avoir ajouter les dêpot non-free) :
# apt-get install r8168-dkms
Source (entre autre) : How To get your Realtek RTL8111/RTL8168 working (https://www.unixblogger.com/how-to-get-your-realtek-rtl8111rtl8168-working-updated-guide)

A+
Titre: Connexion ethernet instable
Posté par: renaud07 le 17 novembre 2018 à 18:13:26
Merci pour la piste, je vais tester ça  :)
Titre: Connexion ethernet instable
Posté par: renaud07 le 18 novembre 2018 à 22:04:14
Alors, j'ai toujours des ratés, avec firefox qui mouline sur "recherche de l'hôte". Pas d'amélioration par rapport au pilote libre, donc. Je pensais que la gestion par dhclient aurait résolu le problème, mais non. C'est beaucoup plus stable qu'avec networkmanager mais j'ai toujours quelques secondes de flottement parfois, je n'avais visiblement pas testé assez longtemps.

En faisant un test de ping au même moment vers lafibre, je vois que ça attend puis le ping part quelques secondes plus tard. Et en résultat j'ai un paquet perdu. Je vais aussi creuser la piste DNS qu'on m'a suggéré en MP. Car je viens d'avoir un cas où j'ai lancé un ping vers une ip directement, et j'ai eu droit à recherche de l'hôte pendant plusieurs secondes, alors que le ping continuait normalement...

Je testerais aussi d'autres distributions car jusqu'à présent je n'ai fait qu'Ubuntu/Mint.  Pourquoi pas une Fedora pour commencer.
Titre: Connexion ethernet instable
Posté par: renaud07 le 13 décembre 2018 à 03:18:02
J'envisage séreusement de changer de carte mère, étant donné que ce bug est toujours présent (sans compter le son qui grésille de temps en temps et la corruption du BIOS (https://lafibre.info/materiel-informatique/bios-qui-se-corrompt-lors-dun-reset-usine/) dernièrement). Du coup je me pose la question suivante : rester sur un chip realtek, sachant que les CM moyen de gamme embarquent toutes un 8111 ou alors partir sur du intel.

Je me dis que peut-être c'est l’implèmentation de la carte mère qui est mal foutue et que donc je n'aurais aucun problème avec une autre marque.... de plus je vois que la lettre après 8111 n'est pas la même sur les CM récentes. C'est à priori les différentes révisons, sur la mienne c'est un 8111F sur les actuelles on trouve du 8111G et 8111H, j'en déduis donc que la H est la dernière version ?

Sur la CM de mon serveur (asrock Q1900 ITX) c'est apparemment un 8111GR (me demandez pas ce que la seconde lettre signifie) et je n'ai pas rencontré de soucis à priori.

Bref, j'hésite beaucoup, comme sur le fait de totalement renouveler ma configuration tant qu'à faire qui fête ses 5 ans cette année (là il vaudrait mieux bien choisir)...
Titre: Connexion ethernet instable
Posté par: renaud07 le 14 décembre 2018 à 16:53:20
Je crois avoir enfin percé le mystère des "recherche de l'hôte" intempestifs qui mettent plusieurs secondes à se résourde, faisant croire que la connexion tombe et revient quelques secondes après : A certains moments, au lieu de résoudre lafibre.info normalement, j'ai comme requête DNS lafibre.info.lapalisse.lan (lapalisse.lan étant mon domaine interne). Puis quand le DNS retourne que le domaine n’existe pas là il fait une requête normale.

Je remarque que ça le fait sur plusieurs sites, comme les numeriques ou deezer par exemple.

Tu m'étonnes...

Donc ça ne vient pas pas à priori du pilote (que j'accusais depuis le début), mais d'une mauvaise gestion du DNS... Une idée de ce qui provoquerait ça ?

On dirait qu'il prend pour un nom d'hôte les domaines, comme si je tapais simplement serveur au lieu de serveur.lapalisse.lan (quand je me connecte en SSH par exemple) et il me rajoute donc la valeur search de resolv.conf
Titre: Connexion ethernet instable
Posté par: Thornhill le 14 décembre 2018 à 17:14:48
quelle est la valeur du paramètre ndots dans resolv.conf ?
Titre: Connexion ethernet instable
Posté par: renaud07 le 14 décembre 2018 à 17:26:58
ndots ? J'ai rien de tout ça dans mon resolv.conf... juste nameserver et search.

Tu m'appends un truc, je ne savais pas qu'il pouvait y avoir un tas d’autres options (https://linux.die.net/man/5/resolv.conf) Ça m'apprendra à lire les man à moité  ;D

Si la valeur est à 1 par défaut (même sans l'écrire je suppose) c'est censé être bon, non ?
Titre: Connexion ethernet instable
Posté par: renaud07 le 15 décembre 2018 à 17:12:51
J'ai désactivé le domain-search dans mon DHCP, et il semblerait que ça fonctionne, je n'ai plus de requêtes bizarres ni de "recherche de l'hote" interminable, par contre ça m'oblige à taper mes adresses internes en entier mais bon c'est pas grave.

Il m'arrive toujours cependant d'avoir des ratés de connexions et le message n'est pas "Adresse introuvable", mais "Connexion échouée" (j'avais mal lu depuis tout ce temps). Ça me l'a fait au moins 3 fois aujourd'hui et on dirait que c'est lorsque j'attends trop sur une page (ou que je suis en train de rédiger une réponse un peu longue). Serait-ce la session TLS qui part en time-out un un turc similaire ?

J'essaie de reproduire le bug en laissant wireshark ouvert voir ce que ça raconte mais c'est pas facile.
Titre: Connexion ethernet instable
Posté par: Thornhill le 15 décembre 2018 à 18:33:43

Si la valeur est à 1 par défaut (même sans l'écrire je suppose) c'est censé être bon, non ?

Normalement oui, et pourtant dans la trace le resolver fait comme si la valeur était >1.

As-tu essayé de forcer la valeur à 1  pour voir ?
Titre: Connexion ethernet instable
Posté par: renaud07 le 16 décembre 2018 à 03:05:01
Ça à l'air de fonctionner  :) Mais ça m'oblige à bloquer resolv.conf en lecture seule, sinon à chaque reboot c'est effacé. Pas très pratique, mais bon je ne change pas de DNS tous les jours.

À confirmer, il semblerait que j'ai le même problème sur mon PC portable, le truc que je prenais également pour une instabilité wifi avec des résolutions DNS interminables, qui se finissaient parfois en adresse introuvable... Là ça va poser problème vu que je change de réseau souvent. Je testerais ça demain.

Ce que je n'arrive pas à comprendre, c'est que ça à l'air d'être un symptôme qui touche plusieurs versions d'ubuntu (ça me le fait aussi bien en 16.04 ou 18.04) alors comment se fait-il que je sois le seul à qui ça pose des problèmes ? Car sauf erreur, les box aussi envoient un domain-search (genre home pour la livebox)...
Titre: Connexion ethernet instable
Posté par: Thornhill le 16 décembre 2018 à 21:33:50
Pour le souci d'écrasement de resolv.conf, tu peux utiliser un script de sortie de dhclient pour ajouter l'option ndots en fin de fichier.
Cf  /etc/dhcp/dhclient-exit-hooks.d. et http://manpages.ubuntu.com/manpages/bionic/man8/dhclient-script.8.html (http://manpages.ubuntu.com/manpages/bionic/man8/dhclient-script.8.html)

Ensuite la raison pour laquelle le ndots n'est plus à un par défaut, je ne sais pas, il faudrait chercher les rapports de bugs, à moins que ce soit mal configuré dans un autre fichier quelque part.
Le code du resolver est dans la libC normalement.

Tu peux essayer de chercher ndots sous /etc :

find /etc -type f | xargs grep -i ndots
Titre: Connexion ethernet instable
Posté par: renaud07 le 17 décembre 2018 à 01:03:49
Cette commande est bizarre... J'ai droit à permission non accordée sur tous les fichiers passés en revue, même en root  ??? c'est le comportement normal s'il ne trouve rien ? (Sauf dans le resolv.conf où j'avais renseigné l'option)
renaud@renaud-pc:~$ find /etc -type f | xargs grep -i ndots
find: ‘/etc/ssl/private’: Permission non accordée
find: ‘/etc/cups/ssl’: Permission non accordée
find: ‘/etc/polkit-1/localauthority’: Permission non accordée
grep: /etc/gshadow-: Permission non accordée
grep: /etc/gshadow: Permission non accordée
grep: /etc/ufw/after6.rules: Permission non accordée
grep: /etc/ufw/before.rules: Permission non accordée
grep: /etc/ufw/user.rules: Permission non accordée
grep: /etc/ufw/after.rules: Permission non accordée
grep: /etc/ufw/user6.rules: Permission non accordée
grep: /etc/ufw/before6.rules: Permission non accordée
grep: /etc/ufw/after.init: Permission non accordée
grep: /etc/ufw/before.init: Permission non accordée
/etc/resolv.conf:options ndots:1
/etc/resolv.conf:options ndots:1
grep: /etc/ppp/pap-secrets: Permission non accordée
grep: /etc/ppp/chap-secrets: Permission non accordée
grep: /etc/systemd/system/snap-ubuntux2dmatex2dwelcome-220.mount: Aucun fichier ou dossier de ce type
grep: /etc/systemd/system/snap-ubuntux2dmatex2dwelcome-217.mount: Aucun fichier ou dossier de ce type
grep: /etc/systemd/system/snap-ubuntux2dmatex2dwelcome-199.mount: Aucun fichier ou dossier de ce type
grep: /etc/systemd/system/snap-softwarex2dboutique-31.mount: Aucun fichier ou dossier de ce type
grep: /etc/NetworkManager/system-connections/DHCP: Permission non accordée
/etc/NetworkManager/dispatcher.d/ndots:echo "options ndots:1" >> /etc/resolv.conf
grep: /etc/shadow: Permission non accordée
grep: /etc/vmware/usbarb.rules: Permission non accordée
grep: /etc/brlapi.key: Permission non accordée
grep: /etc/.pwd.lock: Permission non accordée
grep: /etc/security/opasswd: Permission non accordée
grep: /etc/sudoers: Permission non accordée
grep: /etc/cups/subscriptions.conf: Permission non accordée
grep: /etc/cups/subscriptions.conf.O: Permission non accordée
grep: /etc/ssh/ssh_host_ecdsa_key: Permission non accordée
grep: /etc/ssh/ssh_host_rsa_key: Permission non accordée
grep: /etc/ssh/ssh_host_ed25519_key: Permission non accordée
grep: /etc/shadow-: Permission non accordée
grep: /etc/sudoers.d/README: Permission non accordée
grep: /etc/apparmor.d/cache/usr.sbin.cups-browsed: Permission non accordée
grep: /etc/apparmor.d/cache/lightdm-guest-session: Permission non accordée
grep: /etc/apparmor.d/cache/usr.lib.libreoffice.program.senddoc: Permission non accordée
grep: /etc/apparmor.d/cache/usr.lib.libreoffice.program.oosplash: Permission non accordée
grep: /etc/apparmor.d/cache/usr.bin.man: Permission non accordée
grep: /etc/apparmor.d/cache/usr.lib.libreoffice.program.soffice.bin: Permission non accordée
grep: /etc/apparmor.d/cache/usr.sbin.cupsd: Permission non accordée
grep: /etc/apparmor.d/cache/usr.sbin.tcpdump: Permission non accordée
grep: /etc/apparmor.d/cache/usr.lib.libreoffice.program.xpdfimport: Permission non accordée
grep: /etc/apparmor.d/cache/usr.lib.snapd.snap-confine.real: Permission non accordée
grep: /etc/apparmor.d/cache/usr.sbin.ippusbxd: Permission non accordée
grep: /etc/apparmor.d/cache/sbin.dhclient: Permission non accordée

Pour le script, j'utilise networkmanager, pas dhcilent. Mais bon ça change pas grand chose, j'ai ajouté un script ndots dans /etc/NetworkManager/dispatcher.d avec comme contenu
#!/bin/sh
echo "options ndots:1" >> /etc/resolv.conf

Le seul soucis c'est que ça m'écrit 2 fois la ligne car il s'exécute une fois à la déconnexion et une fois à la reconnexion, mais bon, je pense pas que ça influe, si ?

EDIT : Avec 2 fois l'option j'ai de nouveau vu passer une résolution bizarre, mais je n'ai rien remarqué sur ma navigation. Vu que c'est aléatoire j'ai du mal à vérifier toutes les configurations possibles.
Titre: Connexion ethernet instable
Posté par: Thornhill le 17 décembre 2018 à 11:06:30

Le seul soucis c'est que ça m'écrit 2 fois la ligne car il s'exécute une fois à la déconnexion et une fois à la reconnexion, mais bon, je pense pas que ça influe, si ?


Je ne pense pas que ça pose problème d'avoir 2 fois l'option mais pour éviter ça il faut mettre une condition sur le deuxième argument reçu par le script :

if [ X$2 = Xup ] ; then
  echo "options ndots:1" >> /etc/resolv.conf
fi


 Each script receives two arguments, the first being the interface name of the device an operation just happened on, and second the action. For device actions, the interface is the name of the kernel interface suitable for IP configuration. Thus it is either VPN_IP_IFACE, DEVICE_IP_IFACE, or DEVICE_IFACE, as applicable. For the hostname and connectivity-change actions it is always "none".

The actions are:
(...)

up

The interface has been activated.



Pour ton problème de permission tu es certain d'être bien root au moment de passer la commande ? Que donne la commande "id" juste avant le find ?
Titre: Connexion ethernet instable
Posté par: renaud07 le 17 décembre 2018 à 14:02:12
Le script fonctionne nickel  ;) Je me doutais qu'il fallait rajouter une condition mais comme je suis très nul en prog, je ne savais pas quoi mettre. J'étais parti sur un sed c'est pour dire  ;D

Et aujourd’hui la commande fonctionne bien en root... Je n'y comprends plus rien. Par contre ça ne fonctionne pas ni en user normal ni avec sudo. J'ai du confondre faut croire.
root@renaud-pc:/home/renaud# find /etc -type f | xargs grep -i ndots
/etc/resolv.conf:options ndots:1
grep: /etc/systemd/system/snap-ubuntux2dmatex2dwelcome-220.mount: Aucun fichier ou dossier de ce type
grep: /etc/systemd/system/snap-ubuntux2dmatex2dwelcome-217.mount: Aucun fichier ou dossier de ce type
grep: /etc/systemd/system/snap-ubuntux2dmatex2dwelcome-199.mount: Aucun fichier ou dossier de ce type
grep: /etc/systemd/system/snap-softwarex2dboutique-31.mount: Aucun fichier ou dossier de ce type
/etc/NetworkManager/dispatcher.d/ndots:  echo "options ndots:1" >> /etc/resolv.conf
Titre: Connexion ethernet instable
Posté par: Thornhill le 17 décembre 2018 à 14:06:30
Et aujourd’hui la commande fonctionne bien en root... Je n'y comprends plus rien. Par contre ça ne fonctionne pas ni en user normal ni avec sudo.

Surement une fausse manip avec sudo : si tu fais le sudo uniquement sur le find par exemple le egrep sera lui exécuté avec les droits du user lambda qui n'a pas accès aux fichiers protégés (normal).

Ceci dit on n'est pas plus avancé sur la cause initiale du problème : le ndots doit surement être forcé quelque part et ça n'est pas stocké dans un fichier de config sous /etc....
Titre: Connexion ethernet instable
Posté par: renaud07 le 17 décembre 2018 à 14:14:16
Surement une fausse manip avec sudo : si tu fais le sudo uniquement sur le find par exemple le egrep sera lui exécuté avec les droits du user lambda qui n'a pas accès aux fichiers protégés (normal).

Quel c** c'est ça, j'avais complètent zappé de remettre sudo avant le grep ::)
Titre: Connexion ethernet instable
Posté par: Catalyst le 17 décembre 2018 à 14:36:53
Que donne la commande hostname ou équivalent sur les différents systèmes ?
Est-ce un FQDN complet ?
Titre: Connexion ethernet instable
Posté par: renaud07 le 17 décembre 2018 à 14:41:05
Que donne la commande hostname ou équivalent sur les différents systèmes ?
Est-ce un FQDN complet ?

Juste le nom d'hôte, pas de FQDN (qui d'ailleurs s'afficherait dans le terminal).

renaud@renaud-pc:~$ hostname
renaud-pc
renaud@renaud-pc:~$

Sinon, maintenant j'ai une triple requête :

Il demande forum.ubuntu-fr.org, l'ip est renvoyée, mais il demande de nouveau forum.ubuntu-fr.org.lapalisse.lan et comme il ne trouve pas il refait une requête classique :o  Le ndots à pas l'air de faire son effet... Mais bon cela ne bloque pas la navigation à priori, ça fait juste des requêtes inutiles.
Titre: Connexion ethernet instable
Posté par: renaud07 le 19 décembre 2018 à 16:28:36
C'est globalement plus stable avec ndots:1 (pas eu de connexion échouée depuis 2 jours, youpi), par contre j'ai remarqué que depuis que je surveille le trafic, j'ai de temps en temps des DNS retransmission... Et ça se ressent sur les requêtes qui sont plus longues à se faire, particulièrement quand il y a beaucoup de noms à résoudre comme sur le site de Dell.

Après je ne sais pas si ça a un rapport direct avec mon problème ?
Titre: Connexion ethernet instable
Posté par: Catalyst le 19 décembre 2018 à 23:39:11
L'interprétation faite par Wireshark est erronée. Ce ne sont pas des retransmissions mais des messages ICMP émis par .11 indiquant que son port 49685, en écoute de la réponse au query, n'est plus ouvert.

La résolution de nom est relativement longue à faire : 1,2s. Et dans le firewall du .11, le timer de durée de vie des "sessions" UDP est peut-être trop court.

Titre: Connexion ethernet instable
Posté par: renaud07 le 20 décembre 2018 à 13:51:52
Merci pour ces précisions, n'étant pas un expert de l'ICMP, je n'aurais jamais deviné ça seul. Et si en plus wireshark dit n'importe quoi... on est pas sorti de l'auberge  ::) Je me doutais que quelque chose clochait, car en théorie un paquet ICMP ne contient pas ce genre d'info mais sur le coup je me suis dit c'est peut-être une nouvelle RFC que je ne connais pas.

Si c'est un soucis de pare-feu, on va avoir un problème puisque il n'est pas activé sur cette machine...
Titre: Connexion ethernet instable
Posté par: Catalyst le 21 décembre 2018 à 00:15:55
Si c'est un soucis de pare-feu, on va avoir un problème puisque il n'est pas activé sur cette machine...

OMG, pardon, je me suis laissé un peu emporter là :)
Titre: Connexion ethernet instable
Posté par: renaud07 le 22 décembre 2018 à 03:19:54
Je viens de trouver un bug avec ndots qui ressemble à mon problème et que j'ai observé : https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674273

Pour faire court, si on demande un domaine qui n'existe pas, le résolveur fait systématiquement une requête avec le domain-search. Ce qui ne devrait pas se produire (quand j'ai vu ça la première fois je pensais que c'était normal).

Du coup, le fait que ça fasse une requête directe avec le domain-search de temps en temps ne m'étonne guère (sans doute un dommage collatéral). Et c'est un bug qui date de 2009 et n'a jamais été corrigé...

Il ne faut pas chercher plus loin à mon avis. J'ai donc supprimé pour de bon le domain-search de mon DHCP et raccourci mon NDD interne histoire que ce soit moins pénible taper.

EDIT : Je viens de constater un truc intéressant, le bug ne se produit que depuis firefox, si je fais un dig en console, ça renvoie simplement NXDOMAIN sans essayer avec le domain-search. Vous noterez le nombre hallucinant de requêtes envoyées pour rien  :o
Titre: Connexion ethernet instable
Posté par: Thornhill le 22 décembre 2018 à 11:31:22
Dig comme nslookup n'utilisent pas le resolver de la libC.
En utilisant ping par contre je suppose que tu auras le même comportement que FF.
Titre: Connexion ethernet instable
Posté par: renaud07 le 22 décembre 2018 à 13:03:15
C'est exact.
Titre: Connexion ethernet instable
Posté par: renaud07 le 22 décembre 2018 à 15:57:26
Il semblerait que ce soit un bug généralisé... J'ai testé debian et manjaro et c'est la même chose, malgré le ndots à 1 j'ai toujours une requête avec le domain-search.

Comment se fait-il que ça n'ai jamais été corrigé depuis presque 10 ans ? Ça ne gène vraiment aucun linuxien ou quoi ?

Je vais charger de vieilles versions d'ubuntu pour voir.
Titre: Connexion ethernet instable
Posté par: Thornhill le 22 décembre 2018 à 17:43:07
pour moi ça correspond au comportement attendu si  le FQDN n'existe pas :

    ndots:n

sets a threshold for the number of dots which must appear in a name given to res_query(3) (see resolver(3)) before an initial absolute query will be made. The default for n is 1, meaning that if there are any dots in a name, the name will be tried first as an absolute name before any search list elements are appended to it. The value for this option is silently capped to 15.
Titre: Connexion ethernet instable
Posté par: renaud07 le 22 décembre 2018 à 18:07:20
Effectivement j'avais dû mal traduire la première fois.

Mais ça n'explique toujours pas que ça génère aléatoirement une requête avec le domain-search alors que le FQDN existe bien... Je n'ai trouvé aucun rapport de bug là dessus.
Titre: Connexion ethernet instable
Posté par: renaud07 le 13 août 2019 à 02:57:18
Remontage de topic.

Depuis quelques semaines, j'ai remarqué que mon système ne résout plus les noms d'hôtes automatiquement. Pour que ça fonctionne il faut que je modifie resolv.conf à la main.

Je n'ai rien touché à mon DHCP ni à mes zones DNS (si ce n'est mettre à jour -passage de jessie à buster-). Vérification faite, la valeur domain-name est toujours bien envoyée dans la réponse DHCP. Du coup c'est bizarre que network-manager ne le prenne pas en compte...

J'ai également toujours mes fameux fails de résolution, et cette fois j'ai pensé à lancer un dig au même moment où FF me fait le coup du "recherche de l’hôte", et il se trouve que ça ne répond pas non plus, puis ça vient au bout de 5-6 sec et enfin le site s'affiche. Du coup on dirait bien un bug général.

A tout hasard, j'en ai trouvé un qui à l'air similaire au mien, est-ce que ça pourrait être ça ? : https://unix.stackexchange.com/questions/141163/dns-lookups-sometimes-take-5-seconds
Titre: Connexion ethernet instable
Posté par: renaud07 le 21 août 2019 à 22:22:30
Contre toute attente, il semblerait que ces 2 options combinées fonctionnent

options single-request-reopen  single-request
Cela fait 3 jours que je n'ai plus de "recherche de l'hôte" intempestifs.

 :D