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

Merci, j'ai visiblement toujours le même message...

J'ai tenté un restart du client DHCP (via l'iHM disable / enable IPv6) et via la CLI (pas mieux qu'un pkill du process ...) et un reboot sans succès

bah si y a pas de DHCPRELEASE envoyé ça résout rien  C'est pas "sans état" le DHCP.

Après y a l'erreur persistante de conflg. Le DUID est ok ? (ca remplace la MAC du DHCPv4)

Cette commision est une fumisterie qui coute de l'argent pour rien, vu la façon dont elle conduite.

Cette commission est une véritable réussite.

Le rapporteur tient son rôle avec brio, en mettant en évidence l'entre-soi et la gabegie, la dilapidation d'argent public au bénéfice de quelques uns.

Bonjour,

tu as bien une IPv4 qui est dédiée. Je ne vois pas où tu vois que tu es en CGNAT ou en partage de port.

es tu sur d'avoir bien ouvert les ports dans le parefeu vers IPv4?
Possible d'avoir un screenshot ?

As tu bien mis ta PS5, sur une IP Fixe (192.168.1.XX) avec XX au choix ?
possible d'avoir un screenshot aussi ?

Naguy aussi a été pas mal.

Cette commision est une fumisterie qui coute de l'argent pour rien, vu la façon dont elle conduite.