Freebox Player Pop (V8)

  • État Nouveau
  • Pourcentage achevé
    0%
  • Type Anomalie
  • Catégorie Freebox OQEE
  • Assignée à Personne
  • Système d'exploitation Tous
  • Sévérité Moyenne
  • Priorité Très Basse
  • Basée sur la version 9.6.26 - 1.0.109
  • Due pour la version Non décidée
  • Échéance Non décidée
  • Votes 1
  • Privée
Concerne le projet: Freebox Player Pop (V8)
Ouverte par xiboy - 23/05/2021

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.

xiboy a commenté le 24.05.2021 14:32

Même résultat en configuration IPv6 manuelle sur le syno

Admin
phh_f a commenté le 24.05.2021 15:49

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,

xiboy a commenté le 24.05.2021 20:22

Même résultat en configuration IPv6 manuelle sur le syno

xiboy a commenté le 24.05.2021 21:43

(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.

xiboy a commenté le 01.06.2021 09:56

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.
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 :-)), mais rien de rien.
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.

Admin
phh_f a commenté le 01.06.2021 10:06

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?

xiboy a commenté le 01.06.2021 10:19

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?

Admin
phh_f a commenté le 01.06.2021 10:30

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?

xiboy a commenté le 01.06.2021 11:42

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.

xiboy a commenté le 01.06.2021 11:43

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

fj91 a commenté le 01.06.2021 21:17

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 :

mafreebox.freebox.fr
Serveur : pfsense.local.domain
Address: 192.168.2.1

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.

fj91 a commenté le 01.06.2021 21:23

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"

xiboy a commenté le 01.06.2021 22:16

Qu'est-ce que tu as comme dns tout en haut de la page diagnostics?

fj91 a commenté le 02.06.2021 04:38

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.

SwHawk a commenté le 02.06.2021 15:36

@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…

SwHawk a commenté le 02.06.2021 17:13

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)

  • Si mon serveur DNS résout mafreebox.freebox.fr à son IPv6 publique (2a01:…) : Tentative d'établissement d'une connexion RTSP en IPv6 vers le Freebox Server, mais le server répond que le port est inaccessible :

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: 2246664304

