Etat à maintenant, ce n’est pas ipv6, pour info les pbs relevés ce jour, à noter que sur PC3, les durées sont toujours très faibles.
17h23 PC3 7s
17h19 PC1 31mn
15h44 PC1 28mn
14h31 PC3 3s
14h13 PC3 10s
14h11 PC3 24s
14h09 PC1 KO 32mn
14h09 PC1 KO 21s
14h08 PC3 KO 9s
13h52 PC3 KO 19s
12h04 PC1 KO 13mn
12h04 PC1 KO 27s
J’ai déjà indiqué qu’un réseau Wifi qui se déconnecte de manière aléatoire c’est souvent un problème de carte ou de pilote WiFi.
Mais on ne sait toujours pas quel modèle tu utilises.
Nouvelle modif faite : suppression de la double IP dans PC1 et PC3
Dans la conf. de NetworkManager : auto -> manual
A noter que, les 2 PCs étant des portables, cette méthode me permet de me connecter sur des box dont l’adresse n’est pas 192.168.0.1 tout en ayant une IP fixe connue sur les box 192.168.0.1
Si il y a une autre solution je suis preneur.
Côté firmware c’est un peu plus compliqué, j’ai des erreurs inexpliquées, mais celles-ci étaient de fait déjà présentes avant le changement de la box, ceci dit c’est un point à éclaircir.
Cde utilisée : dmesg | grep firmware
PC1
[ 0.375294] Spectre V2 : Enabling Restricted Speculation for firmware calls
[ 15.693277] bluetooth hci0: firmware: failed to load brcm/BCM43142A0-04ca-2009.hcd (-2)
[ 15.693356] firmware_class: See https://wiki.debian.org/Firmware for information about missing firmware
[ 15.693431] bluetooth hci0: Direct firmware load for brcm/BCM43142A0-04ca-2009.hcd failed with error -2
[ 26.747801] r8169 0000:01:00.0: firmware: failed to load rtl_nic/rtl8168g-2.fw (-2)
[ 26.749019] r8169 0000:01:00.0: Direct firmware load for rtl_nic/rtl8168g-2.fw failed with error -2
[ 26.749025] r8169 0000:01:00.0 enp1s0: unable to load firmware patch rtl_nic/rtl8168g-2.fw (-2)
PC3
dmesg | grep firmware
[ 1.271689] [drm] Found UVD firmware Version: 1.43 Family ID: 15
[ 1.272026] [drm] Found VCE firmware Version: 52.0 Binary ID: 3
[ 1.640539] psmouse serio1: elantech: assuming hardware version 4 (with firmware version 0x6d4f02)
[ 265.101776] rtw_pci 0000:03:00.0: firmware failed to restore hardware setting
[ 267.085813] rtw_pci 0000:03:00.0: firmware failed to restore hardware setting
… même ligne plus de 20 fois
[ 2703.086826] rtw_pci 0000:03:00.0: firmware failed to restore hardware setting
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).
source /etc/network/interfaces.d/*
# The loopback network interface
auto lo
iface lo inet loopback
Pb de pilote, probablement, qui s’est révélé avec le chgt de la box?,
J’attends avant de lancer la cde que tu proposes, plein de choses à comprendre via la cde précédente et toujours pas de pb relevé sur PC1 depuis ma dernière modif (1 seule IP), alors que 5 , toujours courtes, sur PC3
Déjà un grand merci.
Bonjour,
Pour ma part, j’ai aussi une carte-wifi en BCM43XX et le fait que je fasse ceci à corriger mon problème.
Ensuite en lisant le compte rendu, il arrive pas à résoudre l’adresse DNS en IP.
As tu modifier le fichier ntp ? (Problème sur la ligne 41)
Ce sera (probablement) ma prochaine modif.
Pour le ntp, j’ai différents scripts ‹ rapide et mal faits › de maj de mon système suite à une nouvelle config (debian 9 à 10 en l’occurrence), cela vient probablement de là, je regarderai, ce n’est probablement pas grand chose.
Normalement une interface n’a pas à avoir deux adresses dans le même réseau car elle n’a qu’une seule adresse mac. donc dans le cas d’un envoi de paquets, si une erreur de table arp se produit, c’est la même carte réseau mais pas la même interface. C’est une anomalie d’avoir deux IP dans le même réseau.
Ensuite on ne met pas une adresse statique et une adresse DHCP du même réseau sur la même interface. si le cable et le wifi sont utilisé en même temps, alors on met deux réseaux différents: un pour le wifi un pour le cable.
sauf utilisation spécifique effective de l’IPv6 autant le désactiver, il n’a aucune utilité réelle dans un réseau local domestique.
dans certains cas, l’IPv6 va être préféré à l’IPv4. C’est souvent/parfois la configuration par defaut d’un système. d’où l’intérêt de désactiver l’IPv6 ou alors d’utiliser la configuration de /etc/gai.conf avec :
# For sites which prefer IPv4 connections change the last line to
#precedence ::ffff:0:0/96 100
Modif ce matin : suppression du Wifi 5g
Ce qui signidie, dexter74, que ta cde (apt install --reinstall broadcom-sta-dkms) n’a pas fonctionné … c’eut été trop simple.
Info complémentaire : après 2 jours d’utilisation de mes scripts je m’aperçois que je n’ai pas d’erreur la nuit et que les erreurs revienne vers 5 ou 6h avant mon réveil, donc mes PCs non chargés.
Ou de grosses perturbations électromagnétiques extérieures (genre le micro onde du voisin qui se lève tôt très mal isolé)?
Ou un impact du réseau externe sur la box?
ou … à suivre 2 jours ce n’est pas encore suffisant.
Pour ton problème, tu peux acheter des modules CPL pour pallier au problème électromagnétique .
Tu peux aussi déplacer tes PC.
Tu peux aussi trop sollicité ton réseau WIFI, celui-ci décroche ou la carte-wifi est surchargé .
Je n’ai pas répondu à tes questions 1 à 4 d’il y a 3 jours car j’attends de tous simplifier, concernant la 4, j’ai déjà et encore en service actuellement 2 modules CPL (1 sur la box , 1 dans une autre pièce)
Ceci dit j’ai cité une possibilité de perturbation électromagnétique mais je n’y crois pas beaucoup (voir point suivant)
Ce sont des PCs portables et, bien sûr, je les ai déjà déplacés, la plupart de mes essais sont fait dans la même pièce que la Box, donc à moins de 3m.
C’est un point à vérifier, en particulier j’ai un syncthing de 80 GO entre les 2 PCs et la perte du réseau le dérange (réanalyse) mais est-ce que cela pourrait être la cause? Sachant que j’ai augmenté progressivement la taille à 80Go et que cette dernière taille a du arriver concomitamment au chgt de la box.
