Hallo Ihr Lieben,
als ich mal wieder über mein VLC Magenta TV Programme sehen wollte funktionierte der Stream nicht mehr. Hat sich etwas geändert? Alle Programme verschlüsselt? Andere Multicast Prgramm Versionen oder so?
Gruß von Stefan Harbich
Hier funktioniert noch alles.
Mehrere Netzwerkkarten (auch virtuelle) aktiv?
Die Multicaststreams der nicht grundverschlüsselten Sender funktionieren bei mir noch.
Hallo Ihr Lieben,
das müsste auch mit dem folgenden Paket "MagentaZuhause XL mit MagentaTVSmartStream2.0 funktionieren, oder?
Gruß von Stefan Harbich
Ich hatte vorher MagentaTV IPTV, bevor ich auf MagentaTV 2.0 umgestellt hatte.
Ja.
Hallo Ihr Lieben,
ich habe jetzt mit tcpdump geschaut was meine Pakete machen. Was mir komisch vorkommt ist der block Eintrag.
22:09:14.232394 IP (tos 0x0, ttl 1, id 0, offset 0, flags [DF], proto UDP (17), length 588)
192.168.30.129 > igmp.mcast.net: igmp v3 report, 2 group record(s) [gaddr 232.0.20.234 block { 87.141.215.251 }] [gaddr 232.0.20.35 allow { 87.141.215.251 }]
192.168.30.1 > 232.0.20.234: igmp query v3 [max resp time 2.0s] [gaddr 232.0.20.234 { 87.141.215.251 }]
192.168.30.1 > 232.0.20.234: igmp query v3 [max resp time 2.0s] [gaddr 232.0.20.234 { 87.141.215.251 }]
192.168.30.129 > igmp.mcast.net: igmp v3 report, 2 group record(s) [gaddr 232.0.20.234 block { 87.141.215.251 }] [gaddr 232.0.20.35 allow { 87.141.215.251 }]
192.168.30.1 > 232.0.20.234: igmp query v3 [max resp time 2.0s] [gaddr 232.0.20.234 { 87.141.215.251 }]
192.168.30.1 > 232.0.20.234: igmp query v3 [max resp time 2.0s] [gaddr 232.0.20.234 { 87.141.215.251 }]
22:09:29.002322 IP (tos 0x0, ttl 255, id 40698, offset 0, flags [DF], proto UDP (17), length 68)
192.168.30.129 > igmp.mcast.net: igmp v3 report, 2 group record(s) [gaddr 232.0.20.35 block { 87.141.215.251 }] [gaddr 232.0.20.234 allow { 87.141.215.251 }]
192.168.30.1 > 232.0.20.35: igmp query v3 [max resp time 2.0s] [gaddr 232.0.20.35 { 87.141.215.251 }]
192.168.30.1 > 232.0.20.35: igmp query v3 [max resp time 2.0s] [gaddr 232.0.20.35 { 87.141.215.251 }]
192.168.30.129 > igmp.mcast.net: igmp v3 report, 2 group record(s) [gaddr 232.0.20.35 block { 87.141.215.251 }] [gaddr 232.0.20.234 allow { 87.141.215.251 }]
192.168.30.1 > 232.0.20.35: igmp query v3 [max resp time 2.0s] [gaddr 232.0.20.35 { 87.141.215.251 }]
192.168.30.1 > 232.0.20.35: igmp query v3 [max resp time 2.0s] [gaddr 232.0.20.35 { 87.141.215.251 }]
Habt Ihr eine Idee wo ich den Fehler habe?
Gruß von Stefan Harbich
@Grinch ?
Sorry,
als Modem verwende ich ein DrayTek Vigor 167 und als Router einen OpenWRT mit mcproxy. Funktionierte eigentlich immer sehr zuverlässig. Ich kann mich daran erinnern das ich eine Umstellung von iptables auf nftables im zentralen OpenWRT Router duchgeführt habe. Ggf. habe ich da an den Firewall Einstellungen was geändert. Mal schauen wie ich die Multicast Regel rausbekomme?
Gruß von Stefan Harbich
bei den „blocks“ wird wahrscheinlich der vorherige Sender „abbestellt“, dazu müsste man jetzt wissen, wann du auf welchen Sender geschaltet hast 
Wenn du auf Nummer sicher gehen willst, dann beendest du den VLC, dann müsste der block kommen und wenn du ihn wieder startest, dürfte es nur noch den „allow“ Eintrag geben und auch keine queries an die alte Adresse.
Aber spannender wäre wahrscheinlich den tcpdump auf WAN Seite zu machen. Im LAN sieht das erstmal ganz OK aus.
Stimmt, ich hatte umgeschaltet. Ich sniffe gleich auf der WAN Seite.
Hallo,
der VLC bekommt was, nur kein Bild. Komisch. Hier der tcpdump auf der WAN Seite.
root@rome01:~# tcpdump -i eth2 -vvv multicast | grep 232
tcpdump: listening on eth2, link-type EN10MB (Ethernet), snapshot length 262144 bytes
192.168.0.2 > 232.0.20.35: igmp v2 report 232.0.20.35
192.168.0.2 > 232.0.20.35: igmp v2 report 232.0.20.35
192.168.0.2 > 232.0.20.234: igmp v2 report 232.0.20.234
192.168.0.2 > 232.0.20.234: igmp v2 report 232.0.20.234
192.168.0.2 > all-routers.mcast.net: igmp leave 232.0.20.35
192.168.0.1 > 232.0.20.35: igmp query v2 [gaddr 232.0.20.35]
192.168.0.1 > 232.0.20.35: igmp query v2 [gaddr 232.0.20.35]
192.168.0.1 > 232.0.20.35: igmp query v2 [gaddr 232.0.20.35]
192.168.0.2 > 232.0.20.35: igmp v2 report 232.0.20.35
192.168.0.2 > 232.0.20.35: igmp v2 report 232.0.20.35
192.168.0.2 > all-routers.mcast.net: igmp leave 232.0.20.234
192.168.0.1 > 232.0.20.234: igmp query v2 [gaddr 232.0.20.234]
192.168.0.1 > 232.0.20.234: igmp query v2 [gaddr 232.0.20.234]
192.168.0.1 > 232.0.20.234: igmp query v2 [gaddr 232.0.20.234]
Ich hatte zwischen ARD und ZDF gewechselt.
Hmmm… der VLC zeigt das glaub ich nur etwas komisch an. Ich mein du kannst ja im LAN gucken, ob da Pakete mit der Zieladresse rumschwirren.
Aber was mich an der WAN Seite schon mal stört ist „igmp v2“ - das sollte v3 sein. Es gibt zwar Konstellationen wo es auch mit v2 funktioniert und evtl hattest du früher eine Gegenstelle, die damit klar kam - aber eigentlich muss es v3 sein. Also das wäre die erste Stelle an der ich forschen würde, warum igmp v2 genutzt wird.
Und dann irritieren mich etwas die IP-Adressen. Hast du die geändert oder warum sind das immer noch lokale Adressen? Also die 192.168.0.2 ist dein OpenWRT, und was ist 192.168.0.1? Routet das Draytek auch noch mal, sprich nutzt du das als Router? Und kannst du dort auch noch mal auf WAN-Seite schauen?
1 „Gefällt mir“
Hallo, ich glaube ich hatte auch vor einiger Zeit mir die Firmware des OpenWRT Router neu gebaut. Ich glaube das scheint der Fehler zu sein?
root@rome01:~# cat /proc/sys/net/ipv4/conf/default/mc_forwarding
0
root@rome01:~# cat /proc/sys/net/ipv6/conf/default/mc_forwarding
0
Müsste das im Kernel nicht auf eine 1 stehen = aktivieren?
Hier die Doku über mein Netz.
SpeedPort Smart hatte ich gegen ein DrayTek Vigor 167 getauscht. Da fällt mir gerade was ein. Ich hatte an dem DrayTek Vigor 167 letzten aus dem Ausland versucht ein Firmware Update zu machen das nicht funktionierte. Ggf. da das Problem. Ich schaue gleich nach.
Dann habe ich auch den DrayTek im Verdacht. Der Speedport ist fix auf IGMPv3 eingestellt. Evtl arbeitet das DrayTek mit v2? Siehe: Welche Einstellungen sind für die IPTV-Einrichtung notwendig? - DrayTek Das muss auf „v3 only“ stehen
Im Zweifel auch mal auf dem OpenWRT v3 erzwingen
echo 3 > /proc/sys/net/ipv4/conf/eth2/force_igmp_version
Könnte man glauben. Aus der Dokumentation vom DrayTek Vigor 167 habe ich unter Netzwerk-Eigenschaften folgende Information: " * IGMP Proxy V2 / V3 (reserviert)". Ging ja auch früher. Jetzt vermute ich mein OpenWRT Router. Weil ich hier die Firmware auch neu gebaut habe und im Kernel folgnde Einstellungen für mcproxy nicht gemacht habe:
IPv6-Funktionalität
Um die IPv6-Funktionalität des mcproxy nutzen zu können, muss der Linux-Kernel IPv6 Multicast Routing unterstützen . Dies ist ein experimentelles Kernel-Feature und muss explizit aktiviert werden. Sie müssen also Ihre eigene Linux-Kernel-Variante konfigurieren und kompilieren. Im Konfigurations-Setup müssen Sie folgendes Modul auswählen:
Netzwerkunterstützung --->
Netzwerkoptionen --->
Das IPv6-Protokoll --->
IPv6: Multicast-Routing (EXPERIMENTELL)
Mehrere Routing-Tabellen
Um mehr als eine Proxy-Instanz für IPv4 und IPv6 zu verwenden, muss der Kernel mit einer zusätzlichen Kernel-Funktion konfiguriert und kompiliert werden. Im Konfigurations-Setup müssen Sie folgendes Modul auswählen:
IPv4:
Netzwerkunterstützung --->
Netzwerkoptionen --->
IP: Multicast-Richtlinienrouting
IPv6:
Netzwerkunterstützung --->
Netzwerkoptionen --->
Das IPv6-Protokoll --->
IPv6: Multicast-Richtlinienrouting
Diese Einstellungen hatte ich vor dem Bauen des Build im kernel-menuconfig vergessen zu aktivieren. Ich baue gerade das Build neu. Mal schauen ob das Problem nach dem einspielen des neuen Build dann behoben ist?
Ich glaube bei Multicast Routing bist du auf dem Holzweg. Das ist für „richtiges“ Routing in einem großen Multicast Netz mit Wegfindung per PIM und was weiss ich. Du brauchst aber nur die Proxy Funktion, die IGMP auf beiden Seiten spricht und die Pakete dann weiterleitet. IPv6 brauchst du sowieso nicht, ist ja alles noch v4.
Imho musst du erstmal schauen, dass du den Multicast in das Netz zwischen Draytek und OpenWRT bekommst. Dazu muss der Draytek im WAN IGMPv3 sprechen und der OpenWRT im LAN auch, damit die SSM Optionen durchgereicht werden können.
Übrigens mag es schon sein, dass das früher auch mit v2 funktioniert hat. Es gab mehrere Umstellungen auch im Telekom-Netz, wie Multicast verteilt wird. Seit einigen Jahren ist aber eben IGMPv3 State-of-the-Art, weil sonst das (soweit ich weiss) im Backbone eingesetzte PIM-SSM nicht richtig arbeiten kann.
Hallo Grinch,
ja das hört sich sehr logisch an. Ich werde mich beim DrayTek Support melden, fragen wie ich beim DrayTek Vigor 167 IGMP v3 only fix einstellen kann. Ich sehe da leider im Menü keine Möglichkeiten. Das was Du mir freundlicherweise gesendet hast sind Einstellungen die in den größeren Modem / Router Modellen vorgenommen werden können. Die Einstellung im OpenWRT Router:
echo 3 > /proc/sys/net/ipv4/conf/eth2/force_igmp_version
hat leider nichts bewirkt. Es läuft alles noch unter IGMP v2. Ggf. kaufe ich mir von GrayTek ein größeres Modell?
Gruß von Stefan Harbich
Hm… ja keine Ahnung was die auch mit „reserviert“ meinen 
Aber vielleicht hat der Support ja einen Tipp, wie man den mit MagentaTV zum Laufen bekommt.
Alternativ könntest du ihn vielleicht auch nur als Modem nutzen. Dann müsste der OpenWRT Einwahl und VLAN Tagging fürs WAN übernehmen.