Attention, il faut toujours séparer les câbles électriques (EDF) des autres (télécom et fibre dans une moindre mesure) !

Sur la carte des antennes Free en panne, au moins un groupe de 4 antennes étaient signalées en panne (ou maintenance) sur l'Ouest de Rennes, avec une antenne sur Saint Jacques de la Lande. La durée de la "panne" (ou maintenance) est indiquée jusqu'au 16 Septembre (Par précaution j'espère!). J'ai du monde qui bosse à Rennes, là!

Code: [Sélectionner]

    Option: (77) User Class Information
        Length: 42
        User Class Data (Text): +FSVDSL_livebox.Internet.sagem.LiveboxPro3
   


Peux-tu reesayer avec la valeur de Livebox 7 (au lieu de LiveboxPro3) ?

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

Et avec tous cela tu as accès à canal + live ?
Merci pour ta réponse car j'ai pas envi de tout casser ma config si ça ne fonctionne pas.