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.

Samuel (poulpito)
Friday 20 September, 2019 09:02:39

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

Arnaud Ladrière (kador)
Friday 20 September, 2019 11:36:30

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.

Damien (dough29)
Friday 20 September, 2019 12:21:43

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

Arnaud Ladrière (kador)
Friday 20 September, 2019 12:46:19

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.

dem (dem)
Tuesday 1 October, 2019 11:02:09

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 !

Samuel (poulpito)
Tuesday 1 October, 2019 14:26:23

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

Renaud GODARD (Alkaline)
Tuesday 1 October, 2019 21:47:36

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.

Bill Pye (fenice)
Thursday 3 October, 2019 13:28:11

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 ?

Bill Pye (fenice)
Thursday 3 October, 2019 14:10:38

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 ?

Damien (dough29)
Thursday 3 October, 2019 16:44:31

Je viens de remplacer mes Player par des Android TV, passé le Server en mode bridge = c'est désormais stable...

dem (dem)
Tuesday 8 October, 2019 11:41:56

J'ai souvent des pertes de connexion (fibre, bridge) quand la FireTV d'Amazon est en marche.

dem (dem)
Thursday 10 October, 2019 11:24:42

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.

Lionel Bruno (lionelb)
Thursday 10 October, 2019 11:47:31

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é !

Thiriet (sebt)
Sunday 13 October, 2019 08:40:13

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.

Thomas L. (thomaslc42)
Sunday 13 October, 2019 09:52:57

Un point à noter : quand cela se produit, l'IPv6 continue de fonctionner normalement, seul l'IPv4 est impacté.

ewok2 (ewok2)
Thursday 24 October, 2019 16:37:07

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

Samuel (poulpito)
Thursday 24 October, 2019 19:32:22

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 !

Samuel (poulpito)
Thursday 24 October, 2019 19:42:01

@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

Samuel (poulpito)
Thursday 24 October, 2019 22:29:30

@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 (ewok2)
Friday 25 October, 2019 07:50:29

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

ewok2 (ewok2)
Friday 25 October, 2019 08:02:47

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

Stéphane (captainkirk85)
Wednesday 30 October, 2019 14:35:48

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.

- (Rootax)
Thursday 21 November, 2019 12:56:00

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.

- (Rootax)
Thursday 21 November, 2019 14:30:04

Au passage, le ping fonctionne toujours depuis l'extérieur, même quand le bug est rencontré.

Chargement...