Bonjour le poteau a était déposé entre 2020 et 2021.

Bon, je reprends le même sujet.
Tout fonctionnait bien depuis mon dernier post...

Depuis fin début Avril, je rencontre une erreur en regardant la TV de Free. Cela ne concerne que la TV en direct.
Les replays et autres applis fonctionnent correctement.

Pour rappel, j'ai une IP Full Stack, et il n'était plus nécessaire de passer par l'ipv6 pour connecter le free player.

A l'époque, j'avais plus ou moins suivi ces tuto :
https://www.fly-the-planet.com/community/viewtopic.php?t=1003
https://www.forum-nas.fr/threads/freebox-routeur-wi-fi-les-diff%C3%A9rentes-options-maj-04-2021.12119/

L'erreur rencontré, affiché sur l'écran de la Tv, est "DASH #1014 - Erreur DNS"
J'ai essayé d'appeler Free, pour savoir si ils avaient changé quelque chose..Bon, comme j'ai un routeur perso, c'est "débrouilles-toi".
Ils m'ont dit de chercher au niveau de mon DNS...En me refilant les DNS de Google.

Je ne suis pas seul dans ce cas, il a y entre autres un sujet ici : https://lafibre.info/remplacer-freebox/erreur-dash1014-dns-depuis-mi-mars-2026-en-freebox-ultra-bridge-routeur-tiers/new/#new

Dans l'interface du GL Inet MT600/Flint2, j'ai activé l'IPV6, et j'obtiens un truc qui fonctionne en passant en Passtrough. Cette configuration n'est apparement pas idéale niveau sécurité car elle expose directement sur le web les clients connectés, et dans une configuration réseau domestique classique, le mode Native est plus recommandé. > Je suis repassé en mode Native

Du coup, j'ai ouvert l'interface utilisateur avancé, Luci, interface graphique d'OpenWrt, et j'ai essayé d'appliquer la demarche ici :
https://blog.kulakowski.fr/post/openwrt-derriere-une-freebox-ipv6-dmz-et-bridge

Mais je n'arrive pas a appliquer la demarche jusqu'au bout..Et pourtant cela fonctionne !
(La FreeTV fonctionne à nouveau, les test IPV6 sont fonctionnels.)

Pour la partie "Prise en charge de l'ipv6", c'est tout bon : J'ai récupéré l'ipv6 de l'interface, je l'ai collé dans les paramètres du Free Server.

C 'est la partie "Interfaces Wan & Wan6" et "Interface LAN" où j'ai un soucis :

 - Je fais les modifications mentionnées (interface graphique Luci)
- J'ai tapé la ligne de commande concernant l'option "préfixe IPV6 délégué personnalisé" - Je n'ai pas de message d'erreur, donc je présume que c'est ok, mais sans certitude..

MAIS, lorsque je veux appliquer les modifications, un compte à rebourd se lance, et puis un deuxieme, mentionnant que la configuration n'est pas sûr/verifié, et qu'il est revenu a l'etat initial.

Ce matin, en réouvrant Luci, les modifications en attentes ne sont plus presentes.

Si je fais le tour :

Interface WAN > Protocole : Client DHCP - OK

Interface WAN6 > OK - A verifier si "Préfixe IPV6 délégué personnalisé " est ok

Interface LAN >
Réglages généraux :
Protocole : Adresse statique - OK
Adresse IPv4 : 192.168.1.254 -> J'ai l'adresse ip de mon routeur sur mon reseau.
Masque-réseau IPv4 : 255.255.255.0 - OK
Passerelle IPv4 : vide (il va trouver) - OK
Diffusion IPv4 : vide (il va trouver) - OK

Réglages avancés :
Longueur d’attribution IPv6 : 64 (c’est le /64 de vos préfixes de délégation) > J'ai toujours 60
Indice d’affectation IPv6 : vide > J'ai 0000
Suffixe IPv6 : ::254 (pour ressembler à l’IPv4) > J'ai toujours ::1

Serveur DHCP / Paramètres IPv6 :
Service de publicité de routeur : mode serveur - OK
Service DHCPv6 : désactivé > J'ai toujours "server Mode"
Proxy NDP : désactivé - OK

