Auteur Sujet: [Appel à contribution] Vos succès et échecs pour récupérer les flux multicast (Lu 6799 fois)

mirtouf · « **Réponse #12 le:** 29 décembre 2018 à 19:18:28 »

Je m'y connais assez peu en multicast mais je viens de constater que le port de destination pour une même chaîne peut changer (alternance 8200, 8202).
En outre les ports sources sont : 49152 et 8200
Les ports de destination sont 1234, 8200 ou 8202

Je pense qu'une règle firewall basée sur un port de destination est une mauvaise idée, je vais plutôt regarder du côté des ports source.

gartox · « **Réponse #13 le:** 30 décembre 2018 à 17:33:08 »

J'avais pas vu de ports dest en udp/1234, je vais l'ajouter dans ma config au besoin.

Par contre, je viens de me rendre compte d'une étape que je n'avais pas expliqué dans le poste d'origine.
Es tu sûr que ton IGMP Proxy est bien actif ? est-ce que tu as bien installé le package multicast ? car il n'est pas installé par défaut.

> télécharger le zip "extra packages" du site mikrotik correspondant à ton hardware et ta version de routeros
> copier multicast.ppk sur la flash du router
> redémarrer
> repasser les blocs de config pour l'IGMP proxy

Si tu vois le menu IGMP-Proxy dans la web interface, alors c'est qu il est déjà là.

Pour le debug, je ne vois pas d'autre solution que de tester des flux avec :
1) la règle deny all input + log => voir ce qui est bloqué
2) la règle deny all forward + log => voir ce qui est blogué

essayer de voir avec les outils router "packet sniffer" et "Torch" pour essayer d'identifier +/- à quel niveau ca ne passe pas.

Pour info, moi aussi il me dit que la box TV n'est pas connectée à une box Internet Bouygues.
A l'occasion, je regarderai pour trouver comment il détecte çà.

mirtouf · « **Réponse #14 le:** 30 décembre 2018 à 19:24:13 »

Pour l'IGMP proxy, s'il n'est pas installé, les commandes retournent une erreur mais il était bien installé et actif.
J'avais déjà utilisé torch pour voir ce qui bloque ainsi que pfsense sur un miniPC et je ne voyais rien de plus que des requêtes IGMP et des flux UDP à destination de 224.0.0.0/4 mais pour les flux UDP seul Fr5 et M6 fonctionnent par intermittence.

En répliquant le port, j'ai vu des requêtes curl de la Miami sur l'IP 192.168.1.254 pour récupérer des informations techniques.

Je vais aussi essayer avec un PC sous Debian Buster pour voir ce qui cloche, enfin si j'arrive à comprendre où cela cloche..

mattmatt73 · « **Réponse #15 le:** 30 décembre 2018 à 21:59:31 »

Citation de: mirtouf le 29 décembre 2018 à 14:02:24

Je reste bloqué sur "ça marche sur Fr5 ou M6 quelques minutes avant un freeze et un changement de chaîne permet de relancer le flux".

Le quelques minutes est fixe à chaque fois?

mirtouf · « **Réponse #16 le:** 30 décembre 2018 à 22:56:22 »

Il me semble, c'est pourquoi je soupçonne un problème sur le proxy IGMP ou sur les droits.

Avec pfsense, j'ai ça en images et pourtant si j'ouvre les ports, cela semble passer mais rien n'arrive.

mattmatt73 · « **Réponse #17 le:** 30 décembre 2018 à 23:02:56 »

Citation de: mirtouf le 30 décembre 2018 à 22:56:22

Il me semble, c'est pourquoi je soupçonne un problème sur le proxy IGMP ou sur les droits.

Je ne sais plus comment s'appel en multicast le fait de renouveller l'abonnement au flux périodiquement, sinon coupure du flux.

mirtouf · « **Réponse #18 le:** 30 décembre 2018 à 23:40:56 »

Oui, normalement le router èmet à intervalles réguliers (a priori 5 minutes chez ByTel) un membership query à destination de 224.0.0.1 pour continuer à recevoir le flux.
Sans que je sache pourquoi, cela ne fonctionne pas avec mon setup: le router envoie une requête à 224.0.0.1 dans le LAN mais rien sur le WAN.

mattmatt73 · « **Réponse #19 le:** 31 décembre 2018 à 00:09:54 »

