Connection internet instable sous Bullseye

Support Debian
Tags: #<Tag:0x00007f7ada495ac8>
#1

Bonjour à tous,
depuis que je suis passé de Debian Buster à Bullseye ma connection internet est devenu instable, voir inexistante. Mon navigateur m’affiche parfois la page recherchée mais je perds aussitôt la connection dès que j’essaie d’aller plus loin.

Pour tester ma connection j’entre ceci dans une console:

traceroute debian-fr.org
debian-fr.org: Name or service not known
Cannot handle "host" cmdline arg 'debian-fr.org' on position 1 (argc 1)

puis:

traceroute 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
1 User(192.168.1.13) 2852.60 ms !H 2852.619 ms !H 2852.611 ms !H

Le Wiki de debian indique que « Depuis Stretch, les nouveaux systèmes n’utilisent par défaut désormais plus les anciens noms d’interface tels que eth0, eth1, wlan0, wlan1 »

En affichant la liste des connections réseaux :
nmcli

wlan0 ; connected to liveBox-70CA
« Qualcom Atheros AR9465 »
wifi (ath9k), 8C:51:D8:B2:6F:TD, hw, mtu 1500
ip4 default
…
p2p-dev-wlan0 : disconnected
…
eth0 : unavailable
…
lo : unmanaged
…
DNS configuration :
servers : 192:168:1.1
domains:home
interface : wlan0

wlan0 est donc actif alors qu’il s’agit d’une ancienne interface

Cela peut-il à voir avec mon problème ?
merci

ps: mon portable à plus de 4 ans

#2

Chez moi avec bulleyes, cela varie énormément et ce n’est pas étonnant vu la masse des mises à jour quotidiennes. Parfois, après le démarrage, j’ai spontanément une bonne connexion et parfois, après le démarrage, je suis obligé de relancer la connexion ( ce que je fais avec les outils graphiques ) pour avoir une connexion 100 % correcte.

Mais même quand le symbole connexion correcte ne s’affiche pas, la quasi-totalité des sites s’affichent sans problèmes. Les seuls problèmes systématiques sont la non-connexion de l’application météo de Gnome et certains soirs l’instabilité de Redshift sûrement due à la connexion aléatoire à geoclue.

Mais je n’ai jamais investigué sur ces petits problèmes puisqu’il est aléatoire et qu’une simple reconnexion suffit à résoudre le problème et aussi vu que les paquets sont constamment en évolution, tout raisonnement risquerait d’être invalidé par ces changements.

Mais ton problème est plus profond et différent du mien et je suis chez des amis lève-tard et avec Windows ce matin.

#3

aucun problème de connexion chez moi.
C.F

journalctl | grep Network

Le nommage des interfaces réseaux est anecdotique à mon avis et ça date de stretch
https://www.debian.org/releases/stretch/amd64/release-notes/ch-whats-new.fr.html#new-interface-names

pour avoir la nouvelle règle de nommage il faut supprimer la règle udev

sudo rm /etc/udev/rules.d/70-persistent-net.rules

https://www.freedesktop.org/software/systemd/man/systemd.net-naming-scheme.html

systemctl status  systemd-udevd.service -l --no-pager
● systemd-udevd.service - udev Kernel Device Manager
     Loaded: loaded (/lib/systemd/system/systemd-udevd.service; static; vendor preset: enabled)
     Active: active (running) since Sun 2020-01-05 08:46:52 CET; 33min ago
TriggeredBy: ● systemd-udevd-kernel.socket
             ● systemd-udevd-control.socket
       Docs: man:systemd-udevd.service(8)
             man:udev(7)
   Main PID: 279 (systemd-udevd)
     Status: "Processing with 20 children at max"
      Tasks: 1
     Memory: 42.0M
     CGroup: /system.slice/systemd-udevd.service
             └─279 /lib/systemd/systemd-udevd