Serveur DHCP / Paramètres IPv6 : (IPV6 RA)
Routeur par défaut : sur le prefixez disponible - OK
Activer SLAAC : coché - OK

Route >
Reste à rajouter une route statique depuis l’interface de LuCi.
On va router 2000::/3 vers l’adresse IPv6 du lien local que vous avez noté précédemment - OK


Si je fais un test IPV6 sur google ou autres, cela fonctionne, la TVFree fonctionne a nouveau (peut etre un plus de latence entre les changements de chaine, mais pas sûr..) mais comme je n'ai pas réussi a tout appliquer,  je me dis que ma configuration est bancale..

Et surtout je me demande pourquoi Luci/OpenRT ne m'a pas laissé faire hier..








Je colle ces liens ici, pour ref ultérieur si besoin.
https://lafibre.info/remplacer-freebox/freebox-delta-pop-mode-bridge-onpsense-freeplayer/
https://lafibre.info/remplacer-freebox/freebox-pop-ucg-ultra-configuration-ipv6-pour-player-popoqee/

Pas de la même manière mais c'est surveillé quand même, je vois bien des pertes depuis une machine externe -> IPv6 livebox WAN.

Si tu lis bien, c'est pas exactement ce test qu'on demande. 

Si la livebox est le problème, c'est chaud car j'ai eu Livebox 6 et 7 avec le même problème alors...

Orange est incompétent donc rien n'est impossible 

Surtout quand j'apporte par A+B des preuves de l'inverse, et sans me déranger.

Honnêtement, je dis pas que c'est ton LAN, je dis pas que c'est IPv6, etc... Mais tu as prouvé quoi au juste ? Que tu as un problème ?
Car à moins que tu ais fait pléthores de tests, que tu ne détailles pas, tu as juste prouvé avec des ping en ethernet et en wifi que de temps en temps qu'ils ne marchent plus vers internet.
Tu n'as pas prouvé que ça venait de la livebox. Tu n'as pas prouvé que ça venait de la ligne. Tu n'as pas prouvé que ça vient du NRO. En gros tu n'as rien prouvé, tu as juste constaté un problème.

Donc justement, malgré que ce soit surement vrai à 99%, tu n'as pas dédouané ton LAN.

Et aussi, si on retire tous les clients & usages derrière la box, il n'y a plus de soucis en effet car il n'y a plus d'utilisation

Donc il y a un correlation avec ton traffic LAN ? Si ton LAN ne fait plus rien plus de coupure ? Ou c'est ce que tu imagines ?
Certaines livebox ont des limites de connexions simultané, toi qui a un usage pro ou semi pro, tu atteins peut être cette limite (et ça pourrait faire planter la livebox) Surtout si tu as un gros LAN de pro... Ca serait un cas où la cause est ton LAN par exemple.

Je veux pas te prendre de haut, je sais que tu es un pro etc... Mais tu vas surement un peu vite en besogne. C'est chiant de faire des tests dont on est convaincu qu'ils auront aucune incidence, mais je pense que tu devrais les faire.

A priori tu as demontré par A+B que c'est le NRO ou le réseau, donc changer de livebox ne changerait rien (pourtant ça a fonctionné 6 mois).
Ou alors tu as démontré par A+B que c'est la livebox, dans ce cas la la changer devrait resoudre le problème (ou au moins avec un routeur perso).

Selon une IA, ce problème proviendrait de Docker en mode pont et de la combinaison choisie. Elle recommande de se passer de Docker pour le DHCP ou de configurer
Docker avec Macvlan/Ipvlan. À vérifier, je ne suis pas compétent dans le domaine.

Tu cumules :

• virtualisation réseau (Proxmox)
• virtualisation OS (VM)
• virtualisation réseau Docker

👉 Donc :

chaque couche déforme un peu plus le paquet DHCP

Et à la fin :

• paquet mal formé
• ou réponse jamais reçue

On remarque que cette configuration est bien plus complexe que celle annoncée (figurant) dans le dépôt GitHub du projet.

Le responsable du projet nftables n'a pas non plus réussi à reproduire un bogue potentiel qui serait lié à la virtualisation (testé avec QEMU).

L'IA indique également que Docker gère du réseau, mais n’est pas conçu pour remplacer un routeur (mauvaise isolation).