FS#34909 - [OQEE] Plus de sous-titres si derrière un syno rt1900
Bonjour,
J'ai connecté mon player POP derrière un routeur synology rt1900, lui-même en DMZ sur la delta (donc pas de mode bridge).
Le syno est configuré en IPv6 relay, et très bien, les flux TV fonctionnent sur OQEE (la POP a bien une IPv6).
Seulement je viens de me rendre compte aujourd'hui que je n'ai plus de sous-titres sur aucune des chaînes. Par là j'entends que je ne peux plus choisir de STT, OQEE ne propose que 'Aucun'.
Si je repasse sur le wifi de la delta, et après un reboot de la pop, j'ai de nouveau la possibilité de choisir des sous-titres (pas sur toutes les chaînes, mais c'est une autre histoire 
).
Je sèche, l'adressage IPv6 semble bien fonctionner puisque les flux TV sont là, mais comment sont gérés les STT alors?? Qu'est-ce qui peut bloquer?
Merci pour votre aide.
Chargement...
Activer les raccourcis clavier
- Alt + ⇧ Shift + l Se connecter/Se déconnecter
- Alt + ⇧ Shift + a Ouvrir une tâche
- Alt + ⇧ Shift + m Mes recherches
- Alt + ⇧ Shift + t Rechercher par ID de tâche
Liste des tâches
- o Ouvrir la tâche sélectionnée
- j Déplacer le curseur vers le bas
- k Déplacer le curseur vers le haut
Détails de la tâche
- n Tâche suivante
- p Tâche précédente
- Alt + ⇧ Shift + e ↵ Enter Modifier cette tâche
- Alt + ⇧ Shift + w Surveiller
- Alt + ⇧ Shift + y Fermer cette tâche
Édition de la tâche
- Alt + ⇧ Shift + s Enregistrer la tâche
Même résultat en configuration IPv6 manuelle sur le syno
Bonjour,
C'est un peu compliqué, y a différents problèmes qui s'entre-mèlent. Mais pour faire simple, quelle est votre configuration IPv4 sur le Syno? J'imagine que l'IPv4 est NATée. Passez en IPv4 bridgée sur le Syno, et je pense que ça devrait marcher. À défaut, utilisez le serveur DNS de la Freebox (j'imagine que le Syno n'utilise pas le DNS de la Freebox).
Je tente une explication probable de votre problème: Les sous-titres ne sont, actuellement, disponibles qu'en RASH (RTSP utilisé sur la Pop exclusivement pour le live), et non en DASH ("bête" http, utilisé pour le live et le start-over/timeshift). Le RASH passe par mafreebox.freebox.fr, mais le nom mafreebox.freebox.fr n'est résolvable en IPv6 que par le serveur DNS intégré à la Freebox (d'où ma suggestion d'utiliser le DNS de la Freebox). Autrement, ce n'est accessible que en IPv4. Auquel cas, on tombe dans un problème du RTSP utilisé par le RASH, qui est que ça passe mal les NAT (d'où ma suggestion de passer en bridge).
D'autre part, ce problème doit aussi se manifester par le fait que le temps de zap est assez long (3s), est-ce que vous confirmez?
Cordialement,
Même résultat en configuration IPv6 manuelle sur le syno
(désolé pour le double post)
Merci pour cette réponse détaillée.
J'avoue ne pas saisir comment se passer du NAT dans ma configuration actuelle (freebox en mode routeur + syno en DMZ). Forcément quand je désactive le NAT, je n'ai plus d'accès au delà de mon LAN, logique, mais je ne vois pas comment faire autrement. J'ai loupé quelque chose?
Sinon pour les DNS, je me suis aidé de l'outil de diagnostic de la POP, et effectivement une erreur me disait que le server n'était pas résolvable en ipv6.
J'ai modifié la conf du syno pour envoyer en IPv4 et en IPv6 la delta comme serveur DNS.
L'outil de diagnostic est tout content maintenant, mais pas OQEE: toujours aucun choix de STT, et je confirme que le zapping est lent (3s effectivement).
J'ai loupé quelque chose? ou la conf DNS ne suffit pas?
Cordialement.
Après de multiples tentatives, même si le diagnostics sur la POP était tout vert (notamment sur la résolution IPv6 du server), impossible d'avoir les sous-titres sur les flux live.
), mais rien de rien.
Je vois bien des flux RTSP passés entre la POP et le serveur en faisant un tcpdump sur le syno (j'ai bien aimé le UserAgent
Et cela fonctionne dès que je suis en direct sur la delta.
Donc pour le moment, j'ai arrêté le syno, mais c'est bien dommage car sa fonctionnalité de contrôle parental (et notamment de filtrage web absent de la delta) me manque.
Cordialement.
Bonjour,
Vous voyez le flux RTSP, et il reste ouvert? De ma compréhension, Oqee va essayer de l'ouvrir, mais ne recevra jamais aucune donnée. Et il l'ouvre en IPv4 ou en IPv6?
Oui je viens de regarder un peu mieux la capture, effectivement la pop envoie des paquets en IPv4 vers mafreebox.freebox.fr, mais rien en retour.
Une idée de ce qui peut bloquer?
Est-ce que vous pouvez vérifier la résolution DNS de mafreebox.freebox.fr depuis un ordinateur derrière le Syno? Est-ce que cette résolution donne l'IPv6?
Faut que je remette en route le syno, je fais ça ce soir.
Par contre, connecté sur la delta, depuis un poste linux, j'obtiens une résolution en ipv4:
# ping mafreebox.freebox.fr
PING mafreebox.freebox.fr (212.27.38.253) 56(84) bytes of data.
Pardon je n'ai rien dit (un peu bête de tester avec un pingv4):
# nslookup
> mafreebox.freebox.fr
Server: 127.0.0.53
Address: 127.0.0.53#53
Non-authoritative answer:
Name: mafreebox.freebox.fr
Address: 212.27.38.253
Name: mafreebox.freebox.fr
Address: fd0f:ee:b0::1
Bonsoir,
Je me joins à la conversation pour un problème similaire (voir post https://dev.freebox.fr/bugs/task/33990).
J'avais répondu un peu vite en ne faisant pas suffisamment cas de l'analyse de Pierre-Hugues (toutes mes excuses).
En y regardant de plus près, lors d'un changement de chaîne, le player tente bien une connexion rash avant de basculer en dash au bout de 2 à 3s.
Côté config, j'ai bien déclaré les DNS free en IPV4 et IPV6 dans mon pfsense.
Les chaînes sont toutes accessibles malgré la latence.
De même, un test sur https://test-ipv6.com/ me donne un résultat positif
En revanche, la résolution DNS de mafreebox.freebox.fr ne semble pas fonctionner :
Réponse ne faisant pas autorité :
Nom : freeplayer.freebox.fr
Address: 212.27.38.253
Aliases: mafreebox.freebox.fr
Je suis donc preneur de toute idée.
En complément, je viens de lancer un diagnostic sur la pop(j'avais oublié de le faire avant mon post…) : "Pas d'ipv6 trouvé pour freebox server"
Qu'est-ce que tu as comme dns tout en haut de la page diagnostics?
J'ai 2 DNS :
IPV4 : 192.168.4.1 qui correspond à un de mes lan sur pfsense sur lequel est connecté un player.
IPV6 : le préfixe du subnet déclaré sur la Freebox pour le même lan.
Ce qui m'amène à penser que ça ne pourra pas marcher comme je le souhaite puisque j'ai 2 player à connecter, chacun sur un lan différent.
@fj91, dans l'interface de pfSense, vous devez avoir un onglet Resolveur DNS (voire Unbound DNS), dans lequel vous devez pouvoir configurer des contournements d'hôtes. Il vous suffit alors d'ajouter l'hôte mafreebox.freebox.fr avec son adresse IPv6 afin que le player POP puisse résoudre l'IPv6 à partir du pfSense.
Personnellement, ça ne suffit pas à avoir les flux RTSP (rash) qui passent, c'est pourquoi j'aimerais avoir un peu plus de détail sur les configurations (m)DNS à implémenter pour que l'on puisse avoir accès aux sous-titres, voire d'autres configurations supplémentaires.
Pour la question du deuxième LAN, je ne suis pas sûr que ça pose un problème…
Désolé pour le double post, mais au final je me permets de donner les résultats de mes derniers tests, malheureusement infructueux:
Pour information, j'ai un serveur DNS que je peux configurer pour donner des contournements d'hôtes (named avec rpz policy pour information)
Copie du tcpdump analysé par Wireshark
1010 23.721133 IPv6Player IPv6Server TCP 94 43476 → 554 [SYN] Seq=0 Win=65535 Len=0 MSS=1440 SACK_PERM=1 TSval=4294904075 TSecr=0 WS=64 1011 23.721736 IPv6Server IPv6Player ICMPv6 142 Destination Unreachable (Port unreachable) Internet Control Message Protocol v6 Type: Destination Unreachable (1) Code: 4 (Port unreachable) Checksum: 0x8fc7 [correct] [Checksum Status: Good] Reserved: 00000000 Internet Protocol Version 6, Src: IPv6Player, Dst: IPv6Server Transmission Control Protocol, Src Port: 43476, Dst Port: 554, Seq: 2246664304Pas de tentative d'établissement de flux RTSP en IPv4
Et quelques autres paquets qui suivent, sans finalement passer en rash dans Oqee
En espérant que cela aide à trouver des solutions…
PS : Je me permets de rajouter que l'IPv6 publique du serveur répond au ping depuis le LAN, au cas où.
Merci pour l'info, ça marche effectivement mieux.
En revanche lorsque le lance un nslookup sur le serveur de la Freebox, j'obtiens ceci :
Non-authoritative answer:
mafreebox.freebox.fr canonical name = freeplayer.freebox.fr.
Name: freeplayer.freebox.fr
J'avoue ne pas bien comprendre si je compare avec le résultat obtenu par xiboy
Une explication ?
@fj91, votre pfSense est configuré pour forwarder les requêtes DNS vers les serveurs DNS de Google (8.8.8.8) ?
En tous cas c'est une réponse qui est corroborée par les requêtes DNS qu'on peut effectuer même sur les DNS de Free :
dig étant un utilitaire un peu plus complet que nslookup ou host, la commande effectuant une requête sur le serveur ns0.proxad.net, autoritaire sur le domaine freebox.fr, pour obtenir l'IPv6 (in aaaa) associée au nom d'hôte mafreebox.freebox.fr
En version pour obtenir l'IPv4 (in a), on obtient ça :
Après, la comparaison est difficile. En fait, je pense que les DNS de Free utilisent l'adresse IP du client effectuant la requête pour donner l'IPv4 (et normalement l'IPv6) associée à mafreebox.freebox.fr. Par contre, avec la requête que vous effectuez, c'est techniquement le serveur de Google qui fait la requête sur le serveur de Free, et donc l'IP n'est pas retournée puisque le serveur de Google n'est pas identifié par Free comme étant associé à un abonnée (étonnamment).
Je me doutais de la question mais je n'ai pas configuré de forward dans pfsense et les DNS de la Freebox sont ceux par défaut.
Je vais revérifier encore une fois juste au cas où…
Question toute bête : ne pourrait-il pas s'agir d'un port bloqué par le firewall de nos routeurs entre le serveur et le player?
J'ai plutôt l'impression que c'est le player qui initie la connexion, mais bon on ne sait jamais… (Je ne peux pas tester présentement car j'ai tout remis derrière la delta)
@xiboy : en ce qui me concerne, j'ai pu ouvrir le port 554, que ce soit en IPv4 ou en IPv6, donc quand je vois le "Port Unreachable" en IPv6, j'ai du mal à croire que ça vienne du firewall, accessoirement dans un sens ou dans l'autre (Player vers Server 554 et Server 554 vers Player)…
D'après ce que disait Pierre-Hugues pour l'IPv4, il y a effectivement d'autres ports à ouvrir dans un FW (de ce que je comprends par «problèmes de NAT»), mais le fait que niveau IPv6 la connexion soit refusée par le serveur, c'est quand même problématique, à moins que le service n'écoute que sur l'adresse lien-local (fe80::), ce que j'ai du mal à vérifier… Mais bon une fois que le Freebox Server est en bridge (ce qui est quand même mon cas depuis le début… j'ai essuyé quelques pots cassés d'ailleurs ^^), c'est quand même étrange que le proxy RTSP n'écoute que sur l'adresse lien-local, ça voudrait dire qu'il faut obligatoirement relier le player en filaire au server…
Pour répondre à la question de Pierre-Hugues plus haut, je viens de refaire le test et j'ai bien une résolution en IPv6 de mafreebox.freebox.fr (en forçant le DNS de la freebox dans la conf du serveur DHCP du syno), mais pas de sous-titres.
@pierre-Hugues : Pour ce qui est du DNS de la Freebox, celui ne fonctionne qu'en mode routeur, une fois passé en bridge, pas moyen d'y avoir accès et donc de résoudre une IPv6 de mafreebox.freebox.fr. Par ailleurs, en mode bridge, l'adresse fd0f:ee:b0::1 est inaccessible (tâche pourtant ouverte il y a plusieurs années : https://dev.freebox.fr/bugs/task/21048, sur laquelle je viens de faire un petit up).
Elle est bien accessible en mode routeur, mais bon un double NAT, juste pour le plaisir d'avoir les sous-titres… C'est un peu dommage…
Surtout qu'en mode routeur, impossible d'avoir des sous-titres non plus…
Serait-il possible d'avoir un retour concernant les problèmes évoqués dans ce rapport ? Ce serait agréable de pouvoir disposer des sous-titres, ne serait-ce qu'en direct…
C'est beau de voir vos différents tests, si ça peut vraiment faire résoudre le problème que ce soit en mode routeur ou bridge.