Je poste ici après plusieurs échanges avec le support téléphonique, car on commence à avoir suffisamment de données pour dépasser le simple diagnostic « redémarrez la box ».
J’ai une Bbox Wi-Fi 7 XT / Sagemcom F@st5696b sur une offre FTTH 8 Gb/s / 1 Gb/s, qui subit des coupures longues et apparemment aléatoires. Lors d’un précédent épisode, l’écran de la Bbox affichait explicitement :
S2 — Erreur de signal optique
Débrancher/rebrancher la fibre avait alors permis de retrouver la connexion, probablement parce que cela force une nouvelle synchronisation PON, mais évidemment cela ne permet pas d’identifier la cause.
Un technicien est déjà intervenu. Au moment de son passage, tout était revenu à la normale. Il avait relevé environ -16,5 dBm en amont et -17 dBm au niveau de la Bbox, soit seulement ~0,5 dB de perte sur le parcours testé. La jarretière fibre et la Bbox ont déjà été remplacées.
Architecture réseau
La Bbox n’assure pas directement tout mon LAN.
Derrière elle se trouve un réseau domestique relativement conséquent, mais entièrement câblé et monitoré :
Bbox FTTH → routeur principal TP-Link Deco BE68 → switch multi-gigabit 2,5/10 Gb/s → LAN + satellites Deco
Le réseau comprend notamment :
4 bornes Deco BE68 au total ;
un switch principal TRENDnet avec ports 2,5 et 10 Gb/s ;
un NAS Synology ;
un serveur Proxmox ;
une VM Home Assistant ;
plusieurs contrôleurs domotiques Ethernet/Zigbee ;
quelques équipements multimédias ;
un serveur local exécutant différentes automatisations et services.
Il y a donc du trafic réseau normal et parfois des traitements automatisés, mais rien nécessitant une exposition directe de services vers Internet. Je ne détaille volontairement ici ni adresses publiques, ni URL, ni éléments d’authentification.
Le point important est que le LAN situé derrière la Bbox continue de fonctionner normalement pendant les pannes FTTH.
Mise en place d’un diagnostic indépendant
Comme les coupures sont intermittentes, j’ai mis en place sur le serveur Proxmox un outil de monitoring dédié, que j’appellerai ici Netprobe.
Il surveille simultanément plusieurs couches afin d’éviter de confondre un problème LAN avec un problème opérateur :
état de l’interface Ethernet physique du serveur et du bridge Proxmox ;
accessibilité du Deco principal ;
plusieurs équipements Ethernet situés sur différentes branches du LAN ;
plusieurs satellites Deco ;
NAS, Home Assistant et contrôleurs réseau ;
accessibilité locale de la Bbox ;
ping vers plusieurs destinations Internet indépendantes ;
DNS ;
HTTPS ;
API locale de la Bbox ;
état FTTH et WAN remonté par la Bbox ;
activité réseau du serveur juste avant les incidents.
L’objectif est de savoir précisément ce qui tombe en premier et ce qui continue à fonctionner.
Le système conserve également une chronologie avant/après chaque incident afin de rechercher un éventuel déclencheur lié au trafic local.
Incident n°1 — 7 septembre
Premier incident réellement capturé de bout en bout.
Début : environ 19:02 CEST
Retour : environ 21:17 CEST
Durée : ~2 h 15
Au moment de la chute :
les deux sondes Internet deviennent injoignables ;
le LAN reste totalement opérationnel ;
le Deco principal reste accessible ;
les équipements Ethernet restent accessibles ;
les différentes branches du switch restent accessibles ;
la Bbox reste initialement accessible sur son réseau local ;
son API locale répond encore et indique explicitement :
FTTH = DOWN
Internet = DOWN
WAN IP = absente
Link state = down
Puis la connexion revient spontanément.
La Bbox retrouve d’abord son état FTTH/WAN, puis quelques secondes après les sondes Internet redeviennent accessibles.
Aucune intervention locale n’a été nécessaire pour ce retour.
Incident n°2 — 9 septembre
Deuxième incident capturé.
Dernier état sain : ~17:40 CEST
Début de panne : ~17:43 CEST
Retour : ~21:20 CEST
Durée : ~3 h 37
Là encore :
Internet tombe ;
tout le LAN derrière le Deco reste opérationnel ;
Deco principal OK ;
NAS OK ;
Home Assistant OK ;
contrôleurs Ethernet OK ;
satellites Deco OK.
La Bbox devient cette fois plus instable côté accès local pendant la panne : certains contrôles locaux cessent temporairement de répondre.
Je précise volontairement que je ne considère pas cela comme une preuve de reboot : Netprobe observe une indisponibilité locale de la Bbox, mais n’a évidemment pas accès à son boot ID interne.
Au tout début de l’incident, l’état FTTH remonté passe de nouveau à DOWN.
La connexion revient également spontanément après plus de trois heures.
Recherche d’un éventuel déclencheur côté réseau domestique
Lors du premier incident, une activité réseau relativement importante avait eu lieu sur mon serveur peu avant la panne.
J’avais donc conservé comme hypothèse de travail qu’un certain type de trafic pouvait éventuellement provoquer un bug Bbox/ONT.
Le deuxième incident est très intéressant sur ce point :
aucune activité réseau importante n’était présente dans les 15 minutes précédant la panne.
Le trafic était quasiment limité à quelques flux de fond/heartbeats.
La maison était donc pratiquement dans un état réseau « calme », et la panne s’est produite malgré tout.
Cela affaiblit fortement l’hypothèse d’un déclenchement causé par le trafic de mon LAN.
Pour éviter les conclusions basées sur un seul événement, j’ai également mis en place des fenêtres de contrôle sur des périodes sans panne afin de comparer les niveaux de trafic.
À ce jour, nous n’avons trouvé aucun précurseur reproductible côté LAN.
Ce qui est commun aux deux incidents
Les deux captures montrent essentiellement la même chose :
LAN local : sain
Deco / switches : sains
équipements internes : sains
Internet : DOWN
état FTTH Bbox : DOWN
retour spontané après plusieurs heures
La durée varie :
incident 1 : ~2 h 15 ;
incident 2 : ~3 h 37.
Lors d’un incident antérieur non instrumenté, la Bbox avait par ailleurs affiché physiquement S2 — Erreur de signal optique.
À ce stade, cela me semble orienter beaucoup plus vers la chaîne :
Bbox / ONT intégré ↔ PON ↔ OLT ↔ infrastructure optique
que vers mon réseau Ethernet derrière la box.
En revanche, les mesures dont je dispose ne permettent pas de déterminer si le problème vient précisément :
de la Bbox / de son ONT ;
d’une perte de synchronisation PON ;
du port OLT ;
d’un équipement intermédiaire ;
ou d’un défaut optique intermittent impossible à voir lorsque le technicien intervient une fois la liaison revenue.
Ce que je cherche maintenant
Si un Super User, Super Admin ou quelqu’un ayant accès à une expertise FTTH Bouygues passe par ici, ce qui m’intéresserait vraiment serait une corrélation avec les événements opérateur aux horaires précis :
07/09 : ~19:02 → ~21:17 CEST
09/09 : ~17:43 → ~21:20 CEST
Idéalement :
logs de perte/récupération de synchro ONT ;
événements PON/OLT ;
LOS / LOF éventuels ;
état du port OLT pendant ces périodes ;
nombre de désynchronisations ;
éventuels événements touchant d’autres ONT du même arbre PON ;
puissance optique si elle est historisée côté OLT ;
raison de la déconnexion/réinscription ONT si cette information est disponible.
Je peux naturellement fournir des chronologies beaucoup plus précises, des exports Netprobe ou des valeurs horodatées si cela aide quelqu’un à investiguer.
Je cherche surtout à éviter une nouvelle intervention réalisée plusieurs heures après la panne avec pour seule conclusion « RAS au moment du passage », puisque c’est précisément le caractère intermittent du défaut qui pose problème.
Merci d’avance à quelqu’un qui pourrait orienter ce dossier vers une analyse PON/OLT/ONT plutôt qu’un nouveau cycle reset/remplacement de box.
-> ou sinon j'ai vu qu'un utilisateur avait demandé un ont séparé, je ne pensais pas ça possible, comment en faire la demande ? Ça peut, peut-être fix la situation où mon deco devient vrai rooter en supprimant totalement la bbox
