La Fibre
Datacenter et équipements réseaux => Routeurs => 
Remplacer la Bbox par un routeur => Discussion démarrée par: mirtouf le 19 décembre 2018 à 16:05:20
-
Bonjour à toutes et à tous,
certains ayant réussi à faire fonctionner leur Miami derrière un routeur perso sans utiliser le routeur fourni par Bouygues mais d'autres comme moi en FTTH, n'y arrivent pas malgré l'analyse des captures réseau.
J'ai donc créé ce tableau à compléter:
https://lite.framacalc.org/multicast_bbox-2018
pour celles et ceux qui ont essayé.
J'avoue que je suis à court d'idées pour essayer de faire fonctionner la TV de façon fiable.
Peut-être qu'en comparant avec ceux qui ont réussi, une idée lumineuse surviendra et que http://iptv.pfs.bouyguesbox.fr nous livrera ses secrets. ;D
-
Salut,
J'ai complété le doc qui tu partages.
Un partie m'intrigue et je ne comprends pas. Tu obtiens une IP privée sur le WAN ? est-ce Internet est OK avec cette IP ?
Je crois pas que BTel prépare du CGNAT mais on sait jamais.
Est-ce que avec la BBox original tu as une IP Publique ou Privée ?
Quoiqu'il en soit çà ne devrait par gêner pour recevoir la TV (publique ou privée peu importe) mais cette IP privée me semble bizarre. On dirait que tu te retrouve dans un réseau bouytel pas en exploitation...
Si ça te dérange pas, tu peux m'envoyer un export complet de ta config RouterOS, Je peux jeter un oeuil et voir si y'a pas qqch qui cloche.
Autrement question config, j'ai rien ajouté de plus que ce que j'ai posté.
bon courage
-
Salut,
je me suis peut-être mal exprimé mais quand j'ai indiqué un IP non routable après la bbox, il s'agissait de cette IP privée 10.108.238.2
traceroute lafibre.info [23:03 pts/0]
traceroute to lafibre.info (46.227.16.8), 30 hops max, 60 byte packets
1 _gateway (192.168.1.1) 0.380 ms 0.313 ms 0.407 ms
2 10.108.238.2 (10.108.238.2) 3.433 ms 4.020 ms 3.824 ms
3 1.la10.bsr02-ix2.net.bbox.fr (212.194.170.42) 3.914 ms 3.445 ms 3.849 ms
4 be11.cbr01-cro.net.bbox.fr (212.194.171.2) 12.648 ms 12.593 ms 12.683 ms
5 be5.cbr01-lyo.net.bbox.fr (212.194.171.140) 12.559 ms 18.317 ms 18.293 ms
6 la44.bsr01-lyo.net.bbox.fr (212.194.171.149) 11.098 ms 10.915 ms 10.943 ms
7 la10.bsr02-lyo.net.bbox.fr (212.194.171.19) 10.310 ms 10.527 ms 10.558 ms
8 * * *
9 lafibre.info (46.227.16.8) 11.635 ms 11.521 ms 11.498 mset quand on s'intéresse à elle:
nmap -Pn 10.108.238.2 [23:03 pts/0]
Starting Nmap 7.70 ( https://nmap.org ) at 2018-12-22 23:03 CET
Nmap scan report for 10.108.238.2
Host is up (0.0043s latency).
Not shown: 998 filtered ports
PORT STATE SERVICE
179/tcp open bgp
646/tcp closed ldp
Nmap done: 1 IP address (1 host up) scanned in 15.85 seconds
J'avoue que je ne sais pas pourquoi je me retrouve dans le même cas de figure qu'avec un abonnement câble en collecte, est-ce lié à la taille des sous-blocs utilisés pour le routage car ByTel ne veut pas gaspiller ses IP ?
Toujours est-il que ma route par défaut est celle que j'attends:
ip -4 route show
default via 176.133.x.y dev eth0.100 proto zebra
176.133.x.0/22 dev eth0.100 proto kernel scope link src 176.133.a.b
192.168.1.0/24 dev switch0 proto kernel scope link src 192.168.1.1
Concernant routerOS (avec un RB750gr3) j'ai peu travaillé dessus, ma configuration fut celle-ci:
/interface ethernet
set [ find default-name=ether1 ] advertise=10M-half,10M-full,100M-half,100M-full,1000M-half,1000M-full comment="Fibre WAN" mac-address=28:E9:FC:xx:xx:xx
/interface vlan
add interface=ether1 name=Fibre_ByTel_vl100 vlan-id=100
/ip dhcp-client option
add code=60 name=vendorid value=0x42594754454c494144
/ip dhcp-client
add dhcp-options=vendorid disabled=no interface=Fibre_ByTel_vl100
/interface bridge port
add bridge=bridge interface=ether2
add bridge=bridge interface=ether3
add bridge=bridge interface=ether4
add bridge=bridge interface=ether5
/ip address
add address=192.168.88.1/24 comment=LAN interface=bridge network=192.168.88.0
/ip pool
add name=dhcp_pool_lan ranges=192.168.88.10-192.168.88.254
/ip dhcp-server network
add address=192.168.88.0/24 dns-server=192.168.88.1 domain=bbox.lan gateway=192.168.88.1 netmask=24
/ip dhcp-server network
add address=192.168.88.250/32 dns-server=194.158.122.10,194.158.122.15 domain=bbox.lan gateway=192.168.88.1 netmask=24
/ip dhcp-server lease
add address=192.168.88.250 mac-address=D0:05:2A:xx:xx:xx server=dhcp_lan
/ip dhcp-server
add address-pool=dhcp_pool_lan disabled=no interface=bridge name=dhcp_lan
/ip dns
set allow-remote-requests=yes servers=80.67.169.12,80.67.169.40
/ip firewall address-list
add address=212.195.48.0/24 list=VODReplay
add address=212.195.244.0/24 list=VODReplay
add address=62.34.201.0/24 list=VODReplay
add address=194.158.119.0/24 list=VODReplay
add address=195.36.152.0/24 list=VODReplay
add address=192.168.88.0/24 list=MyNetwork
add address=193.251.97.0/24 list=TV
add address=89.86.97.0/24 list=TV
add address=176.165.8.0/24 list=TV
add address=89.86.96.0/24 list=TV
/ip firewall filter
add action=add-src-to-address-list address-list=Syn_Flooder address-list-timeout=1d chain=input comment="Add Syn Flood IP to the list" connection-limit=30,32 protocol=tcp tcp-flags=syn
add action=add-src-to-address-list address-list=Port_Scanner address-list-timeout=1w chain=input comment="Port Scanner Detect" protocol=tcp psd=21,3s,3,1
add action=tarpit chain=input comment="Drop to syn flood list" protocol=tcp src-address-list=Syn_Flooder
add action=tarpit chain=input comment="Drop to port scan list" protocol=tcp src-address-list=Port_Scanner
/ip firewall filter
add action=accept chain=input comment="--- Accept Established / Related" connection-state=established,related in-interface=Fibre_ByTel_vl100
add action=accept chain=input comment="--- Accept IGMP for IPTV Multicast" in-interface=Fibre_ByTel_vl100 protocol=igmp
add action=accept chain=input comment="--- Accept IP Flow for IGMP Proxy" dst-port=8202,8200 in-interface=Fibre_ByTel_vl100 protocol=udp src-address-list=TV
add action=drop chain=input comment="--- Deny All / Drop -- INPUT" src-address-list=!MyNetwork
/ip firewall filter
add action=fasttrack-connection chain=forward comment="--- FastTrack Forwarding Established / Related" connection-state=established,related
add action=accept chain=forward comment="--- Accept Established / Related" connection-state=established,related
add action=accept chain=forward comment="--- Accept IP Flow for IGMP Proxy" dst-port=8200,8202 protocol=udp src-address-list=TV
add action=accept chain=forward comment="--- Accept IP flow for VOD" dst-port=20000-30000 in-interface=Fibre_ByTel_vl100 protocol=udp src-address-list=VODReplay
add action=accept chain=forward comment="--- Accept Outgoing Client Traffic Out to Internet" out-interface=Fibre_ByTel_vl100 src-address-list=MyNetwork
add action=drop chain=forward comment="--- Deny All / Drop -- FORWARD" log=no
/ip firewall nat
add action=masquerade chain=srcnat out-interface=Fibre_ByTel_vl100 src-address-list=MyNetwork
add action=dst-nat chain=dstnat dst-port=20000-30000 in-interface=Fibre_ByTel_vl100 protocol=udp src-address-list=VODReplay to-addresses=192.168.88.250
/routing igmp-proxy
set quick-leave=yes
/routing igmp-proxy interface
add alternative-subnets=0.0.0.0/0 interface=Fibre_ByTel_vl100 upstream=yes
add alternative-subnets=0.0.0.0/0 interface=bridgePas d'IGMP snooping, je ne me suis pas plus lancé dans un débogage par manque de temps.
Est-ce que les IP sources des flux multicast répondent aux requêtes ICMP ? Ce n'est le cas de mon côté (a priori c'est voulu).
PS: j'ai rebranché mon ER-X.
-
Salut,
Voici mon traceroute :
>tracert -d lafibre.info
Détermination de l'itinéraire vers lafibre.info [46.227.16.8]
avec un maximum de 30 sauts :
1 1 ms <1 ms 3 ms 192.168.1.1
2 * * * Délai d'attente de la demande dépassé.
3 16 ms 13 ms 15 ms 212.194.171.70
4 19 ms 19 ms 14 ms 212.194.171.0
5 19 ms 22 ms 22 ms 212.194.171.140
6 20 ms 16 ms 13 ms 212.194.171.149
7 12 ms 16 ms 14 ms 212.194.171.19
8 * * * Délai d'attente de la demande dépassé.
9 23 ms 93 ms 24 ms 46.227.16.8
Itinéraire déterminé.
De mon coté le second Hop ne répond pas.
Je pense que c'est pas un problème. Ça dépend comment l'équipement de collecte Bouygues est configuré. D'ailleurs, quand un équipement est multi-interfaces, il arrive qu'il réponde au traceroute avec une IP qui ne correspond pas à l'interface entrante... J'ai déjà vu çà en MPLS.
Globalement je pense pas que c'est une problème, à partir du moment ou du récupère une IP public via DHCP, ca me semble OK.
Pour le 10.108.238.2, on dirait juste que c'est un router avec BGP + LDP.
Je vais checker ta config RouterOS.
-
Y'a rien qui me choque dans la config routerOS, ca me semble pas mal.
pour commencer à debug, je tenterai d'être moins restrictif sur les règle input et forward du flux udp de l'IPTV :
add action=accept chain=input comment="--- Accept IP Flow for IGMP Proxy" dst-port=8202,8200 in-interface=Fibre_ByTel_vl100 protocol=udp
add action=accept chain=forward comment="--- Accept IP Flow for IGMP Proxy" dst-port=8200,8202 protocol=udp
Il est possible que les sources IP changent en fonction de la région peut être pour répartir la charge des serveurs.
Aussi, mais je pense que ca n'a aucun impact, en faisant un peu de sécurité sur mon mikrotik j'ai supprimé une ligne pour la config IGMP.
Cette config est suffisante :
/routing igmp-proxy
set quick-leave=yes
/routing igmp-proxy interface
add alternative-subnets=0.0.0.0/0 interface=Fibre_ByTel_vl100 upstream=yes
add interface=bridge
bon courage
-
add action=accept chain=input comment="--- Accept IP Flow for IGMP Proxy" dst-port=8202,8200 in-interface=Fibre_ByTel_vl100 protocol=udp
add action=accept chain=forward comment="--- Accept IP Flow for IGMP Proxy" dst-port=8200,8202 protocol=udp
src-port plutôt non ?
-
Non, laisser les dst-port tels qu'ils sont je pense que les ports 8202 et 8200 sont corrects et ne changent pas. Mais enlever les "src-address-list=TV" car il est possible que d'une région à l'autre bouygues source le traffic depuis d'autres IP.
Au pire pour debugger, tu peut mettre une règle 'input all udp" et "forward all udp".
Il faudra refermer après petit à petit, pour améliorer la sécurité.
-
J'ai du mal a voir pourquoi on spécifie un port de destination et pas un port source. Je ne fais que peu de multicast, mais pour moi on matche plutôt un port source.
-
J'ai du mal a voir pourquoi on spécifie un port de destination et pas un port source. Je ne fais que peu de multicast, mais pour moi on matche plutôt un port source.
Là pour te confirmer, faudrait que je refasse un peu de log...
C'est sûr que les ports destination sont figés (8200 et 8202), mais on pourrait voir si les ports sources le sont aussi. Après le but, c'est que la règle firewall match au plus juste.
A mon avis, dès lors que la tambouille IGMP est effectuée, le flux video et audio (RTP) est un flux unicast traditionnel, qui est juste dupliqué depuis le dernier point de diffusion au plus près de l'abonné.
J'ai retrouvé des configs identiques chez Orange et chez d'autres opérateurs étrangés.
a+
-
@mirtouf
Ce serait bien que tu vois pour ajouter IGMP snooping sur ton bridge.
Ca me parait carrèment nécessaire pour le bon fonctionnement de IGMP Proxy, même si dans la théorie igmp snooping n'est là que pour éviter de flooder le bridge avec les flux multicast.
-
En vrac,
j'ai vérifié avec de la réplication de ports que:
- les ports UDP de destination sont toujours 8200 et 8202 (par exemple, IP source 89.86.97.6:49152 vers 232.0.64.206:8200)
- les ports UDP sources sont des ports élevés qui varient
- les IP sources sont bien dans les préfixes annoncés
- la bbox reçoit bien une réponse des serveurs bytel après avoir demandés ses droits (a priori OK)
J'ai en outre déjà testé une règle FW autorisant tout le trafic UDP en entrant ainsi que le forward de tout cela sans succès.
L'activation ou non de l'IGMP snooping ne change rien à la réception des flux multicast, j'ai eu quelques succès avec Fr5 et M6.
J'ai aussi activé l'UPnP.
J'ai cloné ou non l'@ MAC de la bbox sans influence notable.
La seule sonde en erreur sur ma Miami est la sonde qui indique que je ne suis pas connecté au réseau Bouygues, est-ce que cela peut influer ?
Je n'arrive vraiment pas à savoir qui bloque en premier: les droits, l'IGMP proxy ou le firewall.
-
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".
-
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.
-
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 çà.
-
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..
-
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?
-
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.
-
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.
-
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.
-
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 ?
-
Pour être plus précis, les reports sont envoyés mais sans effet sans que je n'identifie la raison.
-
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 ?
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 FORWARDles interfaces sont à adapter.
Au moins, j'ai vu les requêtes SIP. ;D
-
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.
-
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.
-
Je regarde les paquets IGMP que tu as fourni et ils sont complètement différents, je vois notamment des ports source et des ports de destination, pas de VLAN. Ils sont encapsulés ?
-
re, oui pardon j'avais pas spécifié. Mikrotik permet de streamer une capture réseau vers un PC avec le protocole TZSP stream.
donc oui du coup c encapsulé dans UDP/37008.
-
J'ai ceci en règles FW et je vois bien passer le trafic IGMP mais aucun flux UDP n'arrive sur mon interface entrante.
-
A priori, le proxy IGMP pense qu'il est tout seul et envoie des requêtes v3 alors que le réseau Bytel envoie de requêtes v2.
Reste à comprendre les raisons de ce comportement.
gartox, utilises-tu PIM ?
-
Salut,
Tes règles de la config par défaut foute le bordel je pense. Notamment la règle 4 qui à mon avis drop l'igmp entrant vers le router. On voit bien que la règle 15 a son compteur à 0 !
Je désactiverai les règles entre 1 et 10, pour y voir plus clair !
Et non pas de PIM, j'avais tenté au début quand je n'arrivait pas à faire marcher IGMP Proxy, mais en y réfléchissant c'était voué à l'échec car PIM nécessite que ce soit configuré des deux coté. Coté router à la maison et coté router de distribution coté Bouygue ce qui n'est pas le cas sauf sur leur infra backbone mais pas coté client.
-
En fait je m'étais déjà assuré que tout passe à travers un bridge.
J'ai testé avec une Debian et c'est le même problème, le proxy IGMP agit comme s'il était seul au monde et parfois ça fonctionne:
RECV Membership query from 192.168.1.1 to 232.0.31.50
RECV V2 member report from 192.168.1.2 to 232.0.31.50
Should insert group 232.0.31.50 (from: 192.168.1.2) to route table. Vif Ix : 0
Updated route entry for 232.0.31.50 on VIF #0
Joining group 232.0.31.50 upstream on IF address 176.133.29.231
joinMcGroup: 232.0.31.50 on enp0s31f6.100
Current routing table (Insert Route):
-----------------------------------------------------
#0: Dst: 239.255.3.22, Age:2, St: I, OutVifs: 0x00000001
#1: Dst: 232.0.31.50, Age:2, St: I, OutVifs: 0x00000001
#2: Src0: 89.86.97.6, Dst: 232.0.64.207, Age:1, St: A, OutVifs: 0x00000001
#3: Dst: 232.0.64.208, Age:1, St: I, OutVifs: 0x00000001
-----------------------------------------------------
About to call timeout 52 (#0)
Removing group 232.0.64.207. Died of old age.
Removed route entry for 232.0.64.207 from table.
Vif bits : 0x00000001
Setting TTL for Vif 0 to 1
Removing MFC: 89.86.97.6 -> 232.0.64.207, InpVIf: 1
Current routing table (Remove route):
-----------------------------------------------------
#0: Dst: 239.255.3.22, Age:2, St: I, OutVifs: 0x00000001
#1: Dst: 232.0.31.50, Age:2, St: I, OutVifs: 0x00000001
#2: Dst: 232.0.64.208, Age:1, St: I, OutVifs: 0x00000001
-----------------------------------------------------
RECV V2 member report from 176.133.29.231 to 232.0.31.50
The IGMP message was from myself. Ignoring.
About to call timeout 53 (#0)
Removing group 232.0.64.208. Died of old age.
Removed route entry for 232.0.64.208 from table.
Current routing table (Remove route):
-----------------------------------------------------
#0: Dst: 239.255.3.22, Age:2, St: I, OutVifs: 0x00000001
#1: Dst: 232.0.31.50, Age:2, St: I, OutVifs: 0x00000001
-----------------------------------------------------
About to call timeout 54 (#1)
RECV V2 member report from 176.133.29.231 to 232.0.31.50
The IGMP message was from myself. Ignoring.
Route activation request from 176.133.29.231 for 232.0.31.50 is from myself. Ignoring.
About to call timeout 45 (#0)
SENT Membership query from 192.168.1.1 to 224.0.0.1
Sent membership query from 192.168.1.1 to 224.0.0.1. Delay: 10
Le truc drôle est que si je bloque les paquets IGMP, cela peut fonctionner.
Chain INPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
23 3954 ACCEPT all -- enp0s31f6.100 any anywhere anywhere state RELATED,ESTABLISHED
2 120 ACCEPT tcp -- enp0s31f6.100 any anywhere anywhere tcp dpt:ssh
0 0 ACCEPT tcp -- enp0s31f6.100 any anywhere anywhere multiport dports http,https
0 0 ACCEPT icmp -- enp0s31f6.100 any anywhere anywhere
295 20102 ACCEPT all -- enx000ec6fe4cb1 any anywhere anywhere
Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
55 15866 ACCEPT all -- enp0s31f6.100 any anywhere anywhere state RELATED,ESTABLISHED
55 28197 ACCEPT all -- enx000ec6fe4cb1 any anywhere anywhere
0 0 ACCEPT igmp -- enp0s31f6.100 any anywhere anywhere
0 0 ACCEPT udp -- enp0s31f6.100 any 212.195.48.0/24 192.168.1.2 udp dpts:20000:30000
0 0 ACCEPT udp -- enp0s31f6.100 any 212.195.244.0/24 192.168.1.2 udp dpts:20000:30000
0 0 ACCEPT udp -- enp0s31f6.100 any 62.34.201.0/24 192.168.1.2 udp dpts:20000:30000
0 0 ACCEPT udp -- enp0s31f6.100 any 194.158.119.0/24 192.168.1.2 udp dpts:20000:30000
0 0 ACCEPT udp -- enp0s31f6.100 any 195.36.152.0/24 192.168.1.2 udp dpts:20000:30000
0 0 ACCEPT all -- any any 193.251.97.0/24 anywhere PKTTYPE = multicast
55190 75M ACCEPT all -- any any 89.86.97.0/24 anywhere PKTTYPE = multicast
0 0 ACCEPT all -- any any static-176-165-8-0.ftth.abo.bbox.fr/24 anywhere PKTTYPE = multicast
0 0 ACCEPT all -- any any 89.86.96.0/24 anywhere PKTTYPE = multicast
Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
306 52752 ACCEPT all -- any any anywhere anywhere
##------------------------------------------------------
## Enable Quickleave mode (Sends Leave instantly)
##------------------------------------------------------
quickleave
#defaultdown
##------------------------------------------------------
## Configuration for eth0 (Upstream Interface)
##------------------------------------------------------
phyint enp0s31f6.100 upstream ratelimit 0 threshold 1
altnet 0.0.0.0/0
##------------------------------------------------------
## Configuration for eth1 (Downstream Interface)
##------------------------------------------------------
phyint enx000ec6fe4cb1 downstream ratelimit 0 threshold 1
Quand cela fonctionne c'est 1 ou 2 chaînes et timeout au bout de 5 minutes que ce soit avec igmp proxy ou mcproxy.
L'erreur de mcproxy est assez intéressante:
ERROR: failed to get multicast route stats! Error: Cannot assign requested address errno: 99
-
Pour être précis, le problème est là:
ip mroute
(192.168.1.2,239.255.255.250) Iif: unresolved State: unresolved
(176.133.29.231,232.0.64.206) Iif: unresolved State: unresolved
-
gartox, confirmes-tu que des flux multicast sont émis par le préfixe 176.165.8.0/24 ? Il s'agit d'un bloc ByTel dédié aux abonnés.
-
A priori, l'OLT envoie des general mebership query sur 224.0.0.1 mais de façon étrange je ne reçois rien quand j'utilise un routeur tiers. Tous les autres paquets IGMP passent.
Bien évidemment, rien dans nflog...
-
cette blague...
23:24:57.374650 IP 0.0.0.0 > all-systems.mcast.net: igmp query v2
23:24:58.145961 IP plh29-h01-176-133-29-231.dsl.sta.abo.bbox.fr > 232.0.64.232: igmp v2 report 232.0.64.232
23:24:59.545937 IP plh29-h01-176-133-29-231.dsl.sta.abo.bbox.fr > 239.192.152.143: igmp v2 report 239.192.152.143
23:25:00.346953 IP plh29-h01-176-133-29-231.dsl.sta.abo.bbox.fr > 239.255.3.22: igmp v2 report 239.255.3.22
23:25:01.546956 IP plh29-h01-176-133-29-231.dsl.sta.abo.bbox.fr > 224.0.0.251: igmp v2 report 224.0.0.251
23:25:06.950954 IP plh29-h01-176-133-29-231.dsl.sta.abo.bbox.fr > 224.0.0.252: igmp v2 report 224.0.0.252
23:27:02.394776 IP 0.0.0.0 > all-systems.mcast.net: igmp query v2
23:27:03.423947 IP plh29-h01-176-133-29-231.dsl.sta.abo.bbox.fr > 239.255.3.22: igmp v2 report 239.255.3.22
23:27:06.625959 IP plh29-h01-176-133-29-231.dsl.sta.abo.bbox.fr > 224.0.0.251: igmp v2 report 224.0.0.251
23:27:08.425946 IP plh29-h01-176-133-29-231.dsl.sta.abo.bbox.fr > 239.192.152.143: igmp v2 report 239.192.152.143
23:27:09.827008 IP plh29-h01-176-133-29-231.dsl.sta.abo.bbox.fr > 224.0.0.252: igmp v2 report 224.0.0.252
23:27:10.026947 IP plh29-h01-176-133-29-231.dsl.sta.abo.bbox.fr > 232.0.64.232: igmp v2 report 232.0.64.232
23:29:07.462388 IP 0.0.0.0 > all-systems.mcast.net: igmp query v2
23:29:08.498940 IP plh29-h01-176-133-29-231.dsl.sta.abo.bbox.fr > 239.192.152.143: igmp v2 report 239.192.152.143
23:29:13.903939 IP plh29-h01-176-133-29-231.dsl.sta.abo.bbox.fr > 232.0.64.232: igmp v2 report 232.0.64.232
23:29:15.105936 IP plh29-h01-176-133-29-231.dsl.sta.abo.bbox.fr > 239.255.3.22: igmp v2 report 239.255.3.22
23:29:15.305935 IP plh29-h01-176-133-29-231.dsl.sta.abo.bbox.fr > 224.0.0.251: igmp v2 report 224.0.0.251
23:29:16.105935 IP plh29-h01-176-133-29-231.dsl.sta.abo.bbox.fr > 224.0.0.252: igmp v2 report 224.0.0.252
23:30:27.152191 IP plh29-h01-176-133-29-231.dsl.sta.abo.bbox.fr > all-routers.mcast.net: igmp leave 232.0.64.232
23:30:39.904391 IP plh29-h01-176-133-29-231.dsl.sta.abo.bbox.fr > all-routers.mcast.net: igmp leave 239.255.3.22
23:30:42.043597 IP plh29-h01-176-133-29-231.dsl.sta.abo.bbox.fr > 239.255.3.22: igmp v2 report 239.255.3.22
23:40:27.703941 IP plh29-h01-176-133-29-231.dsl.sta.abo.bbox.fr > igmp.mcast.net: igmp v3 report, 1 group record(s)
23:40:28.304010 IP plh29-h01-176-133-29-231.dsl.sta.abo.bbox.fr > igmp.mcast.net: igmp v3 report, 1 group record(s)
23:40:36.703955 IP plh29-h01-176-133-29-231.dsl.sta.abo.bbox.fr > igmp.mcast.net: igmp v3 report, 1 group record(s)
23:40:38.103922 IP plh29-h01-176-133-29-231.dsl.sta.abo.bbox.fr > igmp.mcast.net: igmp v3 report, 1 group record(s)
23:40:40.903937 IP plh29-h01-176-133-29-231.dsl.sta.abo.bbox.fr > igmp.mcast.net: igmp v3 report, 1 group record(s)
23:40:41.503930 IP plh29-h01-176-133-29-231.dsl.sta.abo.bbox.fr > igmp.mcast.net: igmp v3 report, 1 group record(s)
23:40:49.913925 IP plh29-h01-176-133-29-231.dsl.sta.abo.bbox.fr > igmp.mcast.net: igmp v3 report, 1 group record(s)
23:40:50.313926 IP plh29-h01-176-133-29-231.dsl.sta.abo.bbox.fr > igmp.mcast.net: igmp v3 report, 1 group record(s)
23:40:50.713950 IP plh29-h01-176-133-29-231.dsl.sta.abo.bbox.fr > igmp.mcast.net: igmp v3 report, 1 group record(s)
23:40:59.314922 IP plh29-h01-176-133-29-231.dsl.sta.abo.bbox.fr > igmp.mcast.net: igmp v3 report, 1 group record(s)
23:40:59.714918 IP plh29-h01-176-133-29-231.dsl.sta.abo.bbox.fr > igmp.mcast.net: igmp v3 report, 2 group record(s)
23:41:02.716916 IP plh29-h01-176-133-29-231.dsl.sta.abo.bbox.fr > igmp.mcast.net: igmp v3 report, 1 group record(s)
23:41:08.719959 IP plh29-h01-176-133-29-231.dsl.sta.abo.bbox.fr > igmp.mcast.net: igmp v3 report, 1 group record(s)
23:41:09.119937 IP plh29-h01-176-133-29-231.dsl.sta.abo.bbox.fr > igmp.mcast.net: igmp v3 report, 1 group record(s)
23:41:10.722956 IP plh29-h01-176-133-29-231.dsl.sta.abo.bbox.fr > igmp.mcast.net: igmp v3 report, 1 group record(s)
23:41:11.522938 IP plh29-h01-176-133-29-231.dsl.sta.abo.bbox.fr > igmp.mcast.net: igmp v3 report, 1 group record(s)
23:41:18.125923 IP plh29-h01-176-133-29-231.dsl.sta.abo.bbox.fr > igmp.mcast.net: igmp v3 report, 1 group record(s)
23:41:18.725956 IP plh29-h01-176-133-29-231.dsl.sta.abo.bbox.fr > igmp.mcast.net: igmp v3 report, 1 group record(s)
23:41:57.155941 IP plh29-h01-176-133-29-231.dsl.sta.abo.bbox.fr > igmp.mcast.net: igmp v3 report, 4 group record(s)
23:41:57.355920 IP plh29-h01-176-133-29-231.dsl.sta.abo.bbox.fr > igmp.mcast.net: igmp v3 report, 4 group record(s)
23:41:59.356925 IP plh29-h01-176-133-29-231.dsl.sta.abo.bbox.fr > igmp.mcast.net: igmp v3 report, 1 group record(s)
23:42:00.156943 IP plh29-h01-176-133-29-231.dsl.sta.abo.bbox.fr > igmp.mcast.net: igmp v3 report, 1 group record(s)
23:42:00.556919 IP plh29-h01-176-133-29-231.dsl.sta.abo.bbox.fr > igmp.mcast.net: igmp v3 report, 1 group record(s)
23:42:00.756913 IP plh29-h01-176-133-29-231.dsl.sta.abo.bbox.fr > igmp.mcast.net: igmp v3 report, 1 group record(s)
23:42:00.956929 IP plh29-h01-176-133-29-231.dsl.sta.abo.bbox.fr > igmp.mcast.net: igmp v3 report, 1 group record(s)
23:42:02.156920 IP plh29-h01-176-133-29-231.dsl.sta.abo.bbox.fr > igmp.mcast.net: igmp v3 report, 1 group record(s)
23:42:02.356917 IP plh29-h01-176-133-29-231.dsl.sta.abo.bbox.fr > igmp.mcast.net: igmp v3 report, 1 group record(s)
23:42:03.756916 IP plh29-h01-176-133-29-231.dsl.sta.abo.bbox.fr > igmp.mcast.net: igmp v3 report, 1 group record(s)
ça ne fonctionne plus sans raison.
-
OK, j'ai pigé le truc il faudrait utiliser pimd mais je n'arrive pas à la configurer.
En attendant, il faut lancer pimd, le tuer puis lancer igmpproxy pour récupérer les flux.
pimd.conf si quelqu'un sait le configurer.
phyint igb0.100 enable igmpv2
phyint igb1 enable igmpv2
igmp-query-interval 12
igmp-querier-timeout 42
bsr-candidate priority 5
rp-candidate time 30 priority 20
rp-address 10.108.238.2 224.0.0.0/4
spt-threshold packets 0 interval 5