Freebox Server (Ultra V9/ Pop V8/ Delta V7 / Revolution V6 / Mini 4K)

  • État Nouveau
  • Pourcentage achevé
    0%
  • Type Autre
  • Catégorie LAN
  • Assignée à Personne
  • Système d'exploitation Freebox Server V6 (Révolution)
  • Sévérité Basse
  • Priorité Très Basse
  • Basée sur la version 4.9.14
  • Due pour la version Non décidée
  • Échéance Non décidée
  • Votes 1
  • Privée
Concerne le projet: Freebox Server (Ultra V9/ Pop V8/ Delta V7 / Revolution V6 / Mini 4K)
Ouverte par Vincentra - 01/11/2025
Dernière modification par Vincentra - 03/12/2025

FS#40620 - Jonction Server-Player impossible en passant par un switch

Bonjour,

depuis que je suis passé en “combo” Freebox Server (r2) 4.9.11.1 + Player 1.3.54 sur un ensemble Freebox Revolution, je rencontre un problème bloquant.

Je reproduis ce problème dans 2 maisons différentes, mais avec la même installation réseau.

Depuis 2017, la liaison entre mon freebox server et mon freebox player ne se fait pas directement de la sortie RJ45 du freeplug player (dans un cas, des 200mb/s dans l’autre des 500mb/s).
La sortie du freeplug côté player arrive sur un switch réseau (de grande marque réseau, non manageable), et la freebox player vient chercher son accès au freebox server depuis ce même switch réseau.
Le switch réseau permet aussi de dispenser un accès internet à TV, console Sony, lecteur de blu-ray, enregistreur LG.

(je passe par du CPL parce que server et player sont trop éloignés pour tirer un câble RJ45 difficilement intégrable dans la déco, avec passage d’étage).

Je vous mets un petit schéma de l’installation de 2017 qui a toujours été fonctionnel, jusqu’aux dernières mises à jour : https://i.postimg.cc/c1Qw8cDb/Schema-Free-Box.jpg

A présent, je suis obligé de brancher directement le RJ45 du freeplug player au player, sinon :

  • le player est route, et j’ai une à 2 icônes qui m’indiquent que la jonction au serveur est rompue
  • si je redémarre le player, en fin d’initialisation, il me dit qu’il cherche à faire l’association avec le freebox server, et bien sûr cela n’aboutit jamais.

Je ne sais pas ce qui cause ce dysfonctionnement: la mise à jour du server, du player ou la combinaison des deux ???

Le service de proximité m’a confirmé que c’est une configuration (avec un switch réseau entre le CPL et le player) qui est bien supportée et doit fonctionner.

Cela arrive chez moi et chez mes beaux-parents, les switchs réseaux sont de 2 grandes marques différentes, et bien sûr les switchs ont été redémarrés, les freeplugs désappairés et réappairés, et les câbles testés.

Dans ce contexte, le problème est donc reproductible à 2 endroits différents.

Est-il possible de le reproduire en labo de devs pour valider l’introduction de cette régression et envisager la prise en charge de sa correction dans les prochaines mises à jour s’il vous plait ?
(et peut-être d’autres utilisateurs ??)

Je reste à disposition pour de plus amples informations techniques si nécessaire (je suis très expérimenté: vous pouvez me demander des gestes avancées sans crainte).

Merci pour votre écoute

Longue Vie à Free et surtout à la “mémère” : la freebox revolution

(même si la maladie de l’afficheur du serveur me frustre un peu, mais changer la box pour que ca crame à nouveau assez rapidement… bof)

Vincent R.

PS: le soucis est identique si j’utilise les freeplugs d’origine ou des boitiers CPL 1000 de chez Netgear.
Je suis actuellement retourné sur les Freeplugs pour être dans la configuration la plus standard/origine possible

Petit complément:

j'ai un pressentiment sur une cause possible côté mise à jour du player 1.3.54 sur l'ajout de cette "fonctionnalité", mais je suis peut-être à côté de la plaque :

