Freebox Server (Delta V7 / Revolution V6 / Server Mini 4K)

  • État Nouveau
  • Type de tâche Anomalie
  • Catégorie LAN → Bridge
  • Assignée à Personne
  • Système d'exploitation Freebox Server V6 (Révolution)
  • Sévérité Haute
  • Priorité Normale
  • Basée sur la version 3.5.2
  • Due pour la version Non décidé
  • Date d'échéance Non décidé
Concerne le projet: Freebox Server (Delta V7 / Revolution V6 / Server Mini 4K)
Ouverte par morloch (morloch) - 31/08/2018
Dernière édition par Thibaut Freebox (Thibaut Freebox) - 02/09/2019

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

Cette tache ne dépend pas d'autre tache

RCK (RCK)
Monday 3 September, 2018 10:26:01

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.

RCK (RCK)
Monday 3 September, 2018 13:51:33

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).

docteurmicro50 (docteurmicro50)
Wednesday 12 September, 2018 11:55:41

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?

docteurmicro50 (docteurmicro50)
Wednesday 12 September, 2018 11:56:47

Précision : je constate ce phénomène dès qu'il y a une déconnexion puis connexion de l'accès internet.

Jordy Provost (JPFree)
Wednesday 26 September, 2018 20:24:04

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 ;)

serge (xenonserge)
Thursday 1 November, 2018 10:08:38

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!

RCK (RCK)
Tuesday 20 November, 2018 10:44:15

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 !

morloch (morloch)
Tuesday 20 November, 2018 19:48:22

@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:

login_freebox "$MY_APP_ID" "$MY_APP_TOKEN"
reboot_freebox

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.

RCK (RCK)
Tuesday 20 November, 2018 20:17:59

@Morloch: Merci beaucoup pour tous ces détails ! Cela va nous permettre de palier la non réaction de Free sur le sujet :)

hm (hm)
Thursday 22 November, 2018 13:42:33

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.

desu (desu)
Friday 23 November, 2018 21:29:51

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).

Eric Sibert (Eric_S)
Sunday 9 December, 2018 10:52:48

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:

Determining if ip address 82.64.xxx.xxx is already in use for device eth1...

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.

maze (maze92)
Sunday 9 December, 2018 11:44:04

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.

morloch (morloch)
Sunday 9 December, 2018 13:15:31

@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é...

morloch (morloch)
Sunday 9 December, 2018 13:18:31

@Eric Sibert

Pour les emails envoyés par crond, modifiez simplement /etc/crontab pour lire: MAILTO=""

Eric Sibert (Eric_S)
Sunday 9 December, 2018 18:26:49

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.

RCK (RCK)
Wednesday 12 December, 2018 09:10:39
Un seul point a préciser c'est que ce problème ne se produit que lors d'une synchro en VDSL2.

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 ?

morloch (morloch)
Wednesday 12 December, 2018 13:13:13

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 ?

Damien (dough29)
Wednesday 12 December, 2018 17:59:46

Merci pour cette information.

Malgré une version potentiellement majeure (3 → 4) on ne constate pas grand chose sur cette nouvelle "mouture"...

Eric Sibert (Eric_S)
Monday 17 December, 2018 10:35:04

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.

morloch (morloch)
Monday 17 December, 2018 11:50:10

@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 ?

Eric Sibert (Eric_S)
Saturday 22 December, 2018 19:31:44

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 :-(.

RCK (RCK)
Thursday 17 January, 2019 13:46:21

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

Jérôme (badprocess)
Thursday 17 January, 2019 13:58:37

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

RCK (RCK)
Monday 21 January, 2019 22:56:54

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).

Damien (dough29)
Tuesday 22 January, 2019 07:34:27

Pendant ce temps on bosse gratuitement pour Free qui ne daigne même pas nous considérer...

RCK (RCK)
Tuesday 22 January, 2019 09:12:30

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 :(

Neustradamus (Neustradamus)
Friday 25 January, 2019 03:13:42

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

morloch (morloch)
Friday 25 January, 2019 08:48:30

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.

Jérôme (badprocess)
Friday 15 February, 2019 08:27:59

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.

RCK (RCK)
Friday 15 February, 2019 09:06:57

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.

Jérôme (badprocess)
Friday 15 February, 2019 09:10:34

Personnellement ça me le faisait systématiquement même lorsque je redémarrai la box donc effectivement, wait and see :)

RCK (RCK)
Tuesday 23 April, 2019 07:36:32

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.

RCK (RCK)
Wednesday 24 April, 2019 06:15:53

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.

Jérôme (badprocess)
Thursday 25 April, 2019 12:31:36

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.

influenzae (influenzae)
Friday 7 June, 2019 20:04:48

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..)

Michael (mika1337)
Friday 21 June, 2019 01:28:46

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.

