- État Nouveau
- Pourcentage achevé
- Type Anomalie
- Catégorie Répéteur Wifi 5
- Assignée à Personne
- Système d'exploitation Tous
- Sévérité Haute
- Priorité Très Basse
- Basée sur la version 1.9.17
- Due pour la version Non décidée
-
Échéance
Non décidée
-
Votes
3
- Joub_kerbzh (06/02/2024)
- superfloup (16/01/2024)
- wildbleau (15/01/2024)
- Privée
Ouverte par Stéphanefr - 27/11/2023
Dernière modification par Stéphanefr - 27/11/2023
FS#38804 - Répéteur en Ethernet via un switch = plantage
Bonjour,
Comment remonté par d’autres ici, la configuration suivante :
- répéteur POP (v 1.9.17) en Ethernet sur switch Zyxel 1210
- switch relié à la box en Ethernet
Au bout d’un moment, aléatoire, 2 heures ou 2 jours, tout tombe. Redémarrer la Freebox permet de repartir pour un moment. Les liaisons en WiFi directement avec la Freebox ne sont pas affectés. La liaison entre le répéteur et la Freebox tombe à quelques Mbits/s.
Ce problème ne survenait pas il y a 1 ou 2 ans.
Pour moi, le répéteur est initialement relié à la Freebox par l’Ethernet cuivre. Au bout d’un moment est crée une (seconde) liaison WiFi avec la box. Cela génère donc une boucle sur le switch : Freebox → Switch → (cuivre)Répéteur → (Wifi)Freebox (boucle). Mais c’est pure spéculation en l’absence d’un switch gérable façon Cisco.
Workaround : utiliser un répéteur de marque.
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,
Nous avons une nouvelle version de firmware actuellement en beta test qui devrait corriger ce type de problèmes. Est-ce que cela vous intéresse de la tester ? Si oui je vous contacterai par email pour plus de détails.
Merci.
@Stéphanefr: Avez-vous vu le commentaire de @Oliv-r ?
@Oliv-r bonjour quelle est le numéro de version de cette beta ? Je rencontre le même problème (avec un switch CPL) et mon répéteur est en version 1.9.18 (qui n'est pas référencée ici semble-t-il)
Bonjour, excusez mon absence. Je veux bien tester une beta, avec plaisir.
Pour le moment mon workaround est de déplacer le repéteur plus près de la freebox, et de ne pas utiliser l'interface filaire. Du coup plus de pb, mais un débit pas terrible !
Donc, je prends un firmware si c'est toujours possible. merci.
Bonjour,
Si vous cherchez d'autres beta testeurs pour ce nouveau firmware, je suis fort intéressé, ça me débloquerait pas mal chez moi (actuellement mes AP sont en 1.9.18).
Même soucis chez moi, ap en version 1.9.18 le branchement de cet ap provoque une boucle et casse tout le lan
Je re-up le sujet si jamais quelqu'un de Free passe ici …
Je suis également intéressé pour tester cette Beta, j'aimerais pouvoir profiter de mes répéteurs en mode point d'accès. Dès que j'en branche un en Ethernet cela met tout mon réseau en vrac.
J'utilise un switch Zyxel XGS1210-12 branché sur le Server via le port SFP. Je n'avais aucun problème avant de tenter de brancher ce répéteur en Ethernet.
Pour ceux qui ont des box ultra vous pouvez tester la version 4.8.5 Freebox + répéteur 2.3.6
Testé et validé pour ceux qui se posent la question.
Bonjour
Problème qui semble similaire sur 1 répéteur
Ultra en 4.8.6
Répéteurs en 2.3.6
J'ai 3 répéteurs, tous en Ethernet
2 répéteurs OK - Ethernet, 1 adresse IP, et ils restent connectés
1 répéteur capricieux
il se déconnecte de façon aléatoire et reprend la connexion
Tout mon réseau fonctionnait parfaitement auparavant chez Orange
Merci d'avance.
Bonjour,
je peux avoir une mac de GW pour regarder ?
Bonjour
la voici
38:07:16:c0:f3:e5
C'est toujours le même qui se déconnecte on est d'accord ?
celui nommé extension ?
Est ce que vous pourriez tester en débranchant temporairement le "sonos extension" ?
C'est peut être lié…
Exact c'est le répéteur extension
Le sonos extension est relié en wifi. Je vais le débrancher mais je ne comprendrais pas pourquoi ce serait lié à lui.
PI
Répéteur Extension assigné de nouveau à 19h10 malgré Sonos Extension débranché
Je rebranche le Sonos à 12h04 car j'ai besoin de l'utiliser
Tenez moi au courant
Merci
Répéteur Extension assigné vers 7h et vers 11h (donc avant de rebrancher Sonos)
A votre dispo
Pas trop de piste pour le moment… Je pense que c'est lié aux sonos quand même mais il faut que j'arrive à reproduire…
Ça marche
Merci pour votre retour et ces recherches
Tenez moi au courant si besoin d'infos
@Agone On devrait avoir une version qui améliore la compatibilité avec les sonos début semaine prochaine. Est ce que cela vous intéresserai de bêta tester cette version là ?
Bonjour
Si cela ne génère pas de problème pour la mise à jour ultérieure sur des versions stables pas de problème
Avez-vous eu également des retours d'autres personnes sur la stabilité wifi des Nests Hubs. Quand le wifi se coupe ils ne se reconnectent pas toujours. (Obligé de les débrancher)
Bonjour,
Depuis la mise à jour 2.3.11, le spanning-tree ne fonctionne plus de la même façon, je dois maintenant désactiver ce protocole sur l'interface du répéteur avec :
spanning-tree bpdufilter enable
spanning-tree bpduguard disable
au lieu de :
spanning-tree portfast network
Quelles sont les modifications ? Il n'y a pas d'autres solutions ?
Bonjour lcsz,
Si je comprends bien cette doc [0], un port configuré en portfast network s'attend à être connecté à un autre switch cisco qui envoie des BPDU.
On a changé notre façon de détecter les boucles et le répéteur ne fait plus de STP (faire du STP sur une interface WiFi qui peut perdre des paquets n'est pas très fiable).
Comme les répéteurs avant la version 2.3.x faisaient activement du STP, le bridge assurance mettait le port en forwarding à la réception des BPDUs provenant du répéteur pensant que le switch était connecté à un autre switch cisco (donc ça marchait par chance).
Comme le répéteur en version 2.3.x n'envoie plus de BPDU quand le port est configuré en network il pense être connecté à un switch cisco défaillant et le bridge assurance bloque le port en question par sécurité.
Je pense, donc, que vous n'avez pas besoin de désactiver le STP sur votre switch, juste de mettre le port du répéteur dans sa configuration par défaut cad sans portfast d'activé ou alors si vous voulez vraiment du portfast de l'activer dans sa configuration par défaut (i.e.
spanning-tree portfast default, voir [1] pour plus d'explications et pourquoi c'est pas vraiment recommandé).
[0] https://www.cisco.com/c/dam/en/us/td/docs/switches/lan/catalyst9500/software/release/17-1/configuration_guide/lyr2/configuring_optional_spanning_tree_features.html
[1] https://community.cisco.com/t5/blogues-de-routage-et-commutation/fonctionnalit%C3%A9s-avanc%C3%A9es-de-spanning-tree-portfast-bpdu-guard-et/ba-p/3951523
Merci.
Bonjour,
Dans sa configuration de base ou en portfast, le port est BLK.
Tel que je comprends le problème, le répéteur créé un pont au démarrage entre l'interface Wifi et Eth, le switch trouve donc deux chemins (par le port du répéteur et par le port SFP) vers la delta et passe en BLK. En filtrant les BPU je force son activation, mais je n'ai plus de sécurité sur ce port en cas de boucle.
La boucle créée par le répéteur ne dure que quelques secondes ou je vois du MAC Flapping mais elle n'est pas compatible avec l'utilisation du STP.