Citation de: mirtouf le 30 décembre 2018 à 23:40:56

Oui, normalement le router èmet à intervalles réguliers (a priori 5 minutes chez ByTel) un membership query à destination de 224.0.0.1 pour continuer à recevoir le flux.
Sans que je sache pourquoi, cela ne fonctionne pas avec mon setup: le router envoie une requête à 224.0.0.1 dans le LAN mais rien sur le WAN.

Donc en l'état ça paraît logique que ça coupe au bout d'un temps prédéfini ?

mirtouf · « **Réponse #20 le:** 31 décembre 2018 à 00:25:23 »

Pour être plus précis, les reports sont envoyés mais sans effet sans que je n'identifie la raison.

mirtouf · « **Réponse #21 le:** 01 janvier 2019 à 20:53:58 »

J'ai testé avec un bridge sous GNU/Linux et j'ai le même souci de désinscription toutes les 5 minutes.

gartox, peux-tu me dire si avec un bridge, tu as les mêmes symptômes que moi ?

Code: [Sélectionner]

sudo modprobe bridge
sudo brctl addbr br0
sudo brctl addif br0 enp30s0
sudo brctl addif br0 enp42s0
sudo ip link set enp30s0 up
sudo ip link set enp42s0 up
sudo ip link set br0 up
sudo sysctl -w net.ipv4.ip_forward=1
sudo iptables -P FORWARD ACCEPT
sudo iptables -F FORWARD

les interfaces sont à adapter.

Au moins, j'ai vu les requêtes SIP.

gartox · « **Réponse #22 le:** 02 janvier 2019 à 19:07:39 »

Salut,

J'ai pas de machine à dispo pour faire un bridge linux.
J'ai fait une capture wireshark depuis le mikrotik. j'ai juste filtré igmp pour bien voir les échanges de message entre LAN et WAN. Capture en PJ, format Wireshark.

On voit bien les "group membership report" de la boxTV qui passe. C'est trappé par le proxy, ensuite le proxy réèmet des "group membership report" en décalé sur les adresses multicast correspondantes.
Le rôle du proxy IGMP est bien de gérer IGMP en lieu et place des client du LAN pour le WAN. Donc c'est normal que les requête IGMP du WAN ne soient pas envoyé sitôt après celles du LAN.

C'est plutot étrange que le proxy igmp sur ta machine ne réèmette rien coté WAN. Tu peux essayer de mettre une règle du genre "output igmp allow" au moins pour compter les packets. Ce qui est bizarre c'est que tu arrive quand même à t'abonner à une chaine, donc c'est que çà passe un minimum...

Aussi voir si tu peux forcer IGMPv2 sur les autres plateforme que mikrotik, car je sais que ce n'est pas possible sur mikrotik il est sensé le faire tout seul. Mais, j'ai vu çà comme paramètre nécessaire sur d'autre plateforme.

mirtouf · « **Réponse #23 le:** 02 janvier 2019 à 21:59:05 »

Mon problème est que :
- que ce soit côté LAN ou WAN les rapports sont envoyés et dans pas mal de cas, aucun flux n'est envoyé
- j'ai les mêmes soucis de flux qui n'arrivent pas en créant un bridge entre la bbox et l'ONT malgré l'envoi de requêtes IGMPv2 et ce de façon aléatoire (un coup ça marche, un coup ça marche pas, etc.)
alors si même avec un bridge j'ai des problèmes, il faut que je comprenne pourquoi d'abord.

J'ai bridgé pour voir vraiment ce qu'il sort de la bbox et j'ai vu passer:
- les requêtes ARP des équipements ByTel
- des requêtes PPP (wtf ?) qui sont peut-être un début de réponse (ou pas)
- plein de requêtes (curl ?) de la bbox vers les sites des principaux AS opérés par des GAFA, des transitaires ou des GIX
- que le réseau est IPv6 ready
- que acs.bouyguesbox.fr gèrer le TR-069 chez ByTel (Miami et modem)
- que Bytel est resté sur du pur SIP
- que spideo est bien le prestataire utilisé par ByTel pour sa VOD
- et accessoirement que les chinoiseries sont trop bavardes

J'ai comparé un paquet IGMP avec un flux qui n'arrive pas et un paquet IGMP avec un flux qui arrive at bien entendu, aucune différence.