"Le Freebox Player requiert maintenant une connexion internet fonctionnelle pour démarrer, via une adresse IPv4 sur le LAN du Freebox Server (en plus d’une IPv4 sur le VLAN 100 qui était déjà requise). De nombreux services ne fonctionnaient déjà pas sans un accès internet, une configuration valide est maintenant attendue, pour améliorer l’expérience utilisateur en cas de problème. En pratique ce changement ne devrait pas avoir d’impact visible."

dans mon cas, le switch est un NETGEAR GS108, non manageable: il ne peut pas gérer/isoler les VLAN, mais il laisse passer les trames VLAN taggées sans les modifier, donc aucun souci possible avec le fameux VLAN 100

nbanba a commenté le 02.11.2025 17:12

Bonjour

Pour confirmer que les trames vlan 100 passent bien en plus des trames 'native vlan' vous pouvez brancher une machine sur le switch et utiliser la commande suivante (remplacer <interface> par l'interface branchée sur le switch netgear):

tcpdump -nnei <interface> -vvt 'ether proto 0x8100 and ether[14:2] & 0xfff == 100 or ether proto 0x0800 or ether proto 0x0806'

Cordialement
nbanba

nbanba a commenté le 02.11.2025 17:35

Bonjour

Ensuite il faut chercher des trames du type:

xx:xx:xx:xx:xx:xx > xx:xx:xx:xx:xx:xx, ethertype 802.1Q (0x8100), length 142: vlan 100, p 0, ethertype IPv4 (0x0800), (tos 0x0, ttl 57, id 36600, offset 0, flags [none], proto UDP (17), length 124)

Et pour capturer les trames IPv6 également il faut rajouter au filtre tcpdump:

'or ether proto 0x86dd'

Je dis ça car la dernière fois que j'ai capturé le player montait l'IPv6: 2a01:e0a:0xxx:xxxf:ffff:ffff:ffff:ffff/60

la ou ma box à pour IPv6 publique : 2a01:e0a:0xxx:xxx0::1/60
(= 2a01:e0a:0xxx:xxx0:0000:0000:0000:0001/60)

La commande complète donnerait donc:

tcpdump -nnei <interface> -vvt 'ether proto 0x8100 and ether[14:2] & 0xfff == 100 or ether proto 0x0800 or ether proto 0x0806 or ether proto 0x86dd'

Cordialement
nbanba

Bonjour nbanba

je suis quand même surpris car :

1) je n'ai rien changé à mon installation, ni physiquement ni au niveau configuration (hormis les mises à jour "obligatoires" du server et du player)

2) il s'agit de switchs L2 non manageable, qui ne fait donc que du passe-plat, sans modifier ni interpréter les trames

N'ayant pas de machine Linux sous le coude,je vais tenter de trouver un moment pour faire le test depuis Windows 11, avec powershell + TShark :

pktmon etl list
pktmon start --capture --pkt-size 0 --comp <nom_interface>
pktmon stop
pktmon pcapng PktMon.etl -o PktMon.pcapng

et enfin :

tshark -r fichier.pcapng -Y "(vlan.id == 100) or (eth.type == 0x0800) or (eth.type == 0x0806) or (eth.type == 0x86dd)" -V

Ca devrait bien être l'équivalent du tcpdump recommandé ?

Correction/erreur sur les switchs utilisés, ce ne sont pas des Netgear mais des TP-Link :

LS105G
TL-SG108

Je me renseigne en parallèle à savoir si les ports sont regroupés de force dans un VLAN 1 (et potentiellement dropperaient les autres tags VLAN, comme le VLAN 100).

Mais dans ce cas, ce sont bien les dernières mises à jour qui ont cassés cette possibilité, puisque cela a toujours marché: il aura suffit que le dernier firmware player fasse un contrôle du VLAN 100 qui n'existait pas…

J'aurais potentiellement un Netgear GS308 que je pourrais tester à la place du tp-link

Est il censé être OK celui là ??