Pas de tentative d'établissement de flux RTSP en IPv4

  • Si le serveur DNS résout mafreebox.freebox.fr à l'IPv6 lien-local (fe80::) : pas d'établissement de flux en IPv6 (plutôt logique, techniquement cette IPv6 n'est pas routable depuis le LAN, le serveur étant considéré comme WAN), mais tentative d'établissement de flux RTSP en IPv4 :
  No.     Time           Source                Destination           Protocol Length Info
  1603 60.015504      IPv4Player         IPv4Server         TCP      74     46460 → 554 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 SACK_PERM=1 TSval=4294904692 TSecr=0 WS=64
  Frame 1603: 74 bytes on wire (592 bits), 74 bytes captured (592 bits)
  Ethernet II, Src: FreeboxS_0e:d3:81 (8c:97:ea:0e:d3:81), Dst: 4a:bb:cb:6c:14:26 (4a:bb:cb:6c:14:26)
  Internet Protocol Version 4, Src: IPv4Player, Dst: IPv4Server
  Transmission Control Protocol, Src Port: 46460, Dst Port: 554, Seq: 0, Len: 0
  No.     Time           Source                Destination           Protocol Length Info
  1604 60.016055      IPv4Server         IPv4Player         TCP      74     554 → 46460 [SYN, ACK] Seq=0 Ack=1 Win=65160 Len=0 MSS=1460 SACK_PERM=1 TSval=356367710 TSecr=4294904692 WS=128
  Frame 1604: 74 bytes on wire (592 bits), 74 bytes captured (592 bits)
  Ethernet II, Src: 4a:bb:cb:6c:14:26 (4a:bb:cb:6c:14:26), Dst: FreeboxS_0e:d3:81 (8c:97:ea:0e:d3:81)
  Internet Protocol Version 4, Src: IPv4Server, Dst: IPv4Player
  Transmission Control Protocol, Src Port: 554, Dst Port: 46460, Seq: 0, Ack: 1, Len: 0
  No.     Time           Source                Destination           Protocol Length Info
  1605 60.017813      IPv4Player         IPv4Server         TCP      66     46460 → 554 [ACK] Seq=1 Ack=1 Win=87616 Len=0 TSval=4294904693 TSecr=356367710
  Frame 1605: 66 bytes on wire (528 bits), 66 bytes captured (528 bits)
  Ethernet II, Src: FreeboxS_0e:d3:81 (8c:97:ea:0e:d3:81), Dst: 4a:bb:cb:6c:14:26 (4a:bb:cb:6c:14:26)
  Internet Protocol Version 4, Src: IPv4Player, Dst: IPv4Server
  Transmission Control Protocol, Src Port: 46460, Dst Port: 554, Seq: 1, Ack: 1, Len: 0
  No.     Time           Source                Destination           Protocol Length Info
  1609 60.048834      IPv4Player         IPv4Server         RTSP     67     Continuation
  Frame 1609: 67 bytes on wire (536 bits), 67 bytes captured (536 bits)
  Ethernet II, Src: FreeboxS_0e:d3:81 (8c:97:ea:0e:d3:81), Dst: 4a:bb:cb:6c:14:26 (4a:bb:cb:6c:14:26)
  Internet Protocol Version 4, Src: IPv4Player, Dst: IPv4Server
  Transmission Control Protocol, Src Port: 46460, Dst Port: 554, Seq: 1, Ack: 1, Len: 1
  Real Time Streaming Protocol

Et quelques autres paquets qui suivent, sans finalement passer en rash dans Oqee

En espérant que cela aide à trouver des solutions…

SwHawk a commenté le 02.06.2021 17:39

PS : Je me permets de rajouter que l'IPv6 publique du serveur répond au ping depuis le LAN, au cas où.

fj91 a commenté le 02.06.2021 20:25

Merci pour l'info, ça marche effectivement mieux.
En revanche lorsque le lance un nslookup sur le serveur de la Freebox, j'obtiens ceci :

mafreebox.freebox.fr
Server: 8.8.8.8
Address: 8.8.8.8#53

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 ?

SwHawk a commenté le 02.06.2021 20:50

@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 @ns0.proxad.net in aaaa mafreebox.freebox.fr
  ; <<>> DiG 9.16.15-RH <<>> @ns0.proxad.net in aaaa mafreebox.freebox.fr
  ; (1 server found)
  ;; global options: +cmd
  ;; Got answer:
  ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12359
  ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1
  ;; WARNING: recursion requested but not available
  ;; OPT PSEUDOSECTION:
  ; EDNS: version: 0, flags:; udp: 4096
  ;; QUESTION SECTION:
  ;mafreebox.freebox.fr.		IN	AAAA
  ;; ANSWER SECTION:
  mafreebox.freebox.fr.	86400	IN	CNAME	freeplayer.freebox.fr.
  ;; AUTHORITY SECTION:
  freebox.fr.		86400	IN	SOA	ns0.proxad.net. hostmaster.proxad.net. 2020040304 21600 3600 1209600 86400
  ;; Query time: 13 msec
  ;; SERVER: 212.27.32.2#53(212.27.32.2)
  ;; WHEN: mer. juin 02 22:39:11 CEST 2021
  ;; MSG SIZE  rcvd: 135

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 :

  # dig @ns0.proxad.net in a mafreebox.freebox.fr
  ; <<>> DiG 9.16.15-RH <<>> @ns0.proxad.net in a mafreebox.freebox.fr
  ; (1 server found)
  ;; global options: +cmd
  ;; Got answer:
  ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44901
  ;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 3
  ;; WARNING: recursion requested but not available
  ;; OPT PSEUDOSECTION:
  ; EDNS: version: 0, flags:; udp: 4096
  ;; QUESTION SECTION:
  ;mafreebox.freebox.fr.		IN	A
  ;; ANSWER SECTION:
  mafreebox.freebox.fr.	86400	IN	CNAME	freeplayer.freebox.fr.
  freeplayer.freebox.fr.	86400	IN	A	212.27.XXX.XXX
  ;; AUTHORITY SECTION:
  freebox.fr.		86400	IN	NS	ns1.proxad.net.
  freebox.fr.		86400	IN	NS	ns0.proxad.net.
  ;; ADDITIONAL SECTION:
  ns0.proxad.net.		86400	IN	A	212.27.32.2
  ns1.proxad.net.		86400	IN	A	212.27.32.130
 ;; Query time: 12 msec
 ;; SERVER: 212.27.32.2#53(212.27.32.2)
 ;; WHEN: mer. juin 02 22:45:13 CEST 2021
 ;; MSG SIZE  rcvd: 168

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).

fj91 a commenté le 02.06.2021 21:08

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ù…

xiboy a commenté le 02.06.2021 21:12

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)

SwHawk a commenté le 02.06.2021 21:23

@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…


xiboy a commenté le 08.06.2021 07:47

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.

SwHawk a commenté le 08.06.2021 14:13

@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…

xiboy a commenté le 08.06.2021 18:59

Surtout qu'en mode routeur, impossible d'avoir des sous-titres non plus…

SwHawk a commenté le 20.06.2021 21:15

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.

Chargement...

Activer les raccourcis clavier

Liste des tâches

Détails de la tâche

Édition de la tâche