arnaud (aco)
Saturday 10 August, 2019 02:21:29

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...

arnaud (aco)
Saturday 10 August, 2019 03:31:11

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 !".

Damien (dough29)
Saturday 10 August, 2019 04:22:34

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 ^^

morloch (morloch)
Saturday 10 August, 2019 07:27:35

@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).

arnaud (aco)
Saturday 10 August, 2019 10:07:55

@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.

morloch (morloch)
Tuesday 13 August, 2019 15:27:24

@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...

Lionel Bruno (lionelb)
Wednesday 28 August, 2019 11:02:56

Bonjour,

Pour revenir au script, pensez vous que l'on puisse l’exécuter depuis l'extérieur ?

merci

morloch (morloch)
Wednesday 28 August, 2019 12:15:10

@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.

Lionel Bruno (lionelb)
Wednesday 28 August, 2019 12:42:13

Bonjour,

Pour revenir au script, pensez vous que l'on puisse l’exécuter depuis l'extérieur ?

merci

Lionel Bruno (lionelb)
Wednesday 28 August, 2019 12:42:56

Oups desolé pour le repost

Lionel Bruno (lionelb)
Wednesday 28 August, 2019 12:45:40

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 :-)

prohand (prohand)
Wednesday 28 August, 2019 13:26:21

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 :)

Lionel Bruno (lionelb)
Saturday 31 August, 2019 15:17:51

Voilà pour redémarrer à distance en Powershell via l'API : https://www.canaletto.fr/post/surveiller-et-redemarrer-une-freebox-a-distance

pierre (zorabug)
Saturday 31 August, 2019 19:41:55

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:

 Hold at IP de chez OVH,100.0 % ; Sat Aug 31 2019 , 19:58:40
 Hold at IP de chez OVH,100.0 % ; Sat Aug 31 2019 , 19:28:17
 Hold at IP de chez OVH,100.0 % ; Sat Aug 31 2019 , 18:48:22
 Hold at IP de chez OVH,70.0 % ; Sat Aug 31 2019 , 18:17:58
 Hold at IP de chez OVH,100.0 % ; Tue Aug 27 2019 , 16:38:54
 Hold at IP de chez OVH,100.0 % ; Tue Aug 27 2019 , 08:28:11
 Hold at IP de chez OVH,100.0 % ; Tue Aug 27 2019 , 07:57:48
 Hold at IP de chez OVH,100.0 % ; Tue Aug 27 2019 , 07:27:25
 Hold at IP de chez OVH,100.0 % ; Tue Aug 27 2019 , 06:57:02
 Hold at IP de chez OVH,100.0 % ; Tue Aug 27 2019 , 06:26:39
 Hold at IP de chez OVH,100.0 % ; Tue Aug 27 2019 , 05:56:16
 Hold at IP de chez OVH,100.0 % ; Tue Aug 27 2019 , 05:25:53
 Hold at IP de chez OVH,100.0 % ; Tue Aug 27 2019 , 04:55:30
 Hold at IP de chez OVH,100.0 % ; Tue Aug 27 2019 , 04:25:07
 Hold at IP de chez OVH,100.0 % ; Tue Aug 27 2019 , 03:54:44
 Hold at IP de chez OVH,100.0 % ; Tue Aug 27 2019 , 03:24:21
 Hold at IP de chez OVH,100.0 % ; Tue Aug 27 2019 , 02:53:58
 Hold at IP de chez OVH,100.0 % ; Tue Aug 27 2019 , 02:23:35
 Hold at IP de chez OVH,100.0 % ; Tue Aug 27 2019 , 01:53:12
 Hold at IP de chez OVH,100.0 % ; Tue Aug 27 2019 , 01:22:49
 Hold at IP de chez OVH,100.0 % ; Tue Aug 27 2019 , 00:52:26
 Hold at IP de chez OVH,100.0 % ; Tue Aug 27 2019 , 00:22:03
 Hold at IP de chez OVH,100.0 % ; Mon Aug 26 2019 , 23:51:40
 Hold at IP de chez OVH,100.0 % ; Mon Aug 26 2019 , 23:21:17
 Hold at IP de chez OVH,100.0 % ; Mon Aug 26 2019 , 22:50:54
 Hold at IP de chez OVH,100.0 % ; Mon Aug 26 2019 , 22:20:31
 Hold at IP de chez OVH,100.0 % ; Mon Aug 26 2019 , 21:50:08
 Hold at IP de chez OVH,100.0 % ; Mon Aug 26 2019 , 21:19:45
 Hold at IP de chez OVH,100.0 % ; Mon Aug 26 2019 , 20:49:22
 Hold at IP de chez OVH,100.0 % ; Mon Aug 26 2019 , 20:18:59
 Hold at IP de chez OVH,100.0 % ; Mon Aug 26 2019 , 19:48:30
 Hold at IP de chez OVH,100.0 % ; Mon Aug 26 2019 , 19:18:13
 Hold at IP de chez OVH,100.0 % ; Mon Aug 26 2019 , 18:47:50
 Hold at IP de chez OVH,100.0 % ; Mon Aug 26 2019 , 18:17:27
 Hold at IP de chez OVH ,100.0 % ; Mon Aug 26 2019 , 17:47:04