je teste le netgear GS308 demain, en lieu et place du TL-SG108, au moins en fonctionnement CPL ⇒ switch, Player ⇒ switch, puis redémarrage player et accès à toutes les fonctions (mais si l'association avec le server est bonne, je serais déjà confiant pour le reste)

je mettrais à jour le présent case

nbanba a commenté le 03.11.2025 22:13

Bonjour

Pour répondre rapidement (pas disponible ce soir⇒ je ferais une réponse plus complète demain), déjà :
1) je ne travail pas pour Free ou le groupe Iliad, ni de près ni de loin.
2) je ne connais pas Windows
3) je n'ai que quelques notions sommaires en réseau sous Linux.
4) pour tracer le netflow sous Windows en natif, je recommande d'utiliser comme outil natif

netsh trace

5) 'tshark' version ligne de commande de Wireshark est un outil très puissant que je ne peux que recommander (aillant entre autre contribué à son développement ;) ).
Je vous recommande donc de l'utiliser en remplacement de `tcpdump` (désolé, n'etant pas utilisateur de Windows je n'ai pas le réflexe de le proposer quand tcpdump fait le job, bien que je donne un example de son usage pour spanning-tree ici : https://dev.freebox.fr/bugs/task/40468#comment191154)

Dans l'exemple du ticket cité on distingue clairement 2 types de filtres :

-f "capture_filter"
-Y "display_filter"

(filtres à adapter à votre cas d'usage)

Ensuite je fomatte les résultats pour qu'ils s'affichent à peu près sous la même forme que l'output standard de `tcpdump` avec l'invocation

-T fields

En affichant les champs suivants

-e frame.time -e eth.src -e eth.dst -e eth.type

Puis j'affiche la partie observée soit spanning-tree dans l'exemple du ticket précédemment cité (partie à adapter dans votre cas)

-e stp.bridge_id -e stp.root_id -e stp.hello_time -e stp.max_age

Donc votre commande :

tshark -r fichier.pcapng -Y "(vlan.id == 100) or (eth.type == 0x0800) or (eth.type == 0x0806) or (eth.type == 0x86dd)" -V

Semble convenir.

Cependant je rajouterai après

(vlan.id == 100)

L'ethertype 0x8100 (802.1q)

(vlan.id == 100) or (eth.type == 0x8100) or (eth.type == 0x0800) or ...

Aussi le `-V` dans la commande affichera le "wireshark tree" promu par la fonction "proto_tree_add_item()", ce qui est très complet pour une analyse multi trames (souvent trop)
Je recommande d'essayer sans puis de l'ajouter au besoin.

Mais vous devriez capturer directement avec tshark (-w file.pcap) au lieu de relire la capture réseau l'autre outil

N'hésitez pas à m'envoyer les fichiers pcap pour analyse

Je regarderai plus en détail demain…

Cordialement
nbanba

PS:
concernant les switchs, tplink en SOHO est souvent un meilleur choix que netgear (prix, robustesse, features), mais la plupart sont des switchs actifs.
Vérifiez si ces switchs sont administrables et s'ils cherchent à monter un arbre spanning-tree qui pourrait BLOCK le port du switchs recevant le freeplug au lieu de le laisser en FORWARD (déjà vécu chez moi en 2019 avec 1 delta + devialet)
La commande du message cité plus haut devrait faire l'affaire, à savoir (je la remet complète):

tshark -i <interface> \
-f "ether proto 0x0026" \
-Y "stp or stp.bpdu" \
-T fields \
-e frame.time -e eth.src -e eth.dst -e eth.type \
-e stp.bridge_id -e stp.root_id -e stp.hello_time -e stp.max_age

(/!\ live command ⇒ add '-w file.pcap' pour avoir un fichier de capture/!\)

Je regarderai plus en détail demain

Bonjour

merci nbanba pour toutes ces précisions : je les note pour une future utilisation.

Point du jour sur le sujet :

  1. le Netgear GS308 fait l'affaire, à la place du TP-Link TL-SG108

Je l'ai intercalé temporairement pour test entre le boitier CPL et le player.

   Après redémarrage du player, l'association au server s'est faite de manière
   transparente, et tous les types de streaming (enregistrement HDD, OQEE, NetFlix, Replay, TV)
   fonctionnent.
   Je vais donc intervertir mon Netgear de bureau avec le TP-Link : je n'aurais pas
   cette problématique de VLAN sur mon utilisation bureautique.
   C'est un contournement, et j'aurais complété mes connaissances.
  1. C'est bien ce nouveau contrôle (avec l'utilisation du VLAN 100) qui a généré ce dysfonctionnement.

