Répéteur Wifi

  • État Nouveau
  • Pourcentage achevé
    0%
  • Type Anomalie
  • Catégorie Répéteur Wifi 5
  • Assignée à Personne
  • Système d'exploitation Tous
  • Sévérité Basse
  • Priorité Très Basse
  • Basée sur la version 1.0
  • Due pour la version Non décidée
  • Échéance Non décidée
  • Votes
  • Privée
Concerne le projet: Répéteur Wifi
Ouverte par fcrozat - 07/12/2020

FS#33377 - Regression dans la détection de boucle réseau

Depuis la mise à jour du répéteur en version 1.2.8, j’ai constaté quelques pertes de connexion qui semblent liées à la détection de boucle:

Le répéteur est relié en wifi à une freebox Delta.

Le port Ethernet du répéteur est lié à la docking station d’un laptop (sous Linux) qui est connecté à la fois en ethernet (lorsque docké) et en wifi (donc sur le répéteur normalement). Le wifi reste toujours actif.

Par défaut, NetworkManager positionne une metrique plus basse pour l’ethernet, qui est normalement favorisé:
default via 192.168.1.254 dev eth0 proto dhcp metric 100
default via 192.168.1.254 dev wlan0 proto dhcp metric 600

Cette configuration fonctionnait sans aucun problème depuis la sortie du répéteur wifi (l’utilisation de l’ethernet est uniquement pour avoir de meilleures performances par rapport au wifi / répéteur).

Par moment (c’est assez rare), mon laptop perd sa connexion (plus de ping sortant par exemple), en utilisant Freebox Connect, je vois que le répéteur n’est plus vu comme connecté. Lors de la dernière déconnexion, l’application Freebox Connect indiquait que le répéteur était connecté en ethernet (et non plus en wifi). J’ai coupé le wifi sur mon laptop et le répéteur est reparti en connexion Wifi.

Les problèmes sont apparus depuis le sortie du dernier firmware.

Admin
rpomme a commenté le 10.12.2020 15:56

Bonjour @fcrozat,

J'imagine qu'il n'y a pas de façon de rendre le problème facilement reproductible.
Si j'ai bien compris votre config, comme eth0 et wlan0 ne sont pas bridgées, elles ont une MAC et même une IP différente. Cela ne devrait en principe pas créer de boucle.

Juste une idée qui me vient à l'esprit, mais qui a peu de chance de marcher (elle ne colle pas vraiment avec l'observation du répéteur qui se déconnecte, mais ne peut pas faire de mal). Par défaut linux peut répondre sur une interface (disons dans votre cas wlan0) à un paquet ARP qui demande la MAC pour l'IP d'une autre interface (disons eth0), donc le répéteur ou la Gateway pourrait penser que l'IP de eth0 par exemple est accessible sur l'interface wifi de la GW pouvant possiblement créer des problèmes. Pourriez vous donc, s'il vous plait, tester de configurer linux de telle sorte qu'il ne reponde aux ARP que si l'IP demandée est celle de l'interface qui les reçoit:

- echo 2 > /proc/sys/net/ipv4/conf/all/arp_ignore
- echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce

