Merci pour toutes ces infos, je glane à droite et à gauche pour effectivement faire communiquer ce foutu player pop comme il se devrait.
Je rame depuis plusieurs jours MAIS lorsque je force le dns sur windows (adresse ipv6 de ucg) je peux bien ping6er mafreebox.freebox.fr, en revanche lorsque je récupère le dns par l'ucg, ben ça me marche plus. Pourtant c'est bien la même adresse !!! troublant !

Hello Kero

Est-ce que ta config permet d'avoir canal plus sur le player pop?

J'ai fait une configuration différente de toi pour la partie WAN, mais identique pour le LAN et j'ai bien de l'ipV6 sur les éléments du réseau et notamment le player pop. Cependant quand je vais sur canal +, j'ai toujours cette pu... d'erreur RASH.

Le truc que je n'ai pas tester est ta modif sur la partie DNS.

Je n’ai pas Canal plus. En tout cas pas que je sache.

Re

Bon j'ai fait le test avec le DNS décrit par Kero:

Pour la partie DNS
Dans Settings -> Policy Table -> Create New Policy -> j’ai créé une entrée DNS
Type: Host (AAAA)
Domain Name: mafreebox.freebox.fr
IP Address: 2a01:***:***:***0::1

Cela a resolu mon souci de server freebox non accessible sur le player pop (plus aucune erreur sur l'outil de diagnostic).

Par contre cela ne resoud pas le souci d'accès à canal +.... je passe de l'erreur "RASH2" à l'erreur "Erreur Player #4001" (flux indisponible).... Je ne la connaissais pas encore cette erreur.

Il y a donc une evolution mais ce n'est pas encore ça ;-)

Bonjour à tous,

Je me permet de répondre car j'ai rencontré moi aussi un problème de lag après avoir passé la box en mode bridge, j'ai réussi à résoudre le problème donc si ça peut servir...

Voici ma config :

Box : Freebox POP en mode bridge
Firewall/Routeur : Appliance OPNsense hardware (6x2,5G)
AP : TP-Link OMADA EAP650
DNS/DNCP : Technitium

Le player est connecté en WiFi sur l'AP, l'AP est connecté sur une interface de mon firewall, la Freebox est sur l'interface WAN.

---

Dans la config IPv6 de la box, j'ai renseigné dans chaque Next-Hop secondaire l'adresse link-local (fe80::...) de l'interface WAN de mon firewall pour chaque préfixe /64 utilisé derrière le routeur (un par VLAN que j'utilise). C'est ce qui permet à la Freebox de router le trafic retour vers les clients. Sans ça, les paquets IPv6 retour sont droppés silencieusement par la Freebox. C'est déjà bien expliqué plus haut.

J'ai un enregistrement AAAA dans mon DNS interne (Technitium) qui fait pointer mafreebox.freebox.fr vers la GUA de la box (2a01:___::1). En mode bridge, la box n'est plus accessible via son adresse ULA (fd0f:ee:b0::1) - cette adresse est injoignable une fois le mode bridge activé

Pour ceux qui sont sur OPNsense : j'ai déclaré une gateway IPv6 dans System > Gateways pointant vers l'adresse link-local de la Freebox (fe80::...) sur l'interface WAN, et je l'ai définie comme gateway par défaut IPv6. Sans cette étape, OPNsense n'a pas de route par défaut IPv6 et tout le trafic IPv6 vers Internet est droppé localement.

Analyse du lag
Avant l'ajout de l'entrée DNS : latence de +/- 10 secondes. Après l'ajout : +/- 3/4 secondes. J'ai fait des captures Wireshark pour éliminer le délai restant. Voici la séquence exacte observée :

• Le player envoie une requête DNS AAAA pour mafreebox.freebox.fr afin d'obtenir l'adresse IPv6 de la box - c'est l'étape d'authentification réseau Free
• Le player tente une connexion TCP vers la box sur le port RTSP 554 - c'est un vestige du protocole historique Free TV (les chaînes étaient autrefois distribuées en multicast IPTV directement depuis la box). En mode bridge, la box ne sert plus de contenu vidéo et ne répond pas sur ce port en IPv6
• ~1 seconde plus tard, pas de réponse : le player envoie une retransmission TCP
• ~2 secondes plus tard : le firewall renvoie un ICMPv6 "Destination Unreachable" signalant que la connexion RTSP est impossible
• Le player abandonne la tentative RTSP et enchaîne sur les connexions OQEE
• Requêtes DNS sur license.oqee.net et api.oqee.net - le player obtient des enregistrements A et AAAA pour ces serveurs
• Connexion HTTPS vers api.oqee.net (2a01:e0f:1:9000::67) - récupération du manifeste de la chaîne et du token d'accès
• Requête DNS sur time.akamai.com - synchronisation horaire, nécessaire pour la validation des tokens DRM et la synchronisation des flux live
• Le player initie le streaming vers 2a01:e00:0:ffff::f5 - une adresse Anycast du réseau CDN Free/Proxad (2a01:e00::/32). Certains segments transitent également par Akamai (2a02:26f0::/32), un CDN tiers utilisé par Free pour la distribution de contenu. Le player n'obtient pas cette adresse via DNS - c'est le serveur api.oqee.net qui la fournit dans la réponse du manifeste (HLS/DASH). Le trafic est routé vers le point de présence Free le plus proche
• La vidéo est lancée

Le fix final
Le délai résiduel de 3-4 secondes vient des étapes 2-4 : le player attend la réponse RTSP qui ne viendra jamais. La solution est d'ajouter une règle Reject (pas Block) sur le firewall pour le port 554 vers la box :

Reject | IPv6 | TCP | LAN net IPv6 | IP_GUA_Freebox | port 554

La distinction Block vs Reject est capitale : Block droppe le paquet silencieusement et le player attend le timeout TCP complet (~3 secondes). Reject envoie immédiatement un TCP RST, le player comprend instantanément que ce port n'est pas disponible et passe à l'étape suivante en quelques millisecondes.

Résultat : le lag restant disparaît complètement

Voilà, si comme moi certains observent toujours des lags même avoir fait une entrée DNS pour mafreebox.freebox.fr, j'espère que ce pourra servir.

Bonne journée