Hallo @UlrichZ

ddann hoffen wir mal dass er was weiß! Es gab ja schon Beiträge mit vergleichbarem Setup daher denke ich dass es es nur ein Detail sein muss. 

denke zb an den vlan Tag... habe nichts besonderes dafür konfiguriert, ggf ist das die Ursache? 

zu deiner Frage : der PC ist die Firewall 😀 wollte damit sagen dass ich die volle Kontrolle drüber habe und beliebig was konfigurieren und installieren kann

Viele Grüße 

Hallo @Grinch 

Danke für die Hinweise, habe mich heute mit tcpdump vergnügt !

Also ich sehe sowhl auf eth0 (Richtung Speedport) als auch eth1 (LAN, MR ) IGMP Traffic

Hier aus der igmpproxy Output :

The IGMP message was from myself. Ignoring   <- was auch immer das bedeutet

RECV Membership query from 192.168.24.244 to 232.0.20.234  <- 244 ist die FW

RECV V2 member report from 192.168.24.232 to 232.0.20.26   <- 232 ist der MR

Inserted route table entry for 232.0.20.26 on VIF #0

joinMcGroup: 232.0.20.26 on eth0

RECV V2 member report from 192.168.24.232 to 232.0.20.26

Sieht also so aus als würde die Firewall die Pakte weitergeben

Habe auch mcproxy ausprobiert, scheint auch die These zu bestätigen :

@@##-- proxy instance myProxy (table:0,lifetime:378sec) --##@@
pinstance myProxy upstream * in rulematching first
pinstance myProxy upstream * out rulematching all
##-- simple multicast routing information base --##
group: 232.0.20.35
sources: 87.141.215.251(0sec,1x);
87.141.215.251 ==> eth0
group: 232.0.20.234
sources: 87.141.215.251(6sec);
87.141.215.251 ==> eth0
group: 239.255.255.250
sources: 192.168.24.232(4sec,181x);
192.168.24.232 ==> eth1
##-- upstream interfaces --##
eth0(index:3)

##-- downstream interface: eth1 (index:2) --##
querier version: IGMPv3
is querier: true
general query timer: 27sec
startup query count: 0
subscribed groups: 2
-- group address: 232.0.20.234
IGMPv3, INCLUDE_MODE
included list(#1): 87.141.215.251(247sec);

-- group address: 239.255.255.250
IGMPv3, EXCLUDE_MODE(163sec)
requested list(#0):
exclude_list(#0):

*aber* ich sehe auch IGMPv2 im LAN ! Soweit ich das aus anderen Quellen verstehe klappt damit IPTV nicht, müsste auch IGMPv3 sein. Auch der MR schaltet auf v2 (und damit kommt auch am MR selber die Meldung bei der Verbindungsanalyse dass v2 nicht OK sei, man möge die v2-Geräte aus dem Netz-Segment entfernen)

16:54:30.765716 IP (tos 0x60, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 32, options (RA)) 192.168.24.232 > 232.0.20.234: igmp v2 report 232.0.20.234

mcproxy Output wenn v2 da ist :

##-- downstream interface: eth1 (index:2) --##
querier version: IGMPv3
is querier: true
general query timer: 29sec
startup query count: 0
subscribed groups: 3
-- group address: 224.0.0.2                  <- das is die MCast IP
IGMPv2(258sec), EXCLUDE_MODE(258sec)
requested list(#0):
exclude_list(#0):
-- group address: 224.0.0.22
IGMPv2(259sec), EXCLUDE_MODE(259sec)
requested list(#0):
exclude_list(#0):

Lt. tcpdump habe ich viele Geräte im LAN die v2 Pakete verschicken : FritzBox, RaspberryPi mit Openelec, Netzwerkdrucker, Handys usw... aber auch meine Firewall (hostname "nas")

Lustig ist dass sie wohl mit v3 startet, dann auf v2 geht, und der MR folgt brav :

16:54:02.868057 IP (tos 0x60, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 56, options (RA)) 192.168.24.232 > igmp.mcast.net: igmp v3 report, 2 group record(s) [gaddr 232.0.20.234 allow { 87.141.215.251 }] [gaddr 232.0.20.234 to_in { 87.141.215.251 }]  <- MR noch auf v3 (oder ?)

16:54:17.582331 IP (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 48, options (RA)) nas > igmp.mcast.net: igmp v3 report, 2 group record(s) [gaddr igmp.mcast.net to_in { }] [gaddr all-routers.mcast.net to_in { }]  <- FW schickt v3 Paket

16:54:30.312727 IP (tos 0xc0, ttl 1, id 26020, offset 0, flags [none], proto IGMP (2), length 32, options (RA)) nas > all-systems.mcast.net: igmp query v2  <- FW schickt v2 Paket

16:54:30.765716 IP (tos 0x60, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 32, options (RA))192.168.24.232 > 232.0.20.234: igmp v2 report 232.0.20.234  <- MR ist nun auch v2

bin mir nicht sicher was auf der FW die Pakete erzeugt

Ganz nebenbei : mcproxy oder igmpproxy verwenden ? Was ist besser ?

Habe hier noch ein Mitschnitt wo alles anscheinend IGMPv3 war, aber das Bild trotzdem stockte. Kannst Du was damit anfangen ? Ich denke der interessante Teil ist um 16:50:07 herum (query-Paket)

16:48:07.850354 IP (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 32, options (RA))
nas > igmp.mcast.net: igmp v2 report igmp.mcast.net
16:48:28.714083 IP (tos 0x0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 36, options (RA))
nas > all-systems.mcast.net: igmp query v3
Hier startet der Receiver
16:49:20.424107 IP (tos 0x60, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 40, options (RA))
192.168.24.232 > igmp.mcast.net: igmp v3 report, 1 group record(s) [gaddr 239.255.255.250 to_ex { }]
16:49:20.649039 IP (tos 0x60, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 40, options (RA))
192.168.24.232 > igmp.mcast.net: igmp v3 report, 1 group record(s) [gaddr 239.255.255.250 to_ex { }]
16:49:56.039714 IP (tos 0x60, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 56, options (RA))
192.168.24.232 > igmp.mcast.net: igmp v3 report, 2 group record(s) [gaddr 232.0.20.234 allow { 87.141.215.251 }] [gaddr 232.0.20.234 to_in { 87.141.215.251 }]
16:49:56.471705 IP (tos 0x60, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 56, options (RA))
192.168.24.232 > igmp.mcast.net: igmp v3 report, 2 group record(s) [gaddr 232.0.20.234 allow { 87.141.215.251 }] [gaddr 232.0.20.234 to_in { 87.141.215.251 }]
16:50:06.815581 IP (tos 0x60, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 44, options (RA))
192.168.24.232 > igmp.mcast.net: igmp v3 report, 1 group record(s) [gaddr 232.0.20.234 block { 87.141.215.251 }]
16:50:06.816015 IP (tos 0x0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 40, options (RA))
nas > 232.0.20.234: igmp query v3 [max resp time 2.0s] [gaddr 232.0.20.234 { 87.141.215.251 }]
16:50:07.709551 IP (tos 0x60, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 44, options (RA))
192.168.24.232 > igmp.mcast.net: igmp v3 report, 1 group record(s) [gaddr 232.0.20.234 block { 87.141.215.251 }]
16:50:07.816304 IP (tos 0x0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 40, options (RA))
nas > 232.0.20.234: igmp query v3 [max resp time 2.0s] [gaddr 232.0.20.234 { 87.141.215.251 }]
16:50:14.169452 IP (tos 0x60, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 56, options (RA))
192.168.24.232 > igmp.mcast.net: igmp v3 report, 2 group record(s) [gaddr 232.0.20.35 allow { 87.141.215.251 }] [gaddr 232.0.20.35 to_in { 87.141.215.251 }]
16:50:15.049437 IP (tos 0x60, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 56, options (RA))
192.168.24.232 > igmp.mcast.net: igmp v3 report, 2 group record(s) [gaddr 232.0.20.35 allow { 87.141.215.251 }] [gaddr 232.0.20.35 to_in { 87.141.215.251 }]
Ab hier ist das Bild eingefroren

Und hier der Mitschnitt auf eth0, dort passiert bei 16:50:07 wenig... doch ein Firewall Problem ? :

16:47:58.410330 IP (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 48, options (RA)) [11/80]
nas > igmp.mcast.net: igmp v3 report, 2 group record(s) [gaddr all-routers.mcast.net to_ex { }] [gaddr igmp.mcast.net to_ex { }]
16:48:30.834298 IP (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 36, options (RA))
_gateway > all-systems.mcast.net: igmp query v3
16:48:37.034326 IP (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 56, options (RA))
nas > igmp.mcast.net: igmp v3 report, 3 group record(s) [gaddr all-routers.mcast.net is_ex { }] [gaddr igmp.mcast.net is_ex { }] [gaddr 224.0.0.251 is_ex { }]
16:49:20.434323 IP (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 40, options (RA)) nas > igmp.mcast.net: igmp v3 report, 1 group record(s) [gaddr 239.255.255.250 to_ex { }]
16:49:20.598328 IP (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 40, options (RA))
nas > igmp.mcast.net: igmp v3 report, 1 group record(s) [gaddr 239.255.255.250 to_ex { }]
16:49:30.827839 IP (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 36, options (RA))
_gateway > all-systems.mcast.net: igmp query v3
16:49:37.194332 IP (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 64, options (RA))
nas > igmp.mcast.net: igmp v3 report, 4 group record(s) [gaddr 239.255.255.250 is_ex { }] [gaddr all-routers.mcast.net is_ex { }] [gaddr igmp.mcast.net is_ex { }] [gaddr 224.0.0.251 is_ex { }]
16:49:56.050314 IP (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 44, options (RA))
nas > igmp.mcast.net: igmp v3 report, 1 group record(s) [gaddr 232.0.20.234 to_in { 87.141.215.251 }]
16:49:56.098340 IP (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 44, options (RA))
nas > igmp.mcast.net: igmp v3 report, 1 group record(s) [gaddr 232.0.20.234 to_in { 87.141.215.251 }]
16:50:08.826320 IP (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 44, options (RA))
nas > igmp.mcast.net: igmp v3 report, 1 group record(s) [gaddr 232.0.20.234 block { 87.141.215.251 }]
16:50:09.674315 IP (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 44, options (RA))
nas > igmp.mcast.net: igmp v3 report, 1 group record(s) [gaddr 232.0.20.234 block { 87.141.215.251 }]
16:50:14.178321 IP (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 44, options (RA))
nas > igmp.mcast.net: igmp v3 report, 1 group record(s) [gaddr 232.0.20.35 to_in { 87.141.215.251 }]

16:50:14.926332 IP (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 44, options (RA))
nas > igmp.mcast.net: igmp v3 report, 1 group record(s) [gaddr 232.0.20.35 to_in { 87.141.215.251 }]
16:50:30.819783 IP (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 36, options (RA))
_gateway > all-systems.mcast.net: igmp query v3
16:50:36.330310 IP (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 76, options (RA))
nas > igmp.mcast.net: igmp v3 report, 5 group record(s) [gaddr 232.0.20.35 is_in { 87.141.215.251 }] [gaddr 239.255.255.250 is_ex { }] [gaddr all-routers.mcast.net is_ex { }] [gaddr igmp.mcast.net is_ex { }]

Werde morgen noch ein Versuch starten und dem MR direkt am eth1 anschließen, um wirklich alles aus dem Netzwerk auszuschließen, aber wenn die Firewall selber v2 Pakete erzeugt habe ich wohl verloren.

Ich gehe davon aus dass ich meinen sonstigen Geräten das v2 nicht austreiben kann, daher klingt es für mich als sei die Situation festgefahren, der MR kann nicht im selben LAN sein und ich werde wohl schauen müssen dass ich ein extra-Kabel zum MR ziehe (1x quer durch das Haus vom Keller bis in's Wohnzimmer).

Die letzte Alternative die mir einfallen würde : den MR in ein extra Netz (zB 192.168.xx.132, xx ungleich 24) stellen. Wäre noch am selben Netzwerkinterface von der Firewall. Habe ich da ein Denkfehler und die Multicasts würden trotzdem sichtbar sein weil sie sich nciht um die IP kümmern ?

Danke & viele Grüße

Das sieht doch gar nicht sooo schlecht aus.

Aber wahrscheinlich kommen verschiedene Probleme zusammen bzw. sind dann Folgefehler. IMGPv2 ist wie du ja schon gelesen hast schlecht. Das Problem daran ist nicht nur, dass damit die SSM Option nicht übertragen werden kann, das Problem ist auch, dass die Geräte alle auf v2 runtergehen, wenn nur ein Gerät im Netz v2 spricht. Und sie bleiben sehr lange da, üblicherweise bis zum Reboot.

Möglicherweise ists sogar dein nas selbst, das die v2 Pakete schickt, denn wenn ich mir das igmpproxy Log anschaue, dann ist das offenbar noch eine Version ohne IGMPv3 Support. Die würde ich erstmal nicht mehr verwenden und dann mal alle Geräte im Netz neustarten.

Wenn du stabil IGMPv3 hast gehts weiter.

Die unteren tcpdumps sehen soweit schonmal recht vielversprechend aus. Dein NAS schickt fleissig IGMPv3 Reports und möchte die Multicastgruppe mit SSM haben. Das sollte der Speedport verstehen und den Multicast weiterleiten.

Damit wäre dann der nächste Schritt: schau doch mal mit tcpdump auf eth0, ob Pakete an die Multicast-Gruppe ankommen (also im Beispiel die 232.0.20.35 oder 232.0.20.234.

Wenn ja (und davon gehe ich momentan aus), dann hast du wahrscheinlich wirklich irgendeine Firewall Konfiguration, die verhindert, dass die Multicast Pakete ins eth1 weitergeroutet werden.

Ach so und ja, eine andere IP wird nichts bringen. Den IGMP Paketen sind die IPs mehr oder weniger egal, du hast ja trotzdem nur einen IGMP Querier im Netz und der schickt seinen v2 oder v3 query an alle Multicast-Geräte (all-systems.mcast.net), egal welche IP sie haben und auch die Reports gehen an alle (igmp.mcast.net). Wenn, dann müsstest du ein eigenes VLAN aufbauen (wenn dazwischen noch ein Switch mit VLAN Fähigkeit hängt).

Hallo,

nur um zu melden dass ich mich doch letztendlich dazu entschlossen habe (bzw heute durchgeführt), ein extra-Kabel zu ziehen. Das mit IGMP v2 vs v3 war mit zu heikel, bzw wenn das Netzwerk von v3 auf v2 geht sobald irgend ein Gerät ein v2 Request schickt, dann ist mir die Sache zu instabil

mit einer direkten Verbindung zum Speedport läuft es wie erwartet problemlos

Nochmal Danke für die Hilfe & Ratschläge