- État Nouveau
- Pourcentage achevé
- Type Anomalie
- Catégorie LAN → WiFi
- Assignée à Personne
- Système d'exploitation Freebox V9 (Ultra)
- Sévérité Critique
- Priorité Moyenne
- Basée sur la version 4.9.6
- Due pour la version Non décidée
-
Échéance
Non décidée
-
Votes
1
- enzo fournet (05/08/2025)
- Privée
Concerne le projet: Freebox Server (Ultra V9/ Pop V8/ Delta V7 / Revolution V6 / Mini 4K)
Ouverte par enzo fournet - 22/06/2025
Dernière modification par pablomg - 05/08/2025
Ouverte par enzo fournet - 22/06/2025
Dernière modification par pablomg - 05/08/2025
FS#40377 - Gros soucis de connectivité sur les répéteur pop
Bonjour,
Les répéteurs pop de ma box n’arrêté pas de se déconnecter, et cela, très régulièrement.
Lorsque j’essaie de les ping, il y a souvent des erreurs et parfois des erreurs très étranges :
64 bytes from 192.168.0.221: icmp_seq=574 ttl=63 time=24.789 ms 64 bytes from 192.168.0.221: icmp_seq=575 ttl=63 time=26.576 ms 64 bytes from 192.168.0.221: icmp_seq=576 ttl=63 time=25.631 ms 64 bytes from 192.168.0.221: icmp_seq=577 ttl=63 time=23.788 ms 64 bytes from 192.168.0.221: icmp_seq=578 ttl=63 time=25.727 ms Request timeout for icmp_seq 579 Request timeout for icmp_seq 580 Request timeout for icmp_seq 581 Request timeout for icmp_seq 582 Request timeout for icmp_seq 583 Request timeout for icmp_seq 584 Request timeout for icmp_seq 585 Request timeout for icmp_seq 586 Request timeout for icmp_seq 587 64 bytes from 192.168.0.221: icmp_seq=587 ttl=63 time=1057.291 ms
IP des répéteurs :
- 192.168.0.221
- 192.168.0.55
J’ai un répéteur connecté en wifi à la box le 55 et l’autre en filaire à travers un mikrotik CRS305 connecté en SFP+. Je reste disponible pour faire des tests.
MAC de la box :
38:07:16:C2:8D:B2
En version 4.9.6, que je ne peux pas sélectionner sur le ticket.
Chargement...
Activer les raccourcis clavier
- Alt + ⇧ Shift + l Se connecter/Se déconnecter
- Alt + ⇧ Shift + a Ouvrir une tâche
- Alt + ⇧ Shift + m Mes recherches
- Alt + ⇧ Shift + t Rechercher par ID de tâche
Liste des tâches
- o Ouvrir la tâche sélectionnée
- j Déplacer le curseur vers le bas
- k Déplacer le curseur vers le haut
Détails de la tâche
- n Tâche suivante
- p Tâche précédente
- Alt + ⇧ Shift + e ↵ Enter Modifier cette tâche
- Alt + ⇧ Shift + w Surveiller
- Alt + ⇧ Shift + y Fermer cette tâche
Édition de la tâche
- Alt + ⇧ Shift + s Enregistrer la tâche
Bonjour
Les 2 sont déconnectés simultanément ? Le reste des services (Wifi de la box, TV, etc) sont fonctionnels quand les répéteurs se déconnectent ?
Cdt
Bonjour,
Lors des tests de ping, ce n’est pas systématique. Les déconnexions ne semblent pas directement corrélées, mais quand l’un dysfonctionne, l’autre aussi, souvent peu après.
On pourrait donc dire qu’ils déconnent en même temps, mais avec un décalage d’environ 10 à 30 secondes.
J'oubliais le reste des services semblent fonctionner sans difficulté.
Bonjour,
Tout d'abord, je vous conseille de rebooter votre box pour récupérer la version 4.9.7, vous avez eu des crashs dans le passé qui devrait être corrigé par cette version.
Ensuite, je vois le répéteur .55 qui est censé être connecté en Wi-Fi n'est pas connecté ; est ce qu'il a été débranché ? Pour le répéteur .221 qui est connecté via le switch, il a effectivement l'air de galérer à se connecter. Les répéteurs utilisent des protocoles bas niveau pour se configurer qui peuvent potentiellement être filtré par des switchs managés, est ce que vous pouvez le connecter directement sur les ports ethernet de la box et voir s'il fonctionne mieux ?
Bien à vous
Bonjour,
celui qui est en wifi est bien sous tension mais ne fonctionne pas.
Je vous tiens au courant pour l'autre.
Box mise à jour.
Le répéteur sans fil fonctionne depuis que le répéteur filaire ne passe plus par le switch. J'ai un Mikrotik CRS305 qu'est ce que je devrai faire pour éviter ce soucis ?
Petite précision, les deux fonctionnent correctement maintenant.
Bonjour,
Je n'ai aucune connaissance sur RouterOS/Swit mais l'idée ça va être de désactiver la détection de boucle ou le filtrage des paquets STP sur le switch.
Bien à vous
Bonjour
@pablomg
le souci ne serait il pas ressemblant à celui que j'ai constaté dans ce ticket :
https://dev.freebox.fr/bugs/task/39966
Voir mes commentaires à partir de celui-ci:
https://dev.freebox.fr/bugs/task/39966#comment186638
et notamment ceux-ci:
https://dev.freebox.fr/bugs/task/39966#comment186642 https://dev.freebox.fr/bugs/task/39966#comment186648
PS: le souci ici ressemble à une 'duplicate IP' ou a du 'mac flap' et cela cause des boucles qui sont cut par spanning-tree (mis en evidence lors des tests dans le ticket DIAGRAL 39966, après pas besoin de plusieurs répeters, 1 seul suffit a créer une boucle entre ses différentes cartes réseaux)
La désactivation de spanning-tree cause un écroulement instantanée du réseau (broadcast storm) quand le storm control n'est pas réglé pour éviter la perte
total du réseau (après ça ne fonctionne pas mieux 99,99999% des paquets sont des trames L2 qui bouclent)
Si vous voulez vous pouvez faire les tests suivants:
mettez un firewall en transparent mode
ou
un switch manageable
entre le répeteur et la box et capturez le trafic
Pour ceux qui ont des switchs fibre Cisco ou des firewall Fortigate, chez moi le process de capture donne:
sur le control-plane des switchs (cpu based) :
Sinon sur le data-plane des switchs (ASIC based) pour capturer le port physique du repeter, ici branché sur eth1/1/18 et mis en miroir eth1/1/20 sur :
verification:
Puis sur mon laptop branché sur le port eth1/1/20:
Sinon capture direct sur les firewalls (beaucoup plus simple):
avec x1 port du repeter
Une fois capturé si certain ne savent pas lire les pcap avec tshark -r / wireshark, postez ici on le fera
Cordialement
nbanba
Bonjour,
j'avoue ne pas tout comprendre… Il n'y a pas une solution simple pour régler ce problème ?
De mon cote, je vais déjà essayer de désactiver la détection de boucle ou le filtrage des paquets STP sur le switch.
De mon côté, plus aucun problème depuis que le STP est désactivé. Je continue de surveiller.
Le paramètre se trouve dans les bridges. Sur celui que vous utilisez, il suffit de mettre le protocole sur “none”.
Voir la capture d’écran ici :
https://imgur.com/a/Uv6G7xC
@pablomg Bon, après de nouveaux tests et des constats d’instabilité, je me suis rendu compte qu’il y a toujours quelques pertes de paquets, et parfois une augmentation impressionnante du temps de réponse des répéteurs, passant de 5–20 ms à plus de 200 ms.
C’est le cas sur les deux répéteurs.
@nbanba, penses-tu que tu pourrais m’aider en me guidant ? Merci.
Bonjour enzo fournet,
Est ce que ce serait possible de me donner des horodatages précis de quand ça arrive pour que je vois si ça correspond à certains messages dans les logs?
Merci d'avance
Bonjour
Désolé je suis passé à côté de la dernière réponse.
Oui je peux vous aider
Cordialement
nbanba
Bonjour
Si je peux me permettre un conseil:
Ne jamais désactiver le loop guard ou spanning-tree sur son réseau.
Quand on a des soucis de boucles, on
- isole le segment L2
- réduit au minimum possible le domaine de broadcast (on vise RFC3021)
- on passe en L3
- si nécessaire on route les paquets par le L3
La diffusion d'un vlan natif unique seulement sur 2 ports permet souvent d'isoler un segment point à point puis de router au travers d'un des 2 points du segment
Si certains sont tentés de désactiver les sécurités protégeant le réseau (loop guard, STP, PVRSTP+ …) ce n'est possible que si vous avez une maitrise fine et absolue de chaque interconnexion OSI-L1 composant le réseau et de chaque trame OSI-L2 circulant dessus.
Autrement dit sans accès root à la Freebox et sans avoir écrit les programmes qui envoient et reçoivent les paquets c'est impossible.
Cordialement
nbanba
Salut, bon, je n’ai pas des compétences aussi bonnes que les tiennes en réseau mais, d’après ce que j’ai compris, la seule solution viable avec la Freebox en mode routeur serait de faire du NAT sur le répéteur pour éviter les problèmes.
Le souci, c’est que ça impliquerait que tous les appareils derrière le répéteur aient des IP différentes de celles de mon réseau principal…
Étant donné le nombre d’appareils connectés que j’ai, je pense que ça risquerait de mettre le bazar. Ce n’est donc pas une solution viable pour moi.
Pour les logs, @pablomg, j’ai fait un petit script Python qui ping les deux répéteurs et génère des logs si ça échoue ou si la réponse prend plus d’une seconde. Voilà le résultat :
Globalement, je constate des instabilités sur le répéteur connecté derrière le Mikrotik CRS305.
Bonjour Enzo,
Votre box et votre répéteur ont été redémarré durant la journée donc je n'ai pas accès à vos logs d'hier. J'ai mis en place un monitoring sur vos équipements, est ce que vous pourrez me transmettre la sortie de ce même script demain ?
Bien à vous
Ok, je lance ça. À noter que j’ai maintenant 3 répéteurs, dont deux derrière le CRS305 :
Le diagnostic wifi me dit aussi qu'il y a un souci de distance d'un répéteur avec le Wifi (trop éloigné) donc le 192.168.0.55 je suppose sauf qu'il s'affiche comme correctement connecté au wifi, je ne comprends pas trop.
Bonjour @enzo\040fournet
Déjà désolé, je suis dans une zone @ grise (quasi blanche) ou après quelques dizaines de minutes acharnées j'ai enfin réussi à lire votre poste et à envoyer les quelques octets de ce message … De fait il m'est très difficile d'utiliser internet en ce moment
Je reviens sur 2 points des précédents échanges :
- pour le script python, il serait intéressant d'avoir le réel output de la commande ping que python exécute (les HOP, le TTL …
- 2è point : qu'entendez vous par NAT (Network Address Translation) ?
Il me semble qu'un répéteur freebox n'a pas la capacité à ré-écrire les entêtes des paquets donc à faire du NAT à proprement parler
Par contre il est peut-être possible de router par un répéteur, point à confirmer ou infirmer par les devs ici ou à vérifier experimentalement.
Après je n'ai pas testé et je ne peux pas tester aujourd'hui pour vous dire si ça fonctionne (trop peu d'accès @ pour accéder à mon lab, désolé)
Cordialement
nbanba
Bonsoir
Désolé 3è message…
Sur le mikrotik sur lequel est branché 1 répéteur avec lequel vous avez des soucis, pourriez-vous faire 1 pcap full du traffic OSI-L2 en filtrant le tcpdump sur l ip ou la mac du répéteur (et reproduire l'incident) ?
Merci
Cordialement
Voilà les logs de toute la nuit :
Avec un peu plus de détail :
Par contre, étrangement maintenant, c'est le répéteur en Wifi qui fail le plus souvent. Avec toujours quelque fail sur les autres, mais plus rare.
A priori, je ne pense pas que le problème des répéteurs connectés en Ethernet et en Wi-Fi soient les mêmes. Sur le serveur, je vois bien des problèmes avec la connexion entre le serveur et le répéteur aux horodatages donnés mais ça ne devrait pas bloqué un ping, donc il faut qu'on continue de creuser de notre côté.
Bien à vous
Bonjour
Ne pas oublier le soucis de boucle créé par 1 répéter entre sa carte 2.4ghz et sa carte 5ghz.
Merci
Cordialement
nbanba