- État Fermée
- Pourcentage achevé
- Type Anomalie
- Catégorie LAN → Bridge
- Assignée à Personne
- Système d'exploitation Freebox Server V6 (Révolution)
- Sévérité Haute
- Priorité Très Basse
- Basée sur la version 3.5.2
- Due pour la version Non décidée
-
Échéance
Non décidée
-
Votes
38
- sebastieno (27/02/2021)
- moha163 (17/07/2020)
- geolap (26/06/2020)
- umeda (06/06/2020)
- Glandos (19/05/2020)
- JCTelo (15/05/2020)
- chness (08/05/2020)
- cabe69 (20/04/2020)
- MightyBob (15/02/2020)
- sonoma (24/01/2020)
- rpineau (24/12/2019)
- claudius (22/12/2019)
- abouvier (11/12/2019)
- jmuchemb (01/11/2019)
- fenice (25/10/2019)
- sebt (13/10/2019)
- Alkaline (01/10/2019)
- dem (30/09/2019)
- crazyfred (26/09/2019)
- Rootax (22/09/2019)
- thomaslc42 (15/09/2019)
- kador (12/09/2019)
- stephanep (28/08/2019)
- Aerandir53 (19/07/2019)
- influenzae (07/06/2019)
- badprocess (17/01/2019)
- oliv_freebox (03/01/2019)
- fx (02/01/2019)
- maze92 (09/12/2018)
- Eric_S (23/11/2018)
- hm (22/11/2018)
- xenonserge (24/10/2018)
- veg (18/10/2018)
- dough29 (27/09/2018)
- JPFree (26/09/2018)
- docteurmicro50 (12/09/2018)
- RCK (03/09/2018)
- morloch (31/08/2018)
- Privée
Ouverte par morloch - 31/08/2018
Dernière modification par mbizon - 07/08/2020
FS#22818 - Perte de lien Internet via mode bridge après reconnexion lien FO
Bonjour,
Quelque part dans un des micro-logiciel FreeboxOS v3.5.x (avec x probablement = 2 ou 3), un bogue semble s’être introduit qui induit le problème suivant:
lorsque la Freebox serveur v6 perd le lien FO et après rétablissement de ce dernier, seuls les services TV et téléphone sont disponibles, le lien Internet étant perdu et nécessitant le redémarrage de la Freebox pour se voir rétabli.
Historique et description complète du problème disponibles ici: https://www.aduf.org/viewtopic.php?t=282558
Ma configuration est la suivante:
FO (ZMD) → ONU + Freebox Révolution serveur → Ethernet CAT6 → PC sous Linux faisant office de pare-feu/routeur/proxy/serveur → switch 1Gbps → Réseau local en Ethernet CAT6 → machines perso + Freebox player.
Freebox serveur (r2) en mode “bridge”, IPv4 “full stack”, micro-logiciel actuel = v3.5.4.
Passerelle IPv4 Free: 82.64.10.254
07.08.2020 13:24
Raison de la fermeture : Doublon
Commentaires de fermeture :
23539
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,
Je confirme le problème qui est présent depuis maintenant 2 ou 3 mois.
Dès que la freebox (en mode bridge) se reconnecte toute seule à Internet (perte du lien), l'ip de la passerelle devient indisponible pour le routeur local, du coup on perd internet.
Le problème à été confirmé avec 3 freebox ici, toutes avec le dernier firmware.
- Freebox Server Mini (r1) en mode bridge
- IPv4 Full Stack 82.64.53.172
- Micro-Logiciel 3.5.4
ps: c'est très chiant comme bug, vu que la seule solution pour récupérer le net est de redémarrer physiquement la freebox.
Précisions:
- Mes box sont connectées en xDSL, donc le bug ne dépend pas du type de connexion au net (FO, xDSL)
- Le problème est reproductible, il arrive à chaque fois que la box perd le lien internet, de façon manuel (on enlève/remet le cable XDSL) ou automatique (reconnexion auto la nuit).
Idem chez 9 de mes clients, que ce soit en ADSL/VDSL ou FIBRE.
Le pire c'est la box est encore accessible à distance et répond toujours au ping, donc nos outils de supervision de détectent pas cette perte.
La seul solution est de passe en routeur avec DMZ sur notre routeur, mais ce n'est que du palliatif, le double NAT n'est pas une solution, sans compter le temps de reconfiguration des 9 sites de mes clients...
Le support Free, à quand une solution?
Précision : je constate ce phénomène dès qu'il y a une déconnexion puis connexion de l'accès internet.
Problème toujours d'actualité chez moi : FS#22379 Vu aussi ici: FS#22818 Si c'est aussi votre cas, merci de voter pour ce ticket et les deux autres en lien pour que les choses bougent, les clients bridge étant peu nombreux il semble qu'il soient un peu délaissés ;)
Problème aussi confirmé chez moi. Le mode bridge ne fonctionne pas et donc inutilisable. Rien à faire après plusieurs tests et plusieurs configurations. Au bout d'un certain temps aléatoire, comme 1 journée ou 1 heure, on perd le lien Internet. Bref, obligé de repasser la Freebox Server (r1) en mode routeur avec un double NAT!
Bonjour Morloch,
Tu dis avoir utiliser un script pour rebooter ta freebox en cas de perte de lien, est ce que ton script est hébergé sur ton réseau local ou à l'extérieur de ton infra ?
Si il est sur ton réseau local, comment tu fais pour qu'il communique avec la freebox en mode bridge du coup ?
Merci !
@RCK
Le script est invoqué (via crond) toutes les deux minutes pour vérifier la connectivité à Internet et diagnostiquer la perte de liaison au niveau de la box en "bridge". Si le script constate l'absence de connectivité deux fois d'affilé, il redémarre la box via l'API Freebox. Le script est hébergé sur mon pare-feu/routeur/proxy/serveur Linux (voir la topologie de mon réseau dans la description de ce bogue).
Voici le script (freebox-check):
#!/bin/bash # Adresse de la passerelle Internet Free GATEWAY="82.64.10.254" # Interface Ethernet en liaison avec la box serveur WANIF="eth1" # Noms des fichiers "drapeaux" FAILED_FLAG_FILE=/var/run/freebox.failed REBOOT_FLAG_FILE=/var/run/freebox.rebooting log() { logger -t freebox-check "$1" } check_flags() { if [ -f "$REBOOT_FLAG_FILE" ] ; then rm -f "$REBOOT_FLAG_FILE" log "Freebox redémarrée." fi if [ -f "$FAILED_FLAG_FILE" ] ; then rm -f "$FAILED_FLAG_FILE" log "Freebox reconnectée." fi } # Il peut arriver que la table de routage soit altérée lors de la perte # du lien Internet par la box (en fonction des paramètres DHCP reçus, voire # de l'expiration du bail DHCP). On vérifie donc la présence de l'adresse # de la passerelle dans la table de routage et, si elle est absente, on # redémarre l'interface en lien avec la Freebox; son DHCP et les scripts # ifup-* de Linux feront le reste pour rétablir le routage... route -n | grep $GATEWAY &>/dev/null if (( $? != 0 )) ; then log "Redémarrage de l'interface $WANIF pour rétablissement du lien" ifdown $WANIF sleep 1 ifup $WANIF fi # Vérification de la présence de la Freebox ping -c 1 mafreebox.freebox.fr &>/dev/null if (( $? != 0 )) ; then if [ -f "$REBOOT_FLAG_FILE" ] ; then # Attendre la fin du redémarrage de la Freebox exit 0 fi log "Freebox non détectée." exit 0 fi # Vérification de la connectivité Internet; malheureusement la passerelle IPv4 # ne répond pas toujours aux pings, on utilise donc trois pings, l'un vers la # passerelle et les autres vers les DNS de Free. ping -c 1 $GATEWAY &>/dev/null if (( $? == 0 )) ; then check_flags exit 0 else log "Passerelle non répondante au ping." fi ping -c 1 212.27.40.240 &>/dev/null if (( $? == 0 )) ; then check_flags exit 0 else log "DNS1 non répondant au ping." fi ping -c 1 212.27.40.241 &>/dev/null if (( $? == 0 )) ; then check_flags exit 0 else log "DNS2 non répondant au ping." fi # Si les pings ont échoué, alors on a perdu la connectivité Internet et à cause # d'un de ses bogues il faut redémarrer la box pour la retrouver. On ne # redémarre cependant qu'au deuxième échec des pings, et on commence donc par # positionner le drapeau $FAILED_FLAG_FILE, ne redémarrant la box que s'il est # déjà présent. if [ -f "$FAILED_FLAG_FILE" ] ; then rm -f "$FAILED_FLAG_FILE" touch "$REBOOT_FLAG_FILE" log "Redémarrage de la Freebox..." /usr/local/sbin/freebox-reboot exit 0 fi log "Freebox déconnectée !" touch "$FAILED_FLAG_FILE"Le script /usr/local/sbin/freebox-reboot est en fait freeboxos_bash_api.sh (dûment inscrit comme application dans la Freebox) auquel on été ajoutées les lignes suivantes:
La Freebox, même en "bridge" (c'est un faux bridge en réalité) est tout à fait joignable depuis votre réseau local à l'adresse 212.27.38.253 (qui est donc routée sur l'interface WAN du routeur et interceptée par la Freebox plutôt que de partir vers Internet). Si vous voulez pouvoir la joindre avec l'adresse littérale "mafreebox.freebox.fr" même lorsque le lien Internet (et donc DNS) est HS, il vous suffit d'ajouter la ligne "mafreebox.freebox.fr 212.27.38.253" à /etc/hosts.
@Morloch: Merci beaucoup pour tous ces détails ! Cela va nous permettre de palier la non réaction de Free sur le sujet :)
Même problème pour moi: openwrt derrière la freebox en mode bridge. La freebox reste accessible de l'extérieur mais plus d'internet en sortie.
cette semaine elle est même repassée en mode routeur après un reboot...
Merci pour le script ça peut être utile.
Je rencontre également ce problème en bridge.
J'ai aussi un script (NodeJS) pour redémarrer la box qui utilise l'endpoint connection/logs de la v5 de l'API pour détecter le problème. Si ça intéresse quelqu'un:
https://hastebin.com/jimexuxovu.js
Il faut passer le token de l'API dans la variable d'environnement FBX_APP_TOKEN et le chemin du certificat SSL dans la variable FBX_ROOT_CERT si vous voulez utiliser l'API en HTTPS (c'est brièvement expliqué au début du script).
Bonjour morloch,
J'ai une configuration similaire à la tienne : FO - Serveur Mini 4K en bridge - Serveur/Passerelle - LAN
Mon serveur tourne sous SME Server qui est une distribution dérivée de CentOS... qui est elle-même une recompilation d'une célèbre distribution commerciale
J'ai fait des essais dans une VM et je suis enfin passé sur le serveur lui-même. J'ai surtout eu des difficultés avec freeboxos_bash_api.sh. D'après mes essais, il ne fonctionne bien que si on l'exécute une première fois avec une connexion interne active. Donc, je lance une première fois le script (sans commande de redémarrage) au démarrage du serveur avec un délai de 2 mn, pour être sûr que la box est démarrée (elle met plus de 1 mn à démarrer). Ensuite, dans les détails, dans ton script, j'ai dû hardcoder les chemins de route, ifdown et ifup (/sbin/source, ...). J'ai mis un cron à 5 mn pour lancer ton script.
Il reste deux petits problèmes.
Le premier, c'est que le test de connexion à internet semble de temps à autre bloquer la connexion TV pendant quelques secondes. Comme on regarde très peu les chaînes TV, je ne m'en suis pas rendu compte durant les tests. Par contre, vendredi soir, lors de la mise en production, je l'ai noté plusieurs fois et au moins une fois, ça correspondait à l'heure du cron. Ça ne coupe toutes les 5 mn mais quand même, ça gêne un peu.
Le second problème est qu'à chaque appel du cron, j'ai un email envoyé au compte admin et une ligne dans le fichier log général:
C'est surtout le bourrage de la boîte email qui est pénible. Je vais me renseigner pour voir su je peux éviter ça.
Bonjour,
Même problème chez moi.
Un seul point a préciser c'est que ce problème ne se produit que lors d'une synchro en VDSL2.
Si je force la synchro en adsl2+ le souci disparaît, le mode bridge fonctionne parfaitement.
@Eric Sibert
Euh... Vous avez, bien sûr adapté, dans le script, l'adresse IP de la passerelle à la vôtre, n'est-ce pas ?... (faites 'route -n' pour la trouver).
Sinon, il n'y a aucune raison pour qu'une quelconque perturbation ne se propage aux services TV. Mais évidemment, si l'adresse IP de la passerelle n'est pas correctement configurée, le script fera systématiquement un ifup/ifdown sur l'interface Ethernet, provoquant ainsi les interruptions de flux que vous avez observé...
@Eric Sibert
Pour les emails envoyés par crond, modifiez simplement /etc/crontab pour lire: MAILTO=""
Oui, je n'avais pas lu ton script en détail. En reprenant ça à tête reposée, je me suis rendu compte que je n'avais pas le même GATEWAY que toi... Une fois l'adresse IP de la passerelle corrigée, je n'ai plus de message ni dans boîte admin, ni dans le fichier log. Je n'ai pas encore testé mais j'imagine que je n'ai plus non plus les coupures TV, n'ayant plus de réinitialisation de la connexion réseau. Merci pour tes réponses.
Oui je confirme, le problème de perte du net lors d'une reconnection en mode bridge de la freebox ne se produit qu'avec une connexion en VDSL et non ADSL.
Free, Avez-vous pris connaissance du problème ?
A noter que ce bogue affecte toujours le dernier micrologiciel (v4.0.1) de la Freebox Révolution serveur. Cela commence à devenir *très* pénible ! >
Un officiel de Free pourrait-il donner des nouvelle sur la correction de ce bogue au moins faire l'aperçu et nous confirmer que tout cela a bien été pris en compte ?
Merci pour cette information.
Malgré une version potentiellement majeure (3 → 4) on ne constate pas grand chose sur cette nouvelle "mouture"...
Depuis que j'ai mis en place le script de Morloch, je n'ai plus eu de déconnexion pour vérifier que ça fonctionnait bien. Alors que ça déconnectait à tout bout de champ (2-3 jours) avant.
Toujours en v3.5.4 sur fibre. On va laisser couler de l'eau sous les ponts avant de passer à la v4.
@Eric Sibert
Toutes les versions 3.5 et 4.0 (la dernière v4.0.2 incluse: j'ai eu une telle déconnexion ce dernier dimanche) sont affectées par ce bogue.
Si seulement Free pouvait se manifester et nous donner un délai de résolution du bogue... Ou faut-il passer à la concurrence pour obtenir une liaison FO fiable ?
Aujourd'hui, première utilisation réelle de ton script. Après perte de la connexion, je suis allé voir ce qui se passait au niveau de la box. J'ai alors vu qu'il y avait une mise à jour du firmware en cours. Je suis effectivement passé à la 4.0.2 à l'insu de mon plein gré. De toute façon, comme le bug n'est pas résolvaté avec la nouvelle version... ben ton script va continuer à être utile
.
la 4.0.4 est dispo depuis hier, vous pensez qu'il y a une chance pour qu'elle corrige notre soucis ?
https://dev.freebox.fr/blog/?p=5339
Si c'est le cas ce serait bien qu'ils reportent le correctif sur le server de la mini 4k parce que là j'ai redémarré et toujours en 4.0.2
Une précision, le problème se produit en vdsl, en fibre, mais aussi en adsl dégroupé . Le seul mode bridge qui reste opérationnel a la reconnexion est avec le profil adsl (simple).
Récapitulatif, c'est donc lié à :
- https://dev.freebox.fr/bugs/task/22928
- https://dev.freebox.fr/bugs/task/22818
- https://dev.freebox.fr/bugs/task/22379
- https://dev.freebox.fr/bugs/task/22370
Pendant ce temps on bosse gratuitement pour Free qui ne daigne même pas nous considérer...
Neustradamus: Je n'avais pas vu tous les tickets lié au problème ! Cela veux dire que cela fait bientôt 1 an que le problème existe ! c'est moche :(
Récapitulatif, c'est donc lié à :
- https://dev.freebox.fr/bugs/task/10011
- https://dev.freebox.fr/bugs/task/12446
- https://dev.freebox.fr/bugs/task/15672
- https://dev.freebox.fr/bugs/task/15800
- https://dev.freebox.fr/bugs/task/15952
- https://dev.freebox.fr/bugs/task/18505
- https://dev.freebox.fr/bugs/task/19260
- https://dev.freebox.fr/bugs/task/19261
- https://dev.freebox.fr/bugs/task/19655
- https://dev.freebox.fr/bugs/task/19659
- https://dev.freebox.fr/bugs/task/19728
- https://dev.freebox.fr/bugs/task/20226
- https://dev.freebox.fr/bugs/task/20460
- https://dev.freebox.fr/bugs/task/20908
- https://dev.freebox.fr/bugs/task/21048
- https://dev.freebox.fr/bugs/task/21159
- https://dev.freebox.fr/bugs/task/21190
- https://dev.freebox.fr/bugs/task/21303
- https://dev.freebox.fr/bugs/task/21657
- https://dev.freebox.fr/bugs/task/21843
- https://dev.freebox.fr/bugs/task/22284
- https://dev.freebox.fr/bugs/task/22301
- https://dev.freebox.fr/bugs/task/22321
- https://dev.freebox.fr/bugs/task/22337
- https://dev.freebox.fr/bugs/task/22346
- https://dev.freebox.fr/bugs/task/22370
- https://dev.freebox.fr/bugs/task/22379
- https://dev.freebox.fr/bugs/task/22402
- https://dev.freebox.fr/bugs/task/22458
- https://dev.freebox.fr/bugs/task/22464
- https://dev.freebox.fr/bugs/task/22497
- https://dev.freebox.fr/bugs/task/22541
- https://dev.freebox.fr/bugs/task/22580
- https://dev.freebox.fr/bugs/task/22593
- https://dev.freebox.fr/bugs/task/22802
- https://dev.freebox.fr/bugs/task/22818
- https://dev.freebox.fr/bugs/task/22837
- https://dev.freebox.fr/bugs/task/22895
- https://dev.freebox.fr/bugs/task/22928
- https://dev.freebox.fr/bugs/task/23539
Neustradamus à écrit:
> Récapitulatif, c'est donc lié à :
Euh, non, pas du tout !
Attention à ne pas tout mélanger. Il y a différents bogues dans tous ceux que vous listez. Les seuls qui soient en lien avec ce bogue ci sont:
22370, 22379, 22837, 22928 et 23539.
Le reste n'a strictement rien à voir, même s'ils ont pu apparaître dans une version 3.5.x du micrologiciel, i.e. en même temps que celui-ci.
Bon j'ai redémarré la FB server (mini 4k, FFTH) ce matin, passage en 4.0.4, le soucis semble corrigé : Le mode bridge sautait lorsque je redémarrai la FB (électriquement ou via l'interface), et là j'ai procédé aux 2 tests avec succès. Reste à voir si ça tient dans le temps.
Attention, le bug n'intervient qu'à la reconnexion automatique de la box en cas de perte du signal internet.
Je vais passer ma mini 4k en 4.0.4, remettre le vdsl, et surveiller résistance du net à la reconnexion automatique VDSL.
Personnellement ça me le faisait systématiquement même lorsque je redémarrai la box donc effectivement, wait and see :)
OK je viens de passer en 4.0.5, je vais tester le mode bridge et vous dire si on perd toujours la connexion internet à la reconnexion du stack vDSL sur Freebox mini.
Bon le problème persiste :(
- Freebox mini v4.0.5
- Mode BRIDGE
- Connection VDSL
- BUG: A la reconnexion de la ligne VDSL (00h52 ci dessous), internet n'est plus disponible pour le routeur sous la box. La box reste joignable depuis l'internet sur son interface d'administration, et seul un reboot de la freebox remet à plat les réglages.
Du coup je confirme que le problème persiste mais dans mon cas désormais uniquement lorsque je perd la connexion au niveau de la box (par exemple si elle redémarre seule, resynchro). Obligé dans ce cas là de redémarrer manuellement également.
Je confirme le problème est persistant chez moi, et régulier.
J'étais ADSL, ça le faisait.
Je suis FTTH, ça le fait encore.
Flux TV ok mais pas d'internet... et ça arrive toujours quand je ne suis pas chez moi (et que j'ai besoin de ma maison connectée..)
Bonjour à tous, je rencontre également ce problème, mais seulement depuis quelques jours.
Ma configuration :
- Freebox Révolution 4.0.6
- Mode bridge
- Connexion VSDL2
Lorsque la freebox perd le lien VDSL et se reconnecte elle reste joignable de l’extérieur mais aucune connectivité depuis le réseau local. L'adresse IP de routeur fournie lors de la réponse DHCP (x.x.x.254) est injoignable.
Je vais essayer le script en espérant une correction rapide de Free.
Bonjour,
Idem avec 4.0.6 / Freebox 4K toute fraiche sortie du carton en VSDL (qui vient de remplacer une Revolution déjà avec ce problème "du TV ok/bridge dead si pas reload du serveur").
Je dirais même que maintenant c'est pire avec cette nouvelle mini 4K, le bridge fonctionne à peine (et la gw en 254 devient injoignable après quelques ping...).
Du coup j'ai fait quelques tests...j'ai remarqué pendant l'incident que si je fait un "dhclient" vers la Freebox je peux alors pinguer à nouveau la .254 sans avoir à couper l'alim (notez qu'elle a toujours été configurée en statique)
Alors petit script ksh...pour sauver les meubles et d'investiguer un peu (car dans mon cas pendant "l'incident" la freebox est completement injoignable sur son IP 212.27.38.253):
while true
> do
> doas dhclient em2
> sleep 2
> done
Constat:
1) je récupère et conserve la connectivité
2) plus de TV, le player est completement à l'ouest..
3) je n'avais jamais fait attention mais les ping depuis Internet vers l'IP publique ne traversent pas la freebox en mode "bridge", c'est la freebox qui répond.
4) si je débranche le player, magie le bridge "ne tombe plus" (et plus besoin du while de l'enfer)
5) si je branche à nouveau le player, aïeaïe le bridge "tombe" (lire la .254 ne repond plus)
Regardons côté tcpdump (00:0d:b9:41:64:c6 mac de mon routeur / 34:27:92:22:26:3c mac du player 4k) et tada...
03:45:49.643954 00:0d:b9:41:64:c6 70:fc:8f:39:a7:40 0800 98: 82.yyy.xxx.206 > 82.yyy.xxx.254: icmp: echo request (id:9424 seq:2036) [icmp cksum ok] (ttl 255, id 61816, len 84)
03:45:49.666342 70:fc:8f:39:a7:40 00:0d:b9:41:64:c6 0800 98: 82.yyy.xxx.254 > 82.yyy.xxx.206: icmp: echo reply (id:9424 seq:2036) [icmp cksum ok] (ttl 64, id 61854, len 84)
03:45:49.845842 34:27:92:22:26:3c ff:ff:ff:ff:ff:ff 0800 362: 0.0.0.0.68 > 255.255.255.255.67: xid:0x4683b82d [|bootp] (DF) [tos 0x10] (ttl 64, id 0, len 348)
03:45:49.862071 34:27:92:22:26:3c ff:ff:ff:ff:ff:ff 0800 374: 0.0.0.0.68 > 255.255.255.255.67: xid:0x4683b82d [|bootp] (DF) [tos 0x10] (ttl 64, id 0, len 360)
03:45:49.869567 34:27:92:22:26:3c 01:00:5e:00:00:16 0800 60: 82.yyy.xxx.206 > 224.0.0.22: igmp-2 [v2] (DF) [tos 0xc0] [ttl 1] (id 0, len 40, optlen=4 IPOPT-148{4})
la freebox lui a donné l'IP 82.yyy.xxx.206 en DHCP (la meme que j'ai configuré sur mon routeur, l'IP publique de ma freebox) → conflit d'IP
En résumé je dirais que TV + mode bridge c'est mort, la freebox n'identifie pas spécifiquement le player et donne l'IP publique au dernier qui en fait la demande en DHCP. J'avais toujours été agréablement surpris que le mode TV et surtout multi TV fonctionne avec le mode bridge par le passé...j'avais peut être raison de l'être :)
C'est peut être aussi pour cela que je ne peux pas séléctionner l'option multi TV pour cette mini4K ...
Ca commence a être chiant heureusement j'ai un second boitier de secours chez Orange qui finalement marche finalement plutôt bien et sur lequel je peux router par défaut...
addons:
- pour le 3) OK c'est l'option freebox "Réponse au ping" qui était activée.
- Concernant le DHCP, on dirait que cela ressemble au comportement de l'option player "dhcp en mode bridge" qui ne semble pas paramétrable sur le player 4k et en tous cas le player n'a pas l'air de travailler sur un vlan dédié TV. Coté serveur, le paramétrage DHCP n'est pas accessible, message "Cette fonctionnalité n'est pas disponible lorsque votre Freebox est configurée en mode Bridge !".
Merci pour ces informations.
Sur mon infra les 2 players sont derrière mon routeur (pfSense) : c'est donc impossible qu'ils cherchent à récupérer mon @IP publique et donc créer un conflit ^^
@Arnaud
Quelle est l'adresse IP de votre interface réseau en lien avec la box serveur, après votre 'dhclient' ?
A mon avis, vous vous reconnectez à la box qui est sortie du mode 'bridge', et donc vous vous retrouvez avec un double NAT et une adresse locale sur votre interface au lieu de votre adresse publique.
Cela expliquerait aussi pourquoi votre box TV ne retrouve plus ses petits.
Vous auriez alors aussi une perte d'accès depuis l'extérieur à tout service configuré sur votre pare-feu/routeur ou "forwardé" par ce dernier à une autre machine de votre LAN (serveur web par exemple).
@Damien. Ok de même, merci pour ces infos, de mon côté j'ai donc une option supplémentaire avant de passer en mode routeur et finalement mon poste n'apporte pas grand chose à ce tichet il doit s'agir d'un autre problème.
La configuration que j'utilise a plus de 10 ans et fonctionnait en V4, HD (avec muti TV) et révolution (jusqu'à il y a "peu" de temps et domage que j'ai rendu la boite hier j'aurais bien vérifié aussi le comportement actuel) et je trouvais plutôt mortel de faire fonctionner les boitiers TV sans polluer mon réseau local en particulier quand cela peut changer comme cela...On va dire que faire une modif d'infra tous les 10 ans et + cela reste supportable :)
@Morloch. Le DHCP de la freebox renvoit toujours l'adresse IP publique en 82.yyy.xxx.206 à mon routeur si il en fait la demande et idem au player 4K, c'est toujours le dernier qui remporte la mise et pas de double NAT ici. Si je force le server a "discuter DHCP" avec mon routeur je conserve la connectivité Internet vers mes DNS, Mail, WEB, etc et inversement...
Si j'arrete de "discuter DHCP" et que le player 4K est démarré, le freebox server va alors distribuer l'adresse publique au player 4K et ne répondra plus en IP à mon routeur et donc perte de connectivité Internet.
En fait je suis même surpris que le DHCP de la freebox réponde alors qu'il est configuré en mode bridge. De même si j'avais encore le player revolution j'aurais pu analyser le comportement avec 2 player et ce mode bridge.
Sans bien connaitre l'archi TV de free, je dirais qu'avant le player devait se tagguer sur un vlan ID particulier ou devais envoyer un ID DHCP spécifique ou alors le service DHCP ne regarde plus ce DHCP ID. Je vais regarder aussi si il ne faudrait pas un faire un petit reset, repasser temporairement en mode routeur (le server 4K a hérité directement de la configuration du serveur révolution et n'a jamais démarré en mode routeur).
En tout cas merci à vous.
@Arnaud
Votre description du bogue ne correspond *absolument pas* à ce que j'observe chez moi...
Mais je crois avoir compris pourquoi. Vous écrivez en effet:
"Le DHCP de la freebox renvoie toujours l'adresse IP publique en 82.yyy.xxx.206 à mon routeur si il en fait la demande et idem au player 4K"
J'en déduis que la topologie de votre réseau ne correspond pas à celle qui s'applique au bogue que j'observe dans ma configuration (cf le schéma dans la description initiale du bogue).
En effet, il est impossible que la requête DHCP de la box TV traverse votre routeur. C'est donc que vous avez votre box TV connectée à la box serveur, et non pas sur votre réseau local (i.e. "de l'autre côté" de votre routeur).
Puisque la topologie de votre réseau ne correspond pas, non plus que les symptômes observés, je suggère que vous ouvriez un rapport de bogue différent de celui-ci. Inutile en effet de rendre les choses confuses: les développeurs de Free sont déjà assez peu motivés pour corriger "mon" bogue (ce rapport est ouvert depuis déjà plus d'un an), alors si en plus on commence à tout mélanger, au manque de motivation s'ajoutera le manque de compréhension du problème...
Bonjour,
Pour revenir au script, pensez vous que l'on puisse l’exécuter depuis l'extérieur ?
merci
@Lionel
Non, en tout cas pas tel quel, car le script a besoin de vérifier la connectivité depuis le réseau local vers Internet.
Bonjour,
Pour revenir au script, pensez vous que l'on puisse l’exécuter depuis l'extérieur ?
merci
Oups desolé pour le repost
Merci pour la réponse.
En fait je veut juste la rebooter à distance. Avec PRTG je monitore un port derrière le firewall (USG Pro), si ce port est down je dois rebooter la Freebox... Et j'aimerai le faire depuis l'extérieur afin d'éviter d'avoir à installer qq chose sur le lan du client...
Merci pour les idées
Bonjour,
Je confirme aussi ce bug sur ma mini 4k en FTTH.
J'ai mis en place un scénario qui reboot électriquement ma freebox via jeedom en cas de coupure de courant :)
Voilà pour redémarrer à distance en Powershell via l'API : https://www.canaletto.fr/post/surveiller-et-redemarrer-une-freebox-a-distance
Le problème est aussi présent sur la Delta.
J'ai le problème sur différentes box de chez Free sur Freebox OS (pas de problème avec des configurations identiques sur V5):
Avec une 4K fibre en bridge + Pfense
Ainsi que sur 2 delta fibre en bridge + Pfsense
Plus depuis quelques mois, mais aussi sur 4K VDSL bridge + Cisco RVS4000 pendant de nombreux mois (plus de problème depuis février d'après les logs).
Pour résoudre le problème pour l'instant utilisation d'un IQTS-IP200 pour le reboot de la freebox.
Log des reboot sur le IQTS-IP200 sur la 4K bridge fibre avec Pfense:
Log sur la 4k bridge vdsl + Cisco RVS4000:
Pour informations complémentaire avec les Delta je n'ai pas eu le problème suivant les 10 jours de l'installation mi-Aout. Mais depuis Lundi 26 Aout cela intervient presque une fois par jour !!!!
Le problème est très handicapant !
Free pourriez-vous faire la correction du problème ?
Cordialement
Bonjour,
Je sais que le mode bridge ne représente pas une grosse part du parc Free, mais ce bug est malgré tout très génant... Assez étonnant qu'il soit présent depuis si longtemps : /
Cordialement.
J'ai demandé à plusieurs reprises la mise à jour de bridge-utils 1.5 en 1.6 (2016-10-17)
→ https://mirrors.edge.kernel.org/pub/linux/utils/net/bridge-utils/
ça serait bien de l'avoir...
https://dev.freebox.fr/bugs/task/25749
Pour l'ensemble des devs, attention : Le problème est présent sur les différents modèles de Freebox Server ;)
Bonjour,
Ci-dessous des MAC de 3 de nos freebox ayant le problème une serveur 4K et deux serveurs Delta avec le problème en question:
Freebox Delta 1: 34279267BF10
Freebox Delta 2: 3427926510CA
Freebox Mini 4k: FACAE55E2116
En espérant un retour que cela vous sera utile pour résoudre le problème.
Cordialement
Bonjour
même soucis sur une Revolution et une Delta S qui l'a remplacé en fibre PON + bridge. Lorsqu'une perte de signal se produit (facilement reproductible à déconnectant et reconnectant le lien), la Freebox devient injoignable et le seul recours est un redemarrage electrique.
Le soucis était présent sur la révolution et il est identique sur la Delta S qui l'a remplacée récemment.
Je précise que je suis en 4.0.7 et non 3.x comme le posteur original, le soucis est ancien.
Tout pareil que tout le monde .... et puis ca fait un UP du bug
ancienne révolution passée en delta S depuis peu (PON + Bridge) et toujours ce comportement horrible ....
4.0.7 et encore rebootée cette nuit
Il faut que tout le monde vote (je sais pas si ça sert), et surtout que quelqu'un chez Free se préoccupe vraiment du problème.
"Il y a les nouveautés futures, il y a le debug des derniers matériels sortis, et ensuite il y a le debug des plus anciens."
Source : https://dev.freebox.fr/bugs/task/27960#comment115447
Pour ma part je passe dans un 1er temps en IPTV (Android TV) pour dégager les box TV et ensuite je verrai bien ce que je fais pour la connectivité Internet.
Sauf que ce problème est visiblement apparu sur les V6, existe encore sur les V7 depuis pas ma de versions du soft. Donc on a tous les critères d'un soucis logiciel qui touche les derniers matériels sortis ET les anciens, si on se réfère à la liste des bugs cités en référence, et sans doute logiciel.
Je n'ai jamais eu de problème avec l'Alice Box en ADSL2. Puis les problèmes ont commencé avec la Mini 4K en VDSL2 et ça continue en fibre. C'est un problème très ennuyant, Free, faites quelque chose !
Pour le moment pas eu de soucis encore ! depuis que j'ai débranché le câble du player
sinon j'ai mis en place une solution de secours comme j'ai déjà la solution domotique jeedom qui tourne sur une machine virtuelle + un raspberry pi
avec plugin ping + plugin freebox + un scénario :
si 2 ping KO a 1 min d'interval → ca lance le reboot de la freebox (le scénario tourne toutes les 5min)
l'avantage vs le script c'est que c'est du GUI et ca permet d'avoir des logs/stats de l'état du bazard
Je confirme les mêmes symptomes, perte du lien FTTH, aucun trafic possible.
J'ai ce problème depuis le jour de l'installation de la Freebox 4K en ZMD.
Module GPON → Freebox 4K en mode bridge → Routeur Gigabit Asus → Switch Gigabit
Si perte de lien optique, rétablissement de la box, mais plus aucun trafic n'est possible (DNS KO, Passerelle KO...)
Un reboot permet de rétablir la situation.
Le problème est de plus en plus présent, plusieurs fois par jour.
Je peux également confirmer que j'ai ce problème et qu'il se produit depuis plusieurs mois.
Mon service vient de redémarrer après une panne de seize heures. :( A cette occasion, j'avais encore la télévision et l'accès au téléphone, mais évidemment pas d'Internet.
Dans tous les cas où cela s'est produit lorsque le service a été restauré, je n'ai toujours pas accès à Internet et je ne peux pas me connecter à mon serveur à partir d'un serveur externe à ma freebox jusqu'à ce que la freebox soit redémarrée.
La seule chose qui m'a sauvé est le script fourni par @morloch (merci pour cela) - avec quelques modifications, il fonctionne bien sur mon pare-feu OPNsense et, bien sûr, la Freebox est en mode Bridge et j'ai une Freebox Mini 4K.
Il est inacceptable que ce bogue n'ait pas été reconnu par Free et continue d'être un problème pour de nombreux utilisateurs.
J'aimerais savoir quand ce grave problème va être résolu ?
Je peux également confirmer que j'ai ce problème et qu'il se produit depuis plusieurs mois.
Mon service vient de redémarrer après une panne de seize heures. :( A cette occasion, j'avais encore la télévision et l'accès au téléphone, mais évidemment pas d'Internet.
Dans tous les cas où cela s'est produit lorsque le service a été restauré, je n'ai toujours pas accès à Internet et je ne peux pas me connecter à mon serveur à partir d'un serveur externe à ma freebox jusqu'à ce que la freebox soit redémarrée.
La seule chose qui m'a sauvé est le script fourni par @morloch (merci pour cela) - avec quelques modifications, il fonctionne bien sur mon pare-feu OPNsense et, bien sûr, la Freebox est en mode Bridge et j'ai une Freebox Mini 4K.
Il est inacceptable que ce bogue n'ait pas été reconnu par Free et continue d'être un problème pour de nombreux utilisateurs.
J'aimerais savoir quand ce grave problème va être résolu ?
Je viens de remplacer mes Player par des Android TV, passé le Server en mode bridge = c'est désormais stable...
J'ai souvent des pertes de connexion (fibre, bridge) quand la FireTV d'Amazon est en marche.
Encore plusieurs déconnexions chaque jour en ce moment, c'est pénible. Ce matin c'était quand j'étais sur l'appli Amazon Prime Video sur mon smartphone, encore un lien avec Amazon, c'est curieux.
On est sur un buggtracker face à un dysfonctionnement bien précis : perte de la connexion coté LAN en mode BRIDGE après une déconnexion xDLS/FTTH.
Le fait que ça se produise sur un service Amazon n'est à mon avis que pure coïncidence.
Par contre ce serait bien que chacun essaie de faire remonter ce fil chez Free (Tweet, FB, etc...), en espérant que le mode bridge ne devienne pas une option du passé !
Bonjour,
j'ai le même problème sur ma Freebox Delta S en mode bridge : plusieurs déconnexions successives de la box, et à chaque fois, le routeur Orbi derrière perd le lien internet.
Tout est down, plus rien ne fonctionne dans la maison, c'est insupportable.
Pour remettre en route l'ensemble, il faut rebooter la box + resync le routeur Orbi. Seule solution qui fonctionne.
Et 2h après, c'est à nouveau down.
Il me semble que compte tenu du type de clientèle visée par l'offre Delta S (une clientèle intéressée par une offre technique, puisque l'offre S - vendue chère - ne propose aucun autre service média de type TV/Netflix et autre...), ça serait la moindre des choses que le mode bridge privilégié par cette clientèle fonctionne correctement et de manière STABLE.
Même chez Bouygues ça fonctionne mieux. Ca fait 10 jours que j'ai la Delta S - pour le moment je le regrette amèrement.
DONC PLEASE FREE : corrigez-nous ce bug. C'est urgent.
Un point à noter : quand cela se produit, l'IPv6 continue de fonctionner normalement, seul l'IPv4 est impacté.
Bonjour
Pour info je suis tombé "par hasard" sur ce poste.
J'ai de mon coté j'avais la conf suivante :
Fibre – Freebox en Bridge – switch – PFsense – switch – Reste du reseau local
et j'avais également de temps en temps (plus de l'ordre de la semaine au mois) des perte du WAN...
Du coup je suis passé avec la conf suivante (depuis plus d'un an) :
Fibre – switch – PFsense – switch – Reste du reseau local
et j'ai toujours de temps en temps des pertes WAN...
Du coup il y a peut etre un pb ailleurs que dans la freebox ? c'est peut etre coté Free ? qui fait quelque chose de non standard, et la Freebox ou le Pfsense ne se reconnecte pas tout seul...
Pour ma part je pense clairement que c'est le tunnel ipv4 dans l'ipv6 qui doit merder à un moment
vu que l'ipv6 marche toujours
allez bientot l'ipv6 devient la base !
@Ewok2 ton pfsense est en 10G ? j'ai du mal à avoir plus que 2-3Gbits/s avec pfsense et une X520-DA2 (freebsd sans la couche pf et cie) j'ai 7gbits
par contre avec untangle/ipfire/vyos (bref tout ce qui tourne à base de debian) j'ai 8gbits \o
@Ewok2 ton pfsense est en 10G ? j'ai du mal à avoir plus que 2-3Gbits/s avec pfsense et une X520-DA2 (freebsd sans la couche pf et cie) j'ai 7gbits
par contre avec untangle/ipfire/vyos (bref tout ce qui tourne à base de debian) j'ai 8gbits \o
Bonjour
Pour info je suis tombé "par hasard" sur ce poste.
J'ai de mon coté j'avais la conf suivante :
Fibre – Freebox en Bridge – switch – PFsense – switch – Reste du reseau local
et j'avais également de temps en temps (plus de l'ordre de la semaine au mois) des perte du WAN...
Du coup je suis passé avec la conf suivante (depuis plus d'un an) :
Fibre – switch – PFsense – switch – Reste du reseau local
et j'ai toujours de temps en temps des pertes WAN...
Du coup il y a peut etre un pb ailleurs que dans la freebox ? c'est peut etre coté Free ? qui fait quelque chose de non standard, et la Freebox ou le Pfsense ne se reconnecte pas tout seul...
@poulpito mon Pfsense tourne sur une carte serveur qu n'a que 2 port Ethernet Gigabit donc je ne peux pas te dire si je monte au dessus
J'ai retiré la freebox en Bridge par ce qu'elle ne servait a rien et qu'elle consommait des Watts pour rien et prenait de la place!
De mon côté, problème avec une Mini 4K en Bridge (r2). Au bout de quelques heures, routeur derrière la Freebox injoignable. En redémarrant la freebox retour au mode Routeur. Avant cela le routeur perso récupère toujours l'IP publique...
Aucun problème sur une autre Mini 4K (r2) connecté en FTTH (ZMD).
Buggué ce mode bridge.
Même problème ici.
Delta en mode bridge, zone zmd, un routeur derrière.
Après une perte du lien fibre (même pas une seconde), la partie ipv6 est toujours opérationnelle, mais pas la v4. Pourtant, un dhcp renew sur le routeur retrouve bien une adresse, mais rien ne sort ni rentre en v4. A noter que j'ai une ipv4 full stack.
Le soucis "source" est la perte du lien fibre au final, mais le fait que la partie v4 ne remonte pas sans un reboot, si ça pouvait être corrigé, ça serait déja ça.
Merci.
Au passage, le ping fonctionne toujours depuis l'extérieur, même quand le bug est rencontré.
Même problème constaté sur deux de nos quatre succursales (NRAs C7V38, LIS69, ESS42, SSA38), toutes en xDSL mode bridge avec routeur derrière, et sans player.
Comme vous autres les pertes de connexion xDSL (dans notre cas) donnent lieu à une coupure d'internet, vu du LAN, bien que la Box puisse toujours être pinguée depuis l'extérieur.
Nous venons encore d'en faire les frais sur LIS69 après que Free a activé la partage d'IP, changeant ainsi l'IP publique, sans bien entendu nous en informer !
Comme nous désirons une IP dédiée nous avons fait la demande d'«IP fullstack» ce que nous a valu de recevoir encore une autre adresse IP. Peut-être est-aussi un élément du problème.
Si le partage d'IP est corrélé à la bascule du DSLAM en IPv6, ça confirme ce que dit Samuel (poulpito) quand à l'origine probable du problème.
Seuls les sites VDSL (C7V38, LIS69) sont concernés pour l'heure, ainsi ESS42 (ADSL) y échappe t'il !
On prie pour que SSA38 (ADSL avec IP non partagée) y échappe...
PS : Le firmware de la box de LIS69 est le 4.0.6
Je suis en fullstack et je suis également touché (cela dit ça fait pas mal de temps que je n'ai pas eu de déconnection, c'est peut être réglé ?)
J'ai exactement le meme problème avec un Revolution en mode bridge sur fibre avec un Edgerouter Pro8 derrière. Perte de routage IPv4 de façon régulière (environ 1 fois par semaine), IPv6 toujours fonctionnel. Reboot nécéssaire pour retrouver le routage IPv4.
Freebox OS 4.0.6, nouvelle connection en ZMD datant de debut Novembre (Zone SFR). Je suis passé de SFR a Orange puis retour a Free.fr (j'étais en ADSL et étais passé chez SFR pour la fibre comme Free était pas encore dispo) et suis donc un peut mécontent de ce problème... L'assistance Free ne comprend pas ce qu'on leur dit donc inutile de les contacter.
Après, le bug est ouvert, le support au 3244 ne peut pas faire grand chose. Je comprends que le nombre de client en mode bridge soit faible, et donc que la priorité ne soit pas haute, mais ça fait plus qu'un an que ça dure...
D'autant ce qui est bizarre c'est que, dans mon cas, je perd souvent le lien mais mon routeur "s'en sort" la plupart du temps. Typiquement pendant ~80 jours je n'ai pas eu besoin de rebooter la box mais du jour au lendemain j'ai dû le faire. J'ai ça en boucle dans mes logs :/
Ce qui est d'autant plus lamentable, c'est que combiné au fait que les pertes de liens FO sont très fréquents (suffit de voir l'aduf, ou lafibre.info) pour certains, même avec un bon signal, ça rend le mode bridge inutilisable. Donc, soit corrgier ce bug, soit apporter des corrections sur les OLTs (ou je ne sais pas où) pour avec un lien FO stable, mais la situation actuelle est ridicule...
La solution temporaire est de rester en mode routeur puis faire une DMZ.
J'avais déjà informé la société Iliad/Free/Freebox à propos de la mise à jour à faire pour bridge-utils 1.5 → 1.6 (2016-10-17)
- https://dev.freebox.fr/bugs/task/25749
Lié au site https://floss.free.fr/ qui n'est pas à jour et également la base non à jour pour chaque produit aussi:
- https://dev.freebox.fr/bugs/task/22518
La DMZ (et donc le double nat) a aussi son lot d'inconvénients... Au passage, tu es sur que le passe de la 1.5 à 1.6 corrigerait le bug ?
Il n'y a pas réellement de changelog, faut regarder le code mais vu qu'il y a une nouvelle version enfin elle date mais elle doit corriger des problèmes:
- https://kernel.googlesource.com/pub/scm/linux/kernel/git/shemminger/bridge-utils/
- https://kernel.googlesource.com/pub/scm/linux/kernel/git/shemminger/bridge-utils/+/refs/tags/v1.6
- https://kernel.googlesource.com/pub/scm/linux/kernel/git/shemminger/bridge-utils/+/refs/tags/v1.5
- https://kernel.googlesource.com/pub/scm/linux/kernel/git/shemminger/bridge-utils/+/refs/heads/master
Une nouvelle version, c'est normal de mettre à jour, non ?
- https://packages.debian.org/fr/sid/bridge-utils - https://launchpad.net/ubuntu/+source/bridge-utils - http://www.fr.linuxfromscratch.org/view/blfs-stable/basicnet/bridge-utils.html - ...
A noter que la version 1.5 date de 2011 et la 1.6 de 2016.
J'ai une bonne nouvelle, "bridge-utils" a été intégré dans iproute2, qui est déjà dans les Freebox mais pas à jour.
Demande de mise à jour : iproute2 4.2.0 → 4.20.0 (2019-01-07)
https://dev.freebox.fr/bugs/task/25765
Je viens donc de créer un nouveau ticket: iproute2 4.2.0 (2015-08-31) → 5.4.0 (2019-11-25)
- https://dev.freebox.fr/bugs/task/29346
Allez voter, il faut enfin avoir cette résolution pour l'ensemble des Freebox en service.
- https://mirrors.edge.kernel.org/pub/linux/utils/net/iproute2/
- https://git.kernel.org/pub/scm/network/iproute2/iproute2.git
- https://wiki.linuxfoundation.org/networking/iproute2
Je commence sincerement a en avoir ras le bol de free, j'ai ce meme probleme FS#29024 - Perte de connection internet en mode bridge depuis pas mal de temps deja et AUCUN RETOUR DE FREE, ni biensur de resolution du probleme.
A quoi sert ce site a part perdre son temps puisque les problemes remontés ne sont pas traités ??
Sinon, quand il s'agit d'ajouter des fonctions inutiles ou blaireau-friendly, la, il y a du monde et tout le web franco-centrique s'en fait echo mais pour regler les vrais soucis ou ajouter les fonctions de base d'un reseau : vrai par-feu reglable par l'utilisateur, routage statique, resolution de ce bug immonde etc la on pisse dans un violon, et il y a en plus des abrutis pour dire que ca ne sert a rien (pour eux certainement puisque il sont incapables de comprendre)
Bref, j'ai la fibre free mais peut etre plus pour longtemps et au passage je basculerais parents et famille ailleurs aussi.
100% d'accord !
Sauf que le mode bridge chez les autres n'est pas toujours top ! A moins de remplacer la box par un routeur directement connecté sur la fibre, et encore sans IP fixe...
Donc Free, bouge toi le cul !!!
De mieux en mieux !
Cet après midi ma FBX Révolution en vDSL perd sa connexion, elle se relance et quitte toute seule le mode BRIDGE pour repasser en mode ROUTEUR.
Bien sur ça fout la grouille sur l'USG, mais comme il est en client DHCP seule les connections entrantes étaient impactées et donc j'ai mis un moment à m'en apercevoir...
Merci Free !
j'ai eu aussi ce probleme mais une ou 2 fois seulement, heuresement. D'un seul coup, la freebox qui etait en mode bridge est repassée toute seule en mode routeur. J'aimerais bien savoir ce qui a provoqué ca mais bon, dans ce domaine ont nous prends aussi pour des cons.
ja ideja vecu ce passage de bridge a routeur c lié a un gros update, ils ont coche pour les linuxiens le N au lieu du Y
Pour ma part ça y est je suis sur le réseau du fruit orangé...
Ben je me sens libéré, configuration de mon modem VDSL (Netgear DM200) beaucoup plus simple autant pour IPv4 que IPv6, pas d'histoire de 6rd qui fait qu'on est obligé de garder la box opérateur !
Cela va devenir plus simple de se passer de la box chez Orange que chez Free.... Le naufrage. Trop de box à maintenir ?
Ben clairement... chez Orange VLAN 832 en bridge sur l'eth0 du modem, côté routeur (pfSense chez moi) les bonnes trames DHCP4 et DHCP6 et roulez jeunesse !
Pour la TV et téléphone c'est pas non plus hyper compliqué même si je n'ai pas besoin de les mettre en oeuvre.
D'ailleurs je n'ai pas testé mais j'ai l'impression que je peux profiter du /56 IPv6 complet !
Information importante afin d'utiliser un routeur autre que sa Freebox :
- Il y a quelques jours OpenWrt 19.07.0 est sorti.
Qu'apporte cette version ?
J'imagine le 4"rd" ?
Ça devient fatiguant ce problème... J'essaie de mettre en place le palliatif du reboot par API et ipv6 mais impossible d'activer l'accès à distance. J'ai un joli message "Erreur lors de la récupération de la configuration" quand je passe dans le menu "Gestion des accès".
On peut tous essayer de faire des efforts avec des contournements, parce que l'on utilise pas les confs "standards", mais même si ces contournements ne fonctionnement plus il va falloir que se soit corrigé... sinon c'est go concurrence avec un bon vieux modem
J'ai eu un soucis en HTTPS pour contourner sur une box, du coup j'ai du repasser en HTTP et c'est OK. Mais pas en IPV6.
Passez chez le fruit orangé (ou sa marque bleue moins chère) : zéro soucis avec un modem en bridge (Netgear DM200) et /56 IPv6 complet ^^
@Damien, tout le monde sait ici qu'il est possible de changer d’opérateur...
Donc si on reste chez Free c'est que l'on y trouve tout de même un intérêt, une IP fixe par exemple pour ceux qui en ont besoin.
Ca existe encore des IP dynamiques ?!
Je suis en IP fixe chez le fruit... et aucun soucis que ça soit en v4 ou v6 ^^
Chez Orange les IP sont dynamiques, sauf en Orange Business, mais c’est plus cher. Chez BT et SFR les IP sont dynamiques, mais elles bougent très peu, donc ce sont presque des IP fixes. Chez Free les IP sont fixes mais maintenant partagées. Mais tout le monde peut demander une full IP. Après chacun fait ce qu'il veut avec le marché selon ses besoins et ses habitudes.
Ils ont dû faire évoluer ça parce que je suis en IP fixe ça c'est certain !
Tan mieux pour toi, tu dois être en Pro ou il s'agit d'une erreur de leur part car aucune offre Orange ou Sosh ne propose d'IP fixe, même en option. Et dans les offres pro c'est contractuel, donc clairement exprimé dans le contrat. Mais fin du sujet, car ce n'est pas l'objet de ce fil que l'on est en train de troler.
Orange proposait l'IP fixe au grand public pour 15 euros / mois, ce n'est peut être plus d'actualités. Sinon c'est possible gratuitement dès Orange Pro (pas forcément business). Mais effectivement, le coût mensuel est plus cher.
Sinon pour en revenir au ticket, une mise à jour des libs dans Freebox OS et de Freebox OS lui même pourrait sans doute redonner un mode bridge stable. J'ai préféré le double NAT. C'est moche mais plus stable.
Et aucune communication des devs de Free sur le sujet... c'est peut être ça le pire.
Au final qq'un de France ou de Navarre est-il jamais arrivé à l'aide de son propre routeur à mettre en place une connectivité IPv4 + IPv6 sur un DSLAM IPv6 en xDSL ? Et en Fibre (non point à point, logiquement) ?
@Zebu1er: https://lafibre.info/remplacer-freebox/
Je viens de voir ça : https://lafibre.info/remplacer-freebox/instabilite-sur-la-connection-free-sans-freebox
Mêmes symptômes sans freebox, si le problème est lié, il vient sûrement des équipements derrière la freebox et l'architecture/protocoles du réseau de Free.
Ça expliquerai l'absence totale de réaction des dev, le problème n'étant pas vraiment chez eux... bref à suivre
Possible que ça ne vienne pas directement de la Freebox elle même. Mais de Free oui ! Et donc c'est à Free de répondre.
Dans ton lien il s'agit du remplacement de la Freebox en FO, ll serait intéressant de savoir si àa arrive également en cas de remplacement en mode ADSL.
la seule chose qui me fait resté chez free actuellement c'est l'ipv4 fixe. Malheuresement, ca ne sert plus a grand chose si la connection est down...
la, j'etudie les offres concurrentes pour me barrer a court / moyen terme.
J'ai vu que red propose la fibre 1Gb down 400Mbps up pour 23€ par mois et cerise sur le gateau la tv en option ! super pour moi du coup je pense peut etre basculer mais il y a peu d'infos techniques sur le modem. Es-ce qu'on peu le remplacer facilement par son propre routeur en conservant la telephonie ? la consommation en watts du modem ?
Ou peu t'on trouver des infos sur les debits moyens constatés sur la fibre sfr red ??
En fibre j'imagine que la majorité des opérateurs proposent de l'IP fixe ?
En tout cas chez Sosh j'en ai fait l'expérience sur du VDSL je suis en IP fixe avec un modem perso devant un pfSense et c'est hyper stable autant en IPv4 et IPv6.
Non, aucun opérateur ne propose de l'IP fixe garantie.
Les baux DHCP sont souvent assez longs, mais l'IP finit toujours par changer.
Vécu et testé chez Sosh FTTH.
Bon, après, c'est peut-être pas trop l'endroit pour discuter de tout ça ? Même si je comprends tout à fait la frustration au vu du silence de Free.
Bonne nouvelle !
Je viens d'avoir une déconnexion et au retour du lien l'IPv4 était fonctionnelle (i.e. mon script n'a pas eu besoin de redémarrer la Freebox serveur):
La version du micrologiciel de la Freebox étant toujours la 4.0.7, j'en déduis que Free a corrigé le problème en amont, sur ses équipements...
Bon, cela reste évidemment à confirmer: suite à la prochaine déconnexion.
Ben non, désolé pour le "bruit"... Il s'agissait juste d'un redémarrage (télécommandé de chez Free ? intempestif ?) de la Freebox...
J'ai tenté l'expérience de déconnexion/reconnexion de la fibre, et le problème est toujours là !
Arf, j'y ai cru un instant :/
Bonjour,
Je detere ce topic, même souci ici aussi depuis des mois mais en VDSL2, fbx revolution en mode bridge. Routeur derrière.
Perte de connection internet sur le routeur après une desynchro/resynchro du Fbx server.
Obligé de rebooter le fbx server pour que ça reparte
Malheureusement, on ne peut pas parler de déterrage, le bug étant toujours d'actualité. Il n'y a qu'à voir le nombre de message sur ce fil de discussion depuis le début de l'année.
qqn de free pourrait cdonner des news sur la roadmap pour ça ?
Perso, je n'y crois plus.
Heureusement mon OpenWrt fait le job, et heureusement parce qu'avec toutes les personnes qui mettent la main dans le répartiteur en ce moment, les décos sont fréquentes.
Thu Mar 26 00:46:13 2020 daemon.info linetest[5952]: FAIL since Thu Mar 26 00:45:43 CET 2020 (30 seconds)
Thu Mar 26 00:48:44 2020 daemon.info linetest[5952]: Launching Freebox reboot after 0 hours, 3 minutes, 1 seconds
Thu Mar 26 00:48:45 2020 daemon.info linetest[5952]: rebootfreebox → Freebox API version: 6.0
Thu Mar 26 00:48:45 2020 daemon.info linetest[5952]: rebootfreebox → Track ID: 1
Thu Mar 26 00:48:49 2020 daemon.info linetest[5952]: rebootfreebox → Waiting API response....
Thu Mar 26 00:48:52 2020 daemon.info linetest[5952]: rebootfreebox → Reboot initiated
Thu Mar 26 00:51:52 2020 daemon.info linetest[5952]: Launching Freebox reboot after 0 hours, 6 minutes, 9 seconds
Thu Mar 26 00:54:02 2020 daemon.info linetest[5952]: rebootfreebox → Freebox API version:
Thu Mar 26 00:54:02 2020 daemon.info linetest[5952]: rebootfreebox → Track ID: 1
Thu Mar 26 00:56:15 2020 daemon.info linetest[5952]: rebootfreebox → Waiting API response....
Thu Mar 26 00:56:15 2020 daemon.info linetest[5952]: rebootfreebox → Error: status
Thu Mar 26 00:56:25 2020 daemon.info linetest[5952]: Launching Freebox reboot after 0 hours, 10 minutes, 42 seconds
Thu Mar 26 00:58:34 2020 daemon.info linetest[5952]: rebootfreebox → Freebox API version:
Thu Mar 26 00:58:34 2020 daemon.info linetest[5952]: rebootfreebox → Track ID: 1
Thu Mar 26 01:00:47 2020 daemon.info linetest[5952]: rebootfreebox → Waiting API response....
Thu Mar 26 01:00:47 2020 daemon.info linetest[5952]: rebootfreebox → Error: status
Thu Mar 26 01:00:57 2020 daemon.info linetest[5952]: Launching Freebox reboot after 0 hours, 15 minutes, 14 seconds
Thu Mar 26 01:03:07 2020 daemon.info linetest[5952]: rebootfreebox → Freebox API version:
Thu Mar 26 01:03:07 2020 daemon.info linetest[5952]: rebootfreebox → Track ID: 1
Thu Mar 26 01:05:20 2020 daemon.info linetest[5952]: rebootfreebox → Waiting API response....
Thu Mar 26 01:05:20 2020 daemon.info linetest[5952]: rebootfreebox → Error: status
Thu Mar 26 01:05:30 2020 daemon.info linetest[5952]: Launching Freebox reboot after 0 hours, 19 minutes, 47 seconds
Thu Mar 26 01:07:39 2020 daemon.info linetest[5952]: rebootfreebox → Freebox API version:
Thu Mar 26 01:07:39 2020 daemon.info linetest[5952]: rebootfreebox → Track ID: 1
Thu Mar 26 01:09:52 2020 daemon.info linetest[5952]: rebootfreebox → Waiting API response....
Thu Mar 26 01:09:52 2020 daemon.info linetest[5952]: rebootfreebox → Error: status
Thu Mar 26 01:10:02 2020 daemon.info linetest[5952]: Launching Freebox reboot after 0 hours, 24 minutes, 19 seconds
Thu Mar 26 01:12:13 2020 daemon.info linetest[5952]: rebootfreebox → Freebox API version:
Thu Mar 26 01:12:13 2020 daemon.info linetest[5952]: rebootfreebox → Track ID: 1
Thu Mar 26 01:12:48 2020 daemon.info linetest[5952]: rebootfreebox → Waiting API response....
Thu Mar 26 01:12:52 2020 daemon.info linetest[5952]: rebootfreebox → Reboot initiated
Thu Mar 26 01:12:52 2020 daemon.info linetest[5952]: SUCCESS after 0 hours, 27 minutes, 9 seconds
Thu Mar 26 01:13:38 2020 daemon.info linetest[5952]: FAIL since Thu Mar 26 01:13:08 CET 2020 (30 seconds)
Thu Mar 26 01:14:08 2020 daemon.info linetest[5952]: SUCCESS after 0 hours, 1 minutes, 0 seconds
Thu Mar 26 02:19:07 2020 daemon.info linetest[5952]: FAIL since Thu Mar 26 02:18:37 CET 2020 (30 seconds)
Thu Mar 26 02:21:37 2020 daemon.info linetest[5952]: Launching Freebox reboot after 0 hours, 3 minutes, 0 seconds
Thu Mar 26 02:21:38 2020 daemon.info linetest[5952]: rebootfreebox → Freebox API version: 6.0
Thu Mar 26 02:21:38 2020 daemon.info linetest[5952]: rebootfreebox → Track ID: 1
Thu Mar 26 02:21:42 2020 daemon.info linetest[5952]: rebootfreebox → Waiting API response....
Thu Mar 26 02:21:44 2020 daemon.info linetest[5952]: rebootfreebox → Reboot initiated
Thu Mar 26 02:24:44 2020 daemon.info linetest[5952]: Launching Freebox reboot after 0 hours, 6 minutes, 7 seconds
Thu Mar 26 02:26:54 2020 daemon.info linetest[5952]: rebootfreebox → Freebox API version:
Thu Mar 26 02:26:54 2020 daemon.info linetest[5952]: rebootfreebox → Track ID: 1
Thu Mar 26 02:29:07 2020 daemon.info linetest[5952]: rebootfreebox → Waiting API response....
Thu Mar 26 02:29:07 2020 daemon.info linetest[5952]: rebootfreebox → Error: status
Thu Mar 26 02:29:17 2020 daemon.info linetest[5952]: Launching Freebox reboot after 0 hours, 10 minutes, 40 seconds
Thu Mar 26 02:31:27 2020 daemon.info linetest[5952]: rebootfreebox → Freebox API version:
Thu Mar 26 02:31:27 2020 daemon.info linetest[5952]: rebootfreebox → Track ID: 1
Thu Mar 26 02:33:40 2020 daemon.info linetest[5952]: rebootfreebox → Waiting API response....
Thu Mar 26 02:33:40 2020 daemon.info linetest[5952]: rebootfreebox → Error: status
Thu Mar 26 02:33:50 2020 daemon.info linetest[5952]: Launching Freebox reboot after 0 hours, 15 minutes, 13 seconds
Thu Mar 26 02:33:51 2020 daemon.info linetest[5952]: rebootfreebox → Freebox API version: 6.0
Thu Mar 26 02:33:51 2020 daemon.info linetest[5952]: rebootfreebox → Track ID: 1
Thu Mar 26 02:33:55 2020 daemon.info linetest[5952]: rebootfreebox → Waiting API response....
Thu Mar 26 02:33:57 2020 daemon.info linetest[5952]: rebootfreebox → Reboot initiated
Thu Mar 26 02:34:07 2020 daemon.info linetest[5952]: Launching Freebox reboot after 0 hours, 15 minutes, 30 seconds
Thu Mar 26 02:36:18 2020 daemon.info linetest[5952]: rebootfreebox → Freebox API version:
Thu Mar 26 02:36:18 2020 daemon.info linetest[5952]: rebootfreebox → Track ID: 1
Thu Mar 26 02:38:31 2020 daemon.info linetest[5952]: rebootfreebox → Waiting API response....
Thu Mar 26 02:38:31 2020 daemon.info linetest[5952]: rebootfreebox → Error: status
Thu Mar 26 02:38:41 2020 daemon.info linetest[5952]: Launching Freebox reboot after 0 hours, 20 minutes, 4 seconds
Thu Mar 26 02:40:50 2020 daemon.info linetest[5952]: rebootfreebox → Freebox API version:
Thu Mar 26 02:40:50 2020 daemon.info linetest[5952]: rebootfreebox → Track ID: 1
Thu Mar 26 02:43:03 2020 daemon.info linetest[5952]: rebootfreebox → Waiting API response....
Thu Mar 26 02:43:03 2020 daemon.info linetest[5952]: rebootfreebox → Error: status
Thu Mar 26 02:43:13 2020 daemon.info linetest[5952]: Launching Freebox reboot after 0 hours, 24 minutes, 36 seconds
Thu Mar 26 02:43:14 2020 daemon.info linetest[5952]: rebootfreebox → Freebox API version: 6.0
Thu Mar 26 02:43:14 2020 daemon.info linetest[5952]: rebootfreebox → Track ID: 1
Thu Mar 26 02:43:18 2020 daemon.info linetest[5952]: rebootfreebox → Waiting API response....
Thu Mar 26 02:43:20 2020 daemon.info linetest[5952]: rebootfreebox → Reboot initiated
Thu Mar 26 02:43:20 2020 daemon.info linetest[5952]: SUCCESS after 0 hours, 24 minutes, 43 seconds
Thu Mar 26 02:44:08 2020 daemon.info linetest[5952]: FAIL since Thu Mar 26 02:43:38 CET 2020 (30 seconds)
Thu Mar 26 02:44:38 2020 daemon.info linetest[5952]: SUCCESS after 0 hours, 1 minutes, 0 seconds
Thu Mar 26 07:15:21 2020 daemon.info linetest[5952]: FAIL since Thu Mar 26 07:14:51 CET 2020 (30 seconds)
Thu Mar 26 07:17:51 2020 daemon.info linetest[5952]: Launching Freebox reboot after 0 hours, 3 minutes, 0 seconds
Thu Mar 26 07:17:52 2020 daemon.info linetest[5952]: rebootfreebox → Freebox API version: 6.0
Thu Mar 26 07:17:52 2020 daemon.info linetest[5952]: rebootfreebox → Track ID: 1
Thu Mar 26 07:17:56 2020 daemon.info linetest[5952]: rebootfreebox → Waiting API response....
Thu Mar 26 07:17:58 2020 daemon.info linetest[5952]: rebootfreebox → Reboot initiated
Thu Mar 26 07:19:18 2020 daemon.info linetest[5952]: SUCCESS after 0 hours, 4 minutes, 27 seconds
Même sans intervention au PM, ça déco fréquemment chez Free (la fameuse perte du lien optique de 9 secondes dans les logs).
oui surement, l'autre jour dans les logs jai vu une 15aine de desynchros en une heure.
Mais ce pb commence à devenir pesant quand on a des services hostés chez soi....
ce bug existe aussi en ADSL (VDSL2 dans mon cas) pour info
pareil ici en VDSL2. A la resynchro, l'ipv6 fonctionne mais l'ipv4 est en vrac. Hormis le redémarrage de la box, pas d'autre solution.
Habituellement, pas trop de désynchro mais les derniers, plusieurs par journées et vu que je suis en télétravail, c'est pas la joie.
je suis avec une Freebox révolution, firmware 4.0.7. Que la synchro s’établisse en ADSL ou en VDSL, je suis confronté au même bug. Je suis en mode bridge, connecté à un routeur ORBI RBK50 v1 depuis 3 semaines. Pas une journée sans une courte perte d’Internet. Le flux TV semble lui par contre epargné (bon après peut-être que j’ai toujours regardé ma TV en dehors des coupures ?! Difficile à confirmer à 100%...) J’ai apporté mon vote pour la résorption du bug ! En attendant je vais devoir repasser en mode routeur (fait ‘hiech!)
Je rajoute mon expérience.
Quand il y a perte de connexion, c'est en IPv4 uniquement. L'IPv6 reste fonctionnelle, pour tous les sites. Comme j'utilise un résolveur DNS sur mon routeur, je vois bien la différence.
Le redémarrage des interfaces du routeur ne change rien. Seul le redémarrage du serveur permet un retour en quelques instants à la normale sur l'IPv4.
Après avoir perdu plusieurs fois la connexion juste après être parti en week-end, j'ai fini par faire un script Python qui s'occupe de redémarrer la Freebox tout seul.
Si ça peut être utile à certains, j'ai mis les sources ici ⇒ https://github.com/ugomeda/freebox-os-reboot
Un reboot c'est un peu too munch non ?
J'avais fait un script avec un simple passage vers le mode routeur puis retour au mode bridge et cela suffisait.
Ça se fait par appel API aussi : https://github.com/dough29/FreeboxBridgeIPV4Checker/blob/master/checkIPV4.sh
@Ugo Méda
merci pour le script. il fonctionne en ipv4 quand la connection est ok, mais quand le bug arrive, l'ip 212.27.38.253 n'est plus accessible depuis le LAN je crois (pas encore testé lorsque le bug est actif). Du coup cela obligerais a utiliser l'ipv6 de la box pour la joindre, mais chez moi tout l'ipv6 est desactivé et bloqué. Au pire je pourrais activé ipv6 sur mon odroid c2 qui gere la domotique mais je ne veux pas avoir une ipv6 sur internet cette machine et apparement le ping ipv6 lien local de la freebox depuis mon lan ne fonctionne pas (ma config est : freebox server en mode bridge > routeur x86 openwrt > switch microtik > LAN)
@claudius Ce n'est pas le comportement que j'ai sur ma Freebox (mini 4K), j'ai bien fait attention à tout tester quand j'ai eu le problème hier avant de lancer un reboot de la Freebox. En revanche, le DNS (mafreebox.freebox.fr) n'était pas disponible.
Quand le problème se produit l'IPv4 fonctionne toujours sur le LAN. La Freebox reste donc joignable sur son IP locale.
Par contre forcément le DNS si paramétré en IPv4 ne fonctionnera plus (hors cache ou entrée sur le serveur local).
merci, en effet le dns mafreebox.freebox.fr ne fonctionne pas mais l'ip je n'en etait pas sur car j'ai le souvenir d'avoir testé l'acces a l'interface web via l'ip et elle ne repondait plus, d'ou mon doute. Enfin, si tu a testé, je te fait confiance, je retesterais via l'ip quand la liaison ipv4 tombera.
@Ugo Méda merci pour le script, il peut s'utiliser sur un synology ? je n'ai pas de machine en permanence allumée à la maison à part ça.
On peut supposer que ce bugg a été porté sur la nouvelle box POP ?
Hello !
https://dev.freebox.fr/bugs/task/29346
Cette demande a été clôturée hier et il y a eu des MAJ sur les Freebox : à voir l'impact sur le mode bridge.
hier perte de lien ipv4, j'avais installé le script de @Damien pour rebooter la box en cas de probleme, malheuresement, chez moi ca il ne fonctionne pas car quand le lien tombe, l'ip 212.27.38.253 est inaccessible
HTTPSConnectionPool(host='212.27.38.253', port=3387): Max retries exceeded with url: /api/v8/login/ (Caused by NewConnectionError('<urllib3.connection.HTTPSConnection object at 0xffffb31aa880>: Failed to establish a new connection: [Errno 110] Connection timed out'))quand le lien fonctionne, j'arrive a redemarrer la box sans probleme avec le script
@claude:
Oui j'avais le souci au début, quand ça tombait, je perdais la route. j'ai mis une route statique pour accéder à l'IP de la Freebox et ça a réglé le problème
@Jordy
J'ai essayé en simulant une perte de lien en debranchant le cable optique et en mettant une route statique sur un linux derriere le routeur (openwrt)
puis en lancant le script de damien, resultat : idem
Impossible de contacter les adresses IP 8.8.8.8, 1.1.1.1... Lancement du redémarrage de la Freebox... ERREUR HTTPSConnectionPool(host='212.27.38.253', port=3387): Max retries exceeded with url: /api/v8/login/ (Caused by NewConnectionError('<urllib3.connection.HTTPSConnection object at 0xffff9100d790>: Failed to establish a new connection: [Errno 110] Connection timed out'))pourtant la box repond bien au ping (en simulation avec le cable optique debranché) bizarre
Donc le bug est toujours présent si je comprends bien.
Suite à la fermeture du ticket https://dev.freebox.fr/bugs/task/29346 , j'ai redemandé la réouverture car la mise à jour n'est pas up-to-date (5.4.0 alors qu'aujourd'hui nous sommes en 5.7.0), une évolution mais donc incomplète.
Par ailleurs, bridge-utils n'a pas été mis à jour malheureusement, j'avais demandé la version 1.6 (2016-10-17), il y a toujours la 1.5 (2011-03-29) :/
- https://dev.freebox.fr/bugs/task/25749
Par ailleurs, une nouvelle version bridge-utils vient de sortir après des années, la 1.7 (2020-06-23) :)
- https://git.kernel.org/pub/scm/linux/kernel/git/shemminger/bridge-utils.git/
Je vous invite à voter le ticket bridge-utils, merci par avance.
perso je suis pas contre la maj des packages, bien au contraire, mais sur ce ticket #22818 on a faire à un probleme extremement ennuyeux de perte de liaison depuis pas mal de temps ce qui oblige tout le monde a bidouiller un reboot automatique ou une coupure electrique de la box et il ne me semble pas que l'origine soit clairement identifiée mais elle touche que ipv4.
Une solution de contournement aurait aussi pu etre la possibilité d'ajouter des routes statique via l'interface de la freebox, ce qui permetrait de passer la freebox en mode routeur (la ou le probleme de perte de liaison ne se produit pas) tout en ayant un vrai firewall derriere pour proteger le reseau, et en profitant du nat materiel de la box pour effectué la translation d'adresse. Mais je crois avoir lu que cela etait impossible sur la freebox etant donné qu'elle utilisait deja tous les reseaux de classe C pour son usage interne... ca fait beaucoup quand même
Après mise à jour du firmware il y a quelques jours (4.20), j'ai essayé aujourd'hui de débrancher puis rebrancher la connexion fibre sur la box/serveur (retrait/réinsertion du module à l'intérieur du serveur). Connexion perdue qui n'est pas revenue toute seule. Au bout de quelques minutes, le script a détecté l'absence de connexion et a redémarré la box, comme d'habitude...
Donc, je confirme que le bug est toujours présent.
Je viens d'ouvrir le nouveau ticket suite à la fermeture de l'ancien pour iproute2 :
- https://dev.freebox.fr/bugs/task/30995
Merci de voter dessus...
Je peux également confirmer que ce bug est présent. Ce matin, mon accès à Internet via IPv4 a été bloqué et un redémarrage fixé immédiatement. Cela a été confirmé par le site: https://www.free-reseau.fr/ma-ligne/ qui a montré la connexion avait été interrompue pendant une heure et, bien sûr, disponible après le redémarrage. :)
Avec Freebox OS 4.2.3 ou 4.2.4 (uniquement sur Pop), est-ce toujours pareil ?
surtout pas, ce n'est pas hotplug
débranchez la fibre si vous voulez, mais pas le module