janv. 05 08:46:53 debian mtp-probe[350]: bus: 3, device: 3 was not an MTP device
janv. 05 08:46:53 debian mtp-probe[356]: checking bus 5, device 2: "/sys/devices/pci0000:00/0000:00:13.0/usb5/5-2"
janv. 05 08:46:53 debian mtp-probe[356]: bus: 5, device: 2 was not an MTP device
janv. 05 08:46:53 debian mtp-probe[358]: checking bus 1, device 2: "/sys/devices/pci0000:00/0000:00:12.2/usb1/1-3"
janv. 05 08:46:53 debian mtp-probe[357]: checking bus 6, device 2: "/sys/devices/pci0000:00/0000:00:14.5/usb6/6-1"
janv. 05 08:46:53 debian mtp-probe[357]: bus: 6, device: 2 was not an MTP device
janv. 05 08:46:53 debian mtp-probe[358]: bus: 1, device: 2 was not an MTP device
janv. 05 08:46:55 debian systemd-udevd[300]: Using default interface naming scheme 'v243'.
janv. 05 08:46:55 debian systemd-udevd[300]: ethtool: autonegotiation is unset or enabled, the speed and duplex are not writable.
janv. 05 08:46:55 debian systemd-udevd[297]: Using default interface naming scheme 'v243'.

netstat -r
Table de routage IP du noyau
Destination     Passerelle      Genmask         Indic   MSS Fenêtre irtt Iface
default         _gateway        0.0.0.0         UG        0 0          0 wlp3s0b1
link-local      0.0.0.0         255.255.0.0     U         0 0          0 wlp3s0b1
192.168.1.0     0.0.0.0         255.255.255.0   U         0 0          0 wlp3s0b1

Les instabilités ont probablement plus à voir avec le driver puisque tu es correctement connecté

wlan0 ; connected to liveBox-73CA
« Qualcom Atheros AR9465 »
wifi (ath9k), 6C:71:D9:A3:5F:FD, hw, mtu 1500

voir ici
https://wiki.debian.org/fr/ath9k

#4

merci pour vos remarques,
voici ce que me donne systemctl et netstat:systemctl%20status

en redémarrant ma connection via:

service network-manager restart

je retrouve ma connection mais elle demeure instable, même après l’ajout de

[device]
wifi.scan-rand-mac-address=no

dans /etc/NetworkManager/NetworkManager.conf

#5

pour les infos sur la connexion wifi

sudo iwconfig

exemple

wlp3s0b1  IEEE 802.11  ESSID:"E-G"  
          Mode:Managed  Frequency:2.412 GHz  Access Point: 00:17:33:BB:CC:DD  
          Bit Rate=54 Mb/s   Tx-Power=20 dBm   
          Retry short limit:7   RTS thr:off   Fragment thr:off
          Encryption key:off
          Power Management:off
          Link Quality=67/70  Signal level=-43 dBm  
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:19  Invalid misc:216   Missed beacon:0

Power Management:off permet de laisser l’alimentation au maximum.

les instabilités c’est connu
https://www.google.com/search?client=firefox-b-d&q=ath9k+instable

on peut aussi supprimer le mécanise de randomisation de mac addresse
dans les parametres de connection dans le dossier

/etc/NetworkManager/system-connections/

pour le fichier correspondant à la connection wifi, mettre dans la section wifi

[wifi]
cloned-mac-address=permanent

C.F
https://blogs.gnome.org/thaller/2016/08/26/mac-address-spoofing-in-networkmanager-1-4-0/
https://developer.gnome.org/NetworkManager/stable/NetworkManager.conf.html#device-spec

#6

Merci pour les liens, je comprends mieux la nécessité d’une adresse MAC aléatoire
J’ai tout de même modifié le fichier correspondant à ma box en ajoutant dans la partie [wifi]

cloned-mac-address=permanent

la connection reste cependant instable., et en vérifiant le débit avec iwconfig,
j’observe un Bit Rate variant en 72 à 1 Mb/s en moins d’une minute.

Y’a t-il un autre moyen de résoudre ce problème ?

l’instabilité de la connection ne me permet même pas de faire la moindre mise à jour !..