Log sur la 4k bridge vdsl + Cisco RVS4000:

 Hold at IP de chez OVH,90.0 % ; Thu Feb 21 2019 , 10:53:58
 Hold at IP de chez OVH,80.0 % ; Thu Feb 21 2019 , 10:20:40
 Hold at IP de chez OVH,80.0 % ; Thu Feb 21 2019 , 09:47:42
 Hold at IP de chez OVH,90.0 % ; Thu Feb 21 2019 , 09:08:54
 Hold at IP de chez OVH,60.0 % ; Thu Feb 21 2019 , 08:31:22
 Hold at www.google.fr,50.0 % ; Wed Feb 20 2019 , 22:35:45
 Hold at IP de chez OVH,70.0 % ; Wed Feb 20 2019 , 21:37:19
 Hold at IP de chez OVH,70.0 % ; Wed Feb 20 2019 , 21:06:12
 Hold at www.google.fr,60.0 % ; Wed Feb 20 2019 , 20:28:51
 Hold at IP de chez OVH,70.0 % ; Wed Feb 20 2019 , 19:44:21
 Hold at IP de chez OVH,100.0 % ; Wed Feb 20 2019 , 19:13:58
 Hold at IP de chez OVH,80.0 % ; Wed Feb 20 2019 , 18:36:15
 Hold at IP de chez OVH,50.0 % ; Wed Feb 20 2019 , 18:05:41
 Hold at www.google.fr,80.0 % ; Wed Feb 20 2019 , 17:35:18
 Hold at IP de chez OVH,100.0 % ; Wed Feb 20 2019 , 16:53:00
 Hold at IP de chez OVH,80.0 % ; Wed Feb 20 2019 , 16:17:07
 Hold at IP de chez OVH,100.0 % ; Wed Feb 20 2019 , 15:42:30
 Hold at IP de chez OVH,70.0 % ; Wed Feb 20 2019 , 14:55:37
 Hold at IP de chez OVH,60.0 % ; Wed Feb 20 2019 , 14:24:53
 Hold at www.google.fr,90.0 % ; Wed Feb 20 2019 , 13:50:06
 Hold at www.google.fr,60.0 % ; Wed Feb 20 2019 , 13:19:42
 Hold at www.google.fr,70.0 % ; Wed Feb 20 2019 , 12:47:30
 Hold at IP de chez OVH,100.0 % ; Wed Feb 20 2019 , 12:11:58
 Hold at www.google.fr,80.0 % ; Wed Feb 20 2019 , 11:35:21
 Hold at www.google.fr,50.0 % ; Wed Feb 20 2019 , 11:03:31
 Hold at IP de chez OVH,100.0 % ; Wed Feb 20 2019 , 10:30:11
 Hold at www.google.fr,80.0 % ; Wed Feb 20 2019 , 09:53:45
 Hold at www.google.fr,70.0 % ; Wed Feb 20 2019 , 09:13:39
 Hold at www.google.fr,100.0 % ; Wed Feb 20 2019 , 08:42:10
 Hold at www.google.fr,60.0 % ; Tue Feb 19 2019 , 21:12:53
 Hold at IP de chez OVH,50.0 % ; Tue Feb 19 2019 , 20:38:28
 Hold at www.google.fr,100.0 % ; Tue Feb 19 2019 , 20:08:05
 Hold at IP de chez OVH,100.0 % ; Tue Feb 19 2019 , 19:30:44
 Hold at IP de chez OVH,70.0 % ; Tue Feb 19 2019 , 18:57:14

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

- (Rootax)
Sunday 1 September, 2019 09:38:23

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.

Neustradamus (Neustradamus_)
Monday 2 September, 2019 09:38:34

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

Neustradamus (Neustradamus_)
Monday 2 September, 2019 23:12:53

Pour l'ensemble des devs, attention : Le problème est présent sur les différents modèles de Freebox Server ;)

pierre (zorabug)
Tuesday 3 September, 2019 16:54:09

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

Arnaud Ladrière (kador)
Thursday 12 September, 2019 11:57:33

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.

Arnaud Ladrière (kador)
Thursday 12 September, 2019 11:58:34

Je précise que je suis en 4.0.7 et non 3.x comme le posteur original, le soucis est ancien.

Chargement...