PfSense 2.3 mit Telekom Entertain
-
@kdk:
PS: Es gibt jemandem, bei dem läuft das neue angeblich mit der pfsense (2.2.6), ist derjenige der den Vlan Bug eingestellt hat.
Hab mich mit ihm auch schon ausgetauscht und die Konfig verglichen, weiß aber nicht warum es bei ihm geht.Ich kenne auch diesen "jemand" ;) Läuft tatsächlich. 8)
Wobei das Problem mit 2.3 (noch) nicht IGMPv3 ist, sondern, dass der igmmproxy das Upstream VLAN Interface als solches nicht erkennt und dann schon direkt beim Setup anhält.
Ein Test mit dem Entertain 2.0-Receiver und 2.3 also gar nicht erst möglich.Erstaunlicherweise funktioniert aber Entertain 2.0 bereits mit den "alten" igmpproxy (auf 2.2.6).
Die einzige Einschränkung, gilt aber für altes wie neues Entertain, ist schnelles vor UND zurück zappen.
Beim Wegschalten sendet der Receiver ein Leave und beim zurückschalten einen Join.
Wenn der zetiliche Abstand zwischen diesen beiden Requests zu kurz ist, bringt das den igmpproxy scheinbar durcheinander…Dann braucht rund es 20-30 Sekunden bis der igmpproxy diesen Stream wieder abonnieren kann.
-
Ich habe jetzt mal die Quellen des igmpproxy durchgesehen. Die wesentliche Änderung für IGMPv3 betrifft die Analyse der membership reports (Typ 0x22). Diese sieht man ganz gut in den Änderungen des users schickst.
Ein IGMPv3 membership report beinhaltet eine Liste von group records. Diese beinhalten wiederum jeweils eine Multicast-Adresse sowie eine Liste von sources. Im group record steht für die Multicast-Adresse zudem drin, ob es ein join oder ein leave sein soll. In IGMPv3 kann ein host also mit einem einzigen membership report z.B. einer Gruppe beitreten sowie eine andere verlassen.
Die Anpassung interpretiert lediglich je group record den Typ (leave, join, etc.) sowie im Fall eines leave noch die Abwesenheit von sources in den group records. Hier sieht man das:
switch (grec->grec_type) { case IGMPV3_MODE_IS_INCLUDE: case IGMPV3_CHANGE_TO_INCLUDE: if (nsrcs == 0) { acceptLeaveMessage(src, group); break; } /* else fall through */ case IGMPV3_MODE_IS_EXCLUDE: case IGMPV3_CHANGE_TO_EXCLUDE: case IGMPV3_ALLOW_NEW_SOURCES: acceptGroupReport(src, group); break;Die Auswertung der sources sowie konsequenterweise deren Weitergabe in einem durch den igmpproxy erzeugten membership report ist im code nicht vorhanden: Die Aufrufe acceptLeaveMessage(src, group) und acceptGroupReport(src, group) beinhalten nur die Quelladresse des Host, der den membership report erzeugt hat (src), sowie die Multicast-Gruppe (group). Dieser code ist der einzige, der die group records überhaupt ausliest. Die konkreten Einträge der sources aus den Records sind in den Datenstrukturen abgebildet, werden aber nie ausgelesen. Damit können diese auch gar nicht in den membership reports des igmpproxy verwendet werden.
Also wenn mich nicht alles täuscht, dann ist mit dieser Version des igmpproxy ein source specific multicast nicht möglich!
-
Erstaunlicherweise funktioniert aber Entertain 2.0 bereits mit den "alten" igmpproxy (auf 2.2.6).
Ach.
Dann ist die ganze Diskussion über source specific multicast ja vermutlich obsolet. ;D
Ich habe zwar noch pfSense 2.2.6, aber ich werde Entertain 2.0 nicht ordern. (Soweit ich verstanden habe, kann ich das nur mit einem MediaReceiver nutzen. Ich verwende aber gar keinen MR mehr und einen neuen will ich schon gar nicht anschaffen.) Daher kann ich das also nicht testen.
-
Nun das wäre blöd.
Ich hab jetzt mal ein paar Traces gemacht. Leider geht jetzt das alte Entertain nicht mehr…..abgeschaltet.......sch... ade eigentlich.
Mit dem Speedport funzt es einwandfrei.
Mit dem neu kompillierten igmpproxy sind auch die RECV unk. weg, dafür meint er sehr oft:
igmpproxy 88706 The IGMP message was local multicast. Ignoring.
Die Meldung ist neu.
Mit dem neu kompillierten igmpproxy ging ja das alte Entertain gar nicht, der neue Receiver verhält sich aber gleich, kurz läuft es dann stockt es........
Erklärung zu den Traces:
wo Vlan8 steht ist das WAN VLAN8 getracet
ohne direkt am Mediareceiver
orig = original igmpproxy von pfsense
neu = der neue igmpproxy
Neustart= Receiver mal neugestartet
Speedport DSL = Trace vom Speedport WAN/DSL -
Erstaunlicherweise funktioniert aber Entertain 2.0 bereits mit den "alten" igmpproxy (auf 2.2.6).
Ach.
Dann ist die ganze Diskussion über source specific multicast ja vermutlich obsolet. ;D
Ich habe zwar noch pfSense 2.2.6, aber ich werde Entertain 2.0 nicht ordern. (Soweit ich verstanden habe, kann ich das nur mit einem MediaReceiver nutzen. Ich verwende aber gar keinen MR mehr und einen neuen will ich schon gar nicht anschaffen.) Daher kann ich das also nicht testen.
Ich glaube nicht dass das SSM damit obsolet ist. Wir wissen leider nicht warum es bei Victor läuft und bei mir nicht. Ich habe ja auf 2.3 geupdatet bzw. dann neu aufgesetzt weil es bei mir auch mit 2.2.6 nicht lief.
Naja ich vermute mal du benötigst dann nur die neuen Mutlicastadressen der Sender….....
-
@kdk:
Mit dem neu kompillierten igmpproxy sind auch die RECV unk. weg, dafür meint er sehr oft:
igmpproxy 88706 The IGMP message was local multicast. Ignoring.
Die Meldung ist neu.
Das habe ich in der Versionshistorie auch gesehen. Das ist ein Patch zur Unterdrückung von UPnP. Sollte also gut sein.
-
@kdk:
Mit dem neu kompillierten igmpproxy sind auch die RECV unk. weg, dafür meint er sehr oft:
igmpproxy 88706 The IGMP message was local multicast. Ignoring.
Die Meldung ist neu.
Das habe ich in der Versionshistorie auch gesehen. Das ist ein Patch zur Unterdrückung von UPnP. Sollte also gut sein.
Kannst du auch rausfinden wie/warum der igmpproxy im Upstream auf denigmp im Kernel zugreift und im Downstream nicht??
-
@kdk:
Mit dem neu kompillierten igmpproxy ging ja das alte Entertain gar nicht, der neue Receiver verhält sich aber gleich, kurz läuft es dann stockt es….....
Erklärung zu den Traces:
wo Vlan8 steht ist das WAN VLAN8 getracet
ohne direkt am Mediareceiver
orig = original igmpproxy von pfsense
neu = der neue igmpproxy
Neustart= Receiver mal neugestartet
Speedport DSL = Trace vom Speedport WAN/DSLWas mir auffällt: Bei den beiden Files mit dem neuen igmpproxy sind nur IGMPv2 Pakete enthalten, beim File mit dem originalen igmpproxy sind IGMPv3 Pakete drin. Ist es möglich, daß Du das versehentlich vertauscht hast?
Witzigerweise versendet der MR IGMPv2 Pakete, wenn der Router auch IGMPv2 spricht. Das könnte darauf hindeuten, daß sie der MR an die Fähigkeiten des Routers anpaßt.
Die membership reports sind inklusive source, z.B.:
4 33.862781525 192.168.99.102 224.0.0.22 IGMPv3 60 Membership Report / Group 232.0.10.120, new source {87.141.215.251}Ich nehme an, 192.168.99.102 ist der MR?
Auf der WAN-Seite sehe ich mit dem neuen igmpproxy ebenfalls IGMPv3 membership reports, z.B.:
1 0.000000000 10.237.146.195 224.0.0.22 IGMPv3 62 Membership Report / Join group 239.2.0.252 for any sources / Join group 233.89.188.1 for any sourcesHier sieht man, daß keine sources ("any") angegeben sind. Das deckt sich mit dem, was ich aus dem Code herausgelesen habe.
Also das Problem dürfte nicht daran liegen, daß keine IGMPv3 Pakete versendet werden. Die Frage ist einfach, ob der Telekom-Server eine source-Angabe zwingend voraussetzt …
-
Das mit einem IGMPv3 in LAN habe ich auch gesehen, war nach dem Einschalten der MR400.
Da der igmpproxy keine igmpv3 im LAN sprechen kann müssen alle im LAN auf igmpv2 runterschalten.
-> wenn du den proxy stoppst und dann mit vlc oder dem MR was anschauen willst, senden die igmpv3 !!
Also ich würde mal behaupten der TelekomServer ignoriert igmpv3 Paket ohne angabe der Source.
Wie gesagt weiß ich nicht warum es bei Victor läuft.
Der Speedport verhält sich ja igmpv3 konform, und da geht es ja.
-
@kdk:
Kannst du auch rausfinden wie/warum der igmpproxy im Upstream auf denigmp im Kernel zugreift und im Downstream nicht??
Nee, sorry. Ich habe jetzt eine Weile durchgeschaut, aber ich finde im Code einfach nicht heraus, wo überhaupt IGMP-Nachrichten im Upstream versendet werden. :(
Da muß ich mir mal etwas mehr Zeit nehmen.
-
Na dann werde ich wohl oder übel mal Debian mit dem mcproxy testen müssen.
https://mcproxy.realmv6.org/trac/
-
@kdk:
Kannst du auch rausfinden wie/warum der igmpproxy im Upstream auf denigmp im Kernel zugreift und im Downstream nicht??
Nee, sorry. Ich habe jetzt eine Weile durchgeschaut, aber ich finde im Code einfach nicht heraus, wo überhaupt IGMP-Nachrichten im Upstream versendet werden. :(
Da muß ich mir mal etwas mehr Zeit nehmen.
Geht doch. 8)
Der igmpproxy hat eine Routine zum Versenden von Queries: In igmc.c in der Funktion sendIgmp() wird buildIgmp() aufgerufen, hier wird struct igmp *igmp; von <netinet igmp.h="">referenziert. Das beinhaltet nicht die IGMPv3-Erweiterungen. Aus <netinet igmp.h="">(FreeBSD):
/* 52 * IGMPv1/v2 query and host report format. 53 */ 54 struct igmp { 55 u_char igmp_type; /* version & type of IGMP message */ 56 u_char igmp_code; /* subtype for routing msgs */ 57 u_short igmp_cksum; /* IP-style checksum */ 58 struct in_addr igmp_group; /* group address being reported */ 59 }; /* (zero for queries) */ 60 61 /* 62 * IGMP v3 query format. 63 */ 64 struct igmpv3 { 65 u_char igmp_type; /* version & type of IGMP message */ 66 u_char igmp_code; /* subtype for routing msgs */ 67 u_short igmp_cksum; /* IP-style checksum */ 68 struct in_addr igmp_group; /* group address being reported */ 69 /* (zero for queries) */ 70 u_char igmp_misc; /* reserved/suppress/robustness */ 71 u_char igmp_qqi; /* querier's query interval */ 72 u_short igmp_numsrc; /* number of sources */ 73 /*struct in_addr igmp_sources[1];*/ /* source addresses */ 74 };sendIgmp() wird im igmpproxy ausschließlich verwendet von sendGeneralMembershipQuery() und sendGroupSpecificMemberQuery() in request.c. Soweit ich das verstehe, werden diese ausschließlich auf LAN-Seite versendet.
Die Nachrichten im Upstream generiert das OS selbst, wenn ein Interface über die routine setsockopt() zu einer Multicast-Gruppe hinzugefügt wird. Hier hängt es von der Konfiguration ab, welche IGMP-Version das OS verwendet.
Das Ganze ist schon aus dem aktuellen Branch. Die IGMPv3-Erweiterung ändert daran also nichts.
Meine Beobachtungen erklärt das noch nicht ganz: Ich sehe nämlich im Trace auch IGMPv3 membership queries. Diese dürften dann vom OS erzeugt worden sein.
Eine mögliche Verbesserung wäre, wenn der igmpproxy seine membership queries sowohl mit IGMPv3 als auch mit IGMPv2 erzeugt, wobei die IGMPv3-Version zuerst versendet werden sollte. Ein Host, der zwischen IGMPv3 und IGMPv2 auswählt, würde sich dann für IGMPv3 entscheiden. Noch einfacher wäre, einfach nur IGMPv3 membership query Pakete zu versenden. Diese haben den gleichen Typ, nur eben ein paar Felder mehr. Laut RFC müßten unbekannte Felder m.W. ignoriert werden. D.h. ein korrekt implementierter IGMPv2-Client würde in diesem Fall auch das IGMPv3 membership query Paket verstehen.</netinet></netinet>
-
@kdk:
Na dann werde ich wohl oder übel mal Debian mit dem mcproxy testen müssen.
https://mcproxy.realmv6.org/trac/
Da gibt es eine lesenswerte Bachelorarbeit dazu.
Kann das Ding denn source specific multicast? In der Arbeit steht das nämlich im Ausblick noch als Todo. Und ich habe keine Doku gefunden, wo das so richtig drinsteht.
Hilft das für pfSense, wenn es unter Linux läuft? Die Implementierung für OS X und FreeBSD stand in der Arbeit auch noch als offen drin …
-
Naja, für mich stellt sich das so dar, wenn jemand schreibt der proxy beherscht igmpv3, dann bitte ganz, SSM dazugehört.
-
Ich habe mal im source des mcproxy nach dem SSM geschaut und es sind zumindest die Routinen drin (Version 1.1.1 des mcproxy, im File mc_socket.cpp), die dem OS die entsprechenden sources als Filter übergeben. Sieht also so aus, als wäre das SSM implementiert!
In der Doku steht drin, daß das unter Linux läuft. Zumindest stellenweise sind in den includes auch linux-spezifische Dateien eingebunden. Ob sich das unter FreeBSD überhaupt bauen läßt, ist also unsicher. Da ich aber nicht gerade viel Routine in C und C++ habe, halte ich mich aus entsprechenden Versuchen raus. Das führt zu nichts. ;D
-
Hi flo,
danke dass du mal nachgeschaut hast. Werde jetzt mal ein Debian oder OpenWRT (da gibt es wohl Sourcen vom mcproxy) testen. Das wird aber etwas dauern, da ich mir zuerst passende Hardware mit mind. 2x NIC bestellen muss.
Hoffentlich nimmt sich jemand der sich mit Programmierung auskennt dem ganzen mal an, sonst wird die pfsense für mich untauglich aussortiert, obwohl sie das beste WebGUI von allen freien Firewalls hat. Die Linux basierten IPCOp und IPFire sind von der WebGUI lange nicht so gut.
-
Die neuen Multicast Adressen sind aus diesem Bereich (RFC4607):
 -
-
Hallo flo,
habe jetzt mal versucht den mcproxy auf Ubuntu zu kompilieren, das geht aber er läuft nicht, sondern bricht mit Fehler ab. IPCop und IPFire habe ich mir mal angeschaut, aber dort ein Package zu erstellen ist mir zu schwierig, da ich leider nicht programmieren kann.
Teeconnector hat jetzt alle Patches mal zusammengetragen und ich hoffe es wird da eine Lösung geben. Er selbst kann sich leider nicht weiter darum kümmern.
Ich für meinen Teil habe jetzt eine Überganslösung gefunden: ich habe eine Bridge zwischen Interface vlan8 und dem Mediareceiver Interface eingerichtet und den igmpporxy Dienst ausgeschaltet. Dann funktioniert es auch mit dem neuen Entertain und mann kann auch schön im Trace die igmpv3 Meldungen mit SSM sehen.
Das wird allerdings nur solange funnktionieren bis mein Anschluß auf BNG umgeschaltet wird. Dann läuft nämlich alles nur noch über vlan7. Und es ist mir ein bischen unsicher.
Btw: dass der Unicast weiterläuft wenn auf Multicast umgeschaltet werden soll ist anders als beim alten Entertain, wo dann der TV Stream einfach aufgehört hat. Aber es wird ja wie berichtet nur mit ca. 1MBit/s gesendet was im Endefekt zum Abbruch durch den Receiver führt.
Die Source die angegeben wird scheint zumindest bei mir immer die gleiche zu sein die den Multicast versendet.(87.141.215.251)Gruß,
Klaus -
Schade. Ich hoffe, daß sich jemand des igmpproxy mal annimmt für SSM.
@kdk:
Ich für meinen Teil habe jetzt eine Überganslösung gefunden: ich habe eine Bridge zwischen Interface vlan8 und dem Mediareceiver Interface eingerichtet und den igmpporxy Dienst ausgeschaltet. Dann funktioniert es auch mit dem neuen Entertain und mann kann auch schön im Trace die igmpv3 Meldungen mit SSM sehen.
Das wird allerdings nur solange funnktionieren bis mein Anschluß auf BNG umgeschaltet wird. Dann läuft nämlich alles nur noch über vlan7. Und es ist mir ein bischen unsicher.
Sehe ich auch so. Und diese Umstellung hast Du ja nicht in der Hand. Ich bin auf BNG schon umgestellt worden mit meiner Migration auf VDSL100. Hat mir nur leider keiner vorher gesagt. Plötzlich kein IPTV auf VLAN8 mehr. :o Hat ein bißchen gebraucht, bis ich einen an der Strippe hatte, der mir gesagt hat, daß das Absicht war und wie es richtig funktioniert. Wenn man das dann weiß, kein Problem. :)
@kdk:
Btw: dass der Unicast weiterläuft wenn auf Multicast umgeschaltet werden soll ist anders als beim alten Entertain, wo dann der TV Stream einfach aufgehört hat.
Ich habe da mal recherchiert. Offenbar gibt es mit dem neuen Entertain ("EntertainTV") tatsächlich diverse Sender, die überhaupt nur per Unicast ausgestrahlt werden, also gar nicht per Multicast verfügbar sind. Das sind wohl wenig frequentierte Sender, aber dennoch fand ich das überraschend. Für Konsumenten ist das soweit wurscht, wenn man nicht gerade mehrere Empfänger im eigenen Netzwerk hat.
-flo-