Si cela ne corrige pas le problème (c'est probable), lorsqu'il se reproduit pourriez vous, s'il vous plait, me donner le résultat de ces 2 commandes:

- ip route show table all
- iw dev wlan0 station dump

Aussi, si c'est possible une trace réseau de chaque interface pendant 1minute ou 2 pendant le problème pourrait sûrement aider :
- tcpdump -nei eth0 -w output-eth0.pcap
- tcpdump -nei wlan0 -w output-wlan0.pcap

Petite note, je pense que ce que vous essayez de faire pourrait être plus "propre" si vous utilisiez une interface de bonding en mode active-backup (voir https://wiki.debian.org/Bonding). Je ne vais pas vous mentir cette config n'a jamais été réellement testée et risque elle aussi de créer des problèmes (bien qu'en l'utilisant vous n'aurez pas 2 interfaces actives en même temps). Si jamais vous optiez pour cette solution mais que vous rencontriez quand même des problèmes n'hésitez pas à les remonter dans ce thread.

Merci d'avoir pris le temps de remonter le problème.

fcrozat a commenté le 10.12.2020 16:30

Je confirme que je n'ai pas eu beaucoup de fois le problème (2/3 fois depuis la maj du firmware), mais c'était assez pour me faire soupconner une régression (vu que le problème ne s'était jamais produit avant).

eth0 et wlan0 ont bien des IP et MAC address différentes.

Je vais tester les modifs ARPs (en espérant que le problème se reproduise ;)

Je regarderai aussi pour le bonding, mais vu que ce n'est pas la façon dont nous (SUSE/openSUSE) configurons par défaut les laptops avec docking station, je préfèrerai autant avoir une configuration la plus proche posssible de nos utilisateurs (ou alors, il faudra que je discute avec notre mainteneur NetworkManager pour voir si ça a un intérêt d'avoir ça par défaut) ;)

fcrozat a commenté le 10.12.2020 16:52

Le problème vient de se reproduire à l'instant (après changement arp_ignore / arp_announce). Je n'ai pas pu faire de trace réseau. Débrancher le cable ethernet n'a pas résolu le problème. La freebox ne voyait plus le répéteur (dans freebox connect) mais le répéteur avait toujours un AP wifi disponible. Pas de diode allumé pour signaler une coupure de la liaison wifi sur le répéteur.

route:
default via 192.168.1.254 dev eth0 proto dhcp metric 20100
default via 192.168.1.254 dev wlan0 proto dhcp metric 20600
10.0.0.0/8 via 10.163.42.85 dev tun0 proto static metric 50
10.163.40.1 via 10.163.42.85 dev tun0 proto static metric 50
10.163.42.85 dev tun0 proto kernel scope link src 10.163.42.86 metric 50
137.65.0.0/16 via 10.163.42.85 dev tun0 proto static metric 50
147.2.0.0/16 via 10.163.42.85 dev tun0 proto static metric 50
149.44.0.0/16 via 10.163.42.85 dev tun0 proto static metric 50
151.155.128.0/17 via 10.163.42.85 dev tun0 proto static metric 50
164.99.0.0/16 via 10.163.42.85 dev tun0 proto static metric 50
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.20 metric 100
192.168.1.0/24 dev wlan0 proto kernel scope link src 192.168.1.16 metric 600
192.168.1.254 dev eth0 proto static scope link metric 100
192.168.200.0/24 dev virbr0 proto kernel scope link src 192.168.200.1 linkdown
195.135.220.10 via 192.168.1.254 dev eth0 proto static metric 100
local 10.163.42.86 dev tun0 table local proto kernel scope host src 10.163.42.86
broadcast 127.0.0.0 dev lo table local proto kernel scope link src 127.0.0.1
local 127.0.0.0/8 dev lo table local proto kernel scope host src 127.0.0.1
local 127.0.0.1 dev lo table local proto kernel scope host src 127.0.0.1
broadcast 127.255.255.255 dev lo table local proto kernel scope link src 127.0.0.1
broadcast 192.168.1.0 dev wlan0 table local proto kernel scope link src 192.168.1.16
broadcast 192.168.1.0 dev eth0 table local proto kernel scope link src 192.168.1.20
local 192.168.1.16 dev wlan0 table local proto kernel scope host src 192.168.1.16
local 192.168.1.20 dev eth0 table local proto kernel scope host src 192.168.1.20
broadcast 192.168.1.255 dev wlan0 table local proto kernel scope link src 192.168.1.16
broadcast 192.168.1.255 dev eth0 table local proto kernel scope link src 192.168.1.20
broadcast 192.168.200.0 dev virbr0 table local proto kernel scope link src 192.168.200.1 linkdown
local 192.168.200.1 dev virbr0 table local proto kernel scope host src 192.168.200.1
broadcast 192.168.200.255 dev virbr0 table local proto kernel scope link src 192.168.200.1 linkdown
::1 dev lo proto kernel metric 256 pref medium
2620:113:80c0:8360::1 dev tun0 proto kernel metric 50 pref medium
2620:113:80c0:8360::1 dev tun0 proto kernel metric 256 pref medium
2620:113:80c0:8360::1094 dev tun0 proto kernel metric 50 pref medium
2620:113:80c0:8000::/50 via 2620:113:80c0:8360::1 dev tun0 proto static metric 50 pref medium
2a01:e0a:1f0:7990::/64 dev eth0 proto ra metric 100 pref medium
2a01:e0a:1f0:7990::/64 dev wlan0 proto ra metric 600 pref medium
fe80::/64 dev eth0 proto kernel metric 100 pref medium
fe80::/64 dev wlan0 proto kernel metric 600 pref medium
default via fe80::3627:92ff:fe64:3e9e dev eth0 proto ra metric 20100 pref medium
default via fe80::3627:92ff:fe64:3e9e dev wlan0 proto ra metric 20600 pref medium
local ::1 dev lo table local proto kernel metric 0 pref medium
local 2620:113:80c0:8360::1094 dev tun0 table local proto kernel metric 0 pref medium
local 2a01:e0a:1f0:7990:8b0f:14b7:10fc:87e9 dev wlan0 table local proto kernel metric 0 pref medium
local 2a01:e0a:1f0:7990:d88b:c638:c81b:4411 dev eth0 table local proto kernel metric 0 pref medium
local fe80::3d8c:4c26:a9ce:1f09 dev wlan0 table local proto kernel metric 0 pref medium
local fe80::ae25:8a75:6a74:f50a dev tun0 table local proto kernel metric 0 pref medium
local fe80::cf99:7145:9eb5:6369 dev eth0 table local proto kernel metric 0 pref medium
ff00::/8 dev eth0 table local metric 256 pref medium
ff00::/8 dev wlan0 table local metric 256 pref medium
ff00::/8 dev tun0 table local metric 256 pref medium

wifi:
Station 8c:97:ea:9e:6a:94 (on wlan0) 

inactive time:	468 ms
rx bytes:	318107
rx packets:	1846
tx bytes:	158904
tx packets:	1368
tx retries:	59
tx failed:	0
beacon loss:	1
beacon rx:	1988
rx drop misc:	80
signal:  	-41 [-52, -41] dBm
signal avg:	-43 [-50, -40] dBm
beacon signal avg:	215 dBm
tx bitrate:	780.0 MBit/s VHT-MCS 8 80MHz short GI VHT-NSS 2
rx bitrate:	6.0 MBit/s
rx duration:	0 us
authorized:	yes
authenticated:	yes
associated:	yes
preamble:	long
WMM/WME:	yes
MFP:		yes
TDLS peer:	no
DTIM period:	2
beacon interval:120
short slot time:yes
connected time:	246 seconds

J'ai du rebooter le répéteur.

Je me demande si le problème est vraiment lié à une boucle

Admin
rpomme a commenté le 10.12.2020 18:00

Merci, je ne crois pas non plus a un problème de boucle réseau. Plutôt un problème de topologie du mesh.

Pour être sûr de bien avoir compris le setup, lors de l'incident le répéteur était il connecté à la GW en ethernet ? Ou seulement en Wi-Fi ?

Juste une petite remarque sans lien avec le problème; ce genre de routes :
broadcast 192.168.1.0 dev wlan0 table local proto kernel scope link src 192.168.1.16
broadcast 192.168.1.0 dev eth0 table local proto kernel scope link src 192.168.1.20

Me fait penser que la solution à 2 interfaces 2 IPs 2 routes pourrait ne pas parfaite (même si je comprends tout à fait ses avantages), car pour moi les paquets broadcast/multicast peuvent partir sur wlan0 au lieu d'eth0.

Mais bon dans tous les cas ce n'est pas ça qui devrait crasher le réseau comme cela.

Merci.

fcrozat a commenté le 10.12.2020 18:18

Le répéteur n'est jamais connecté en ethernet à la Freebox Delta, uniquement en wifi.

L'ethernet sert uniquement à "alimenter" le dock du portable, les performances étant un peu meilleures en débit utile via l'ethernet.

Si vous voulez vous connecter sur le répéteur/la delta pour récupérer des logs ou autres:

MAC du répéteur: 8C97EA562FCC
Mac de la Delta: 34:27:92:64:3E:9E

Admin
rpomme a commenté le 10.12.2020 18:29

Merci,

Justement tout à l'heure il était apparemment détecté sur le deuxième port de la GW. Je pense que le problème vient de là, je vais essayer de comprendre pourquoi.

fcrozat a commenté le 15.12.2020 12:53

Bonjour,

le problème vient de se reproduire (arp_ignore / arp_announce étaient à 0) et j'ai les traces réseau tcpdump. Où puis-je vous les transmettre ?

Admin
rpomme a commenté le 15.12.2020 13:28

Bonjour @fcrozat,

Merci pour ces traces, vous avez normalement reçu un mail sur l'adresse associée à ce compte.

Chargement...

Activer les raccourcis clavier

Liste des tâches

Détails de la tâche

Édition de la tâche