Au delà de n'avoir aucun intérêt pratique, le commentaire développeurs sur cette mise à jour est:

     "//En pratique// ce changement ne devrait //pas //avoir //d’impact visible//."
  mais aurais dû raisonnablement être : 
     "//En théorie// ce changement ne devrait pas avoir d’impact visible, mais //en pratique//, il pourrait y //en avoir//".
  

Il faut quand même rappeler qu'une grande partie des abonnées Free, en particulier comme FAI chez les particuliers, sont des amateurs avancées de technologie, des geeks et des informaticiens.
C'est aussi ces abonnées là qui ont fait le succès et la réputation de Free.

Il ne faut pas nécessairement penser qu'une majorité possède une installation "standard", mais au contraire, intègre le box dans un environnement plus avancée que n'importe quel utilisateur lambda (non initié).

Admin
rawoul a commenté le 04.11.2025 16:22

Bonjour,

la seule différence apportée par la version 1.3.54 du Player est la contrainte que le DHCP fonctionne sur le réseau local sur le VLAN non taggé. Le comportement lié au VLAN 100 n'a pas changé. Le DHCP sur le VLAN non taggé étant à priori un usage ultra basique, je ne comprends pas trop le problème. Est-ce que le services autres que la TV et VOD (Netflix, Primevideo, YouTube, etc) qui requièrent un accès internet fonctionnaient avant cette MAJ ?

nbanba a commenté le 04.11.2025 20:43

Bonjour

@ArnaudV (@rawoul)
Afin de simplifier les debugs pour le grand public pourriez-vous SVP fournir un outil de capture de paquets natif dans la Freebox (type: tshark ou tcpdump) permettant de capturer le packet flow sur toutes les interfaces (lan, wan, wifi, LTE, vpn,…) ?

Ça aiderai beaucoup les utilisateurs de Freebox et rendrait les analyses techniques plus pertinentes

En vous remerciant d'avance
Cordialement
nbanba

Bonjour @rawoul

à votre question :

Est-ce que le services autres que la TV et VOD (Netflix, Primevideo, YouTube, etc) qui requièrent un accès internet fonctionnaient avant cette MAJ ?

Oui tout était fonctionnel avant cette mise à jour et avec le switch TP-Link.
C'est le seul changement opéré: la mise à jour du player.

J'ai refait mon installation d'origine (switch qui reçoit le CPL et distribue aux autres équipements réseaux), mais avec le NetGear à place: tout est de nouveau opérationnel.

Ce matin, au redémarrage du player, j'ai reçu une mise à jour 1.3.55.
Personne n'en parle encore: je ne sais pas ce qu'elle apporte.

Je viens de voir qu'une mise à jour server était sortie il y a 2 jours (4.9.12), elle sera faite après mon (télé)travail.

Croisons les doigts :)
Attention à nos mémères : on les adore <3

Je mets fin à la demande de "correction", le seul contournement ou point de vigilance étant d'utiliser un switch qui ne taggue pas automatiquement tous ces ports en VLAN1 (ce qui vient en conflit avec la possibilité forcée, suite mise à jour, de pouvoir faire passer du VLAN100 entre server et player).

Merci à tous pour votre participation/échange

Belle journée

Chargement...

Activer les raccourcis clavier

Liste des tâches

Détails de la tâche

Édition de la tâche