PfSense 2.3 mit Telekom Entertain



  • Hallo Zusammen,

    betreibt jemand bereits erfolgreich pfSense 2.3 zusammen mit Telekom Entertain?

    Hintergrund der Frage: Soweit ich diesen Forum-Eintrag verstehe, dürfte das nicht funktionieren:

    https://forum.pfsense.org/index.php?topic=109767.msg613212#msg613212

    Grund sei, daß der igmpproxy in der Version 2.3 nicht mit VLAN-Interfaces umgehen kann. Der Eintrag referenziert einen Bug-Eintrag https://redmine.pfsense.org/issues/6099 mit näheren Erläuterungen.

    Kann das jemand widerlegen oder bestätigen?

    Falls das tatsächlich so sein sollte, dann ist für Entertain-User ein Update auf 2.3 wohl nicht empfehlenswert. In Version 2.3.1 sollte das dann gehen (der Bug 6099 ist mit Zielversion 2.3.1 getaggt).

    -flo-



  • Bei mir funktioniert der igmpproxy nicht in 2.3.



  • Wir werden uns wohl noch gedulden müssen. Der Bug ist heute in die Zielversion 2.3.2 geschoben worden.  >:(



  • Sehr schade. Das dürfte darauf hindeuten, daß die 2.3.1 kurz bevorsteht. Außerdem scheint der Fix für #6099 eine größere Sache zu sein. Hoffen wir, daß das keine längere Hängepartie wird …



  • Bei mir läuft Entertain mit 2.3. Das Problem bezieht sich wohl auf die Vlan-fähigkeit des igmpproxy im Downstream, sonst hätte es noch nie laufen dürfen. Ich benutzt aber intern kein VLAN an der pfsense für Entertain. Habe ein Jetwayboard mit 4 Ethernetinterfacen.

    -> nur bei dem jetzt kommenden Entertain 2.0 (ab2.5.16) geht es nicht mehr, da dort zwingend igmpv3 nötig ist -und im Downstream kann der igmpproxy das nicht. Warum auch immer.



  • Ja, das Problem bezieht sich auf VLANs. Mit 2.3 ist IPTV wohl dann möglich, wenn kein VLAN verwendet wird. Auf der LAN-Seite hat man das selbst in der Hand.

    Aber der Bug bezieht sich auch auf die WAN-Seite! Da kommt es darauf an, wie IPTV angeliefert wird. Sofern die Trennung von VLAN8 und VLAN7 in der pfSense erfolgen muß, dann dürfte es schwierig sein. Wie ist bei Dir die WAN-Seite konfiguriert?

    Welche Infos hast Du genau zu Entertain 2.0 / EntertainTV und igmpv3? Gibt es Quellen?



  • Naja, man könnte natürlich mit einem gemanageten Switch vor der pfSense die VLANs vom trunk nehmen und auf separaten Interfaces untagged in die pfSense befördern.
    Im Zweifelsfall sind dazu auch "nur" 3 Ports eines größeren Switches nötig, die man durch das VLAN Un-/Tagging vom Rest abtrennt

    Aber schön ist anders, da gebe ich schon vorsorglich jedem Recht, der sich beschweren will.  ;D



  • @jahonix:

    Naja, man könnte natürlich mit einem gemanageten Switch vor der pfSense die VLANs vom trunk nehmen und auf separaten Interfaces untagged in die pfSense befördern.
    Im Zweifelsfall sind dazu auch "nur" 3 Ports eines größeren Switches nötig, die man durch das VLAN Un-/Tagging vom Rest abtrennt

    Aber schön ist anders, da gebe ich schon vorsorglich jedem Recht, der sich beschweren will.  ;D

    Nicht schön, aber müßte funktionieren. Das braucht zwei Ports in der pfSense. Die gleiche Lösung geht umgekehrt auch LAN-seitig, sofern man da wirklich mehrere VLANs braucht / haben will.

    Ein anderer Workaround: Ich habe hier VDSL100, da kommt alles von der Telekom in einem VLAN, nicht mehr getrennt in 2 VLANs. Hier besteht auch die Möglichkeit die VLAN-Tags schon vom Modem entfernen zu lassen. Ein Vigor130 kann das z.B. und soweit ich weiß machen Speedports im Bridge-Modus das auch so.



  • @-flo-:

    Aber der Bug bezieht sich auch auf die WAN-Seite! Da kommt es darauf an, wie IPTV angeliefert wird. Sofern die Trennung von VLAN8 und VLAN7 in der pfSense erfolgen muß, dann dürfte es schwierig sein.

    Der Bugreport wurde aktualisiert von Stefan. Der hat mir seine Conf geschickt. Er hat dort sehr wohl im WAN Bereich zwei VLANs aufgesetzt und bei ihm geht der igmpProxy.

    Da er die gleiche Konfig hat wie ich, werde ich es wohl mit einem Update versuchen.

    Wo steht, dass die Telekom igmp v3 beim Entertain 2.0 verwendet?
    Das Thema ist doch alt:
    http://www.schirmer-online.de/2009/06/t-home-entertain-multicast-und-igmp-v3/
    Warum sollte es ab dem 2.5.2016 nicht mehr gehen, wenn doch der aktuellle igmpProxy funktioniert???



  • @power_matz:

    Der Bugreport wurde aktualisiert von Stefan. Der hat mir seine Conf geschickt. Er hat dort sehr wohl im WAN Bereich zwei VLANs aufgesetzt und bei ihm geht der igmpProxy.

    Hab's gerade nachgelesen, das ist prima. Ihr habt da auf der LAN-Seite jedoch jeweils physische Interfaces konfiguriert. Es wäre jetzt noch interessant zu verifizieren, ob der Fehler auf der LAN-Seite überhaupt besteht. Wenn nicht, dann ist der ganze Bug obsolet.

    @power_matz:

    Wo steht, dass die Telekom igmp v3 beim Entertain 2.0 verwendet?
    Das Thema ist doch alt:
    http://www.schirmer-online.de/2009/06/t-home-entertain-multicast-und-igmp-v3/
    Warum sollte es ab dem 2.5.2016 nicht mehr gehen, wenn doch der aktuellle igmpProxy funktioniert???

    Der Schirmer-Blog dreht sich um Switches, das war hier gar nicht die Frage. Mir ging es um einen möglichen Unterschied zwischen Entertain (heute) einerseits und Entertain 2.0 / EntertainTV andererseits.

    Klaus schreibt:

    @kdk:

    -> nur bei dem jetzt kommenden Entertain 2.0 (ab2.5.16) geht es nicht mehr, da dort zwingend igmpv3 nötig ist -und im Downstream kann der igmpproxy das nicht. Warum auch immer.

    Dazu wollte ich gerne Quellen / Hintergründe, weil ich das nicht so ganz zusammenbringe.

    Neu an IGMPv3 ist lediglich das source-specific multicasting. D.h. ein Empfänger kann Multicast Traffic von einer Multicast-Adresse anfordern, der auf einen bestimmten Absender eingeschränkt ist. Das ermöglicht wiederum, daß beliebige Hosts an beliebige Multicast-Adressen senden können, eben auch auf ein und dieselben Multicast-Adresse, ohne daß sich das stört, da die Empfänger den Empfang auf bestimmte Absender einschränken können.

    Die Aussage, daß der IGMP-Proxy das im Downstream nicht kann, ist mir nicht klar, denn im Downstream sendet der Proxy doch wohl nur membership queries, und hier gibt es keinen Unterschied zwischen IGMPv2 und IGMPv3. Die neue Paketstruktur für join / leave und membership reports sind meinem Verständnis nach nur für den Upstream relevant.

    Wenn Telekom also wirklich im Zuge von EntertainTV source-specific multicast einführen will, dann ist in der Tat IGMPv3 zwingende Voraussetzung, und dann sollte das auch der IGMPproxy beherrschen. Wenn der IGMPproxy das nicht kann, dann empfangen Clients unter einer angemeldeten Multicast-Adresse im besten Fall den Traffic aller Sender an diese Multicast-Adresse. Wenn ein heutiger Receiver bereits IGMPv3 beherrscht, dann müßte er - theoretisch - damit sogar klarkommen. Dafür wird das Netz potentiell mit nicht benötigtem Traffic belastet. Andererseits könnte das Telekomseitig für EntertainTV auch so implementiert werden, daß ein Join nur berücksichtigt wird, wenn es IGMPv3 ist. Wenn der IGMPproxy dann keinen IGMPv3 Join schicken kann, bleibt der Bildschirm schwarz. Das ist aber alles Spekulation, darum frage ich ja nach Quellen …  ;)



  • Hallo,

    die Thematik mit den Switches ist mir natürlich nicht entgangen  ;)
    Habe das nur als Referenz genommen, dass bereits damals die Telekom v3 verwendet haben soll. Nur darum ging es mir.



  • Ja paßt. Deswegen ist das Thema bei den Switches auch hochrelevant. Ein IGMP-fühiger switch muß ja sinnvollerweise alle IGMP-Pakete berücksichtigen. Wenn ein MediaReceiver ein IGMP-Paket mit Kennung 0x22 (IGMPv3) versendet (selbst wenn gar kein source-specific multicast verwendet wird), dann klappt das IGMP-Snooping nur, wenn der Switch das eben auch analysieren kann.



  • Ich dachte eigentlich, dass es anders herum funktioniert: aus dem WAN kommen die igmp Pakete und der Switch sorgt dafür, dass die nur die Geräte bekommen, die igmp Pakete wollen. Per Snooping.
    Vom LAN ins WAN war mir nicht bekannt



  • IGMP ist "nur" das Steuerprotokoll (Internet Group Management Protocol). Da passiert ganz grob gesagt folgendes:

    • Die Rechner im LAN melden sich per IGMP an Kanälen (Multicast-Gruppen) an oder ab (beim Ein / Um- oder Abschalten von Kanälen am MediaReceiver) und verteilen periodisch Mitteilungen, an welchen Multicast-Gruppen sie aktuell teilnehmen.
    • Der Router leitet An- und Abmeldungen aus dem LAN ins WAN weiter, damit die Daten aus den entsprechenden Multicast-Gruppen überhaupt an den Router gesendet werden können oder damit die Sendung wieder eingestellt wird.
    • Der Router fragt zusätzlich periodisch Teilnehmer ab, an welchen Kanälen sie angemeldet sind. (Eine Abmeldung könnte ja wegen eines Absturzes oder einer Unterbrechung der Netzwerkverbindung unterblieben sein).
    • Der Router meldet auf Anfrage aus dem WAN die aktuell abonnierten Multicast-Gruppen. Dazu muß er hierfür eine Statistik mitführen.

    Alle diese Router-Funktionen werden durch den IGMPproxy implementiert.

    IGMP (IPv4) setzt in der Transportschicht direkt auf IP auf, es ist also auf derselben Ebene wie TCP und UDP. Bei IPv6 ist das Ganze Teil von ICMP.

    Die Nutzdaten (Bild, Ton) kommen aus dem WAN an den Router, der sie per broadcast im LAN (in der Broadcast-Domäne) verteilt. Welches interne Subnetz an der pfSense als Ziel verwendet wird, bestimmt wiederum der IGMPproxy.

    Aber diese Nutzdaten sind nicht Teil des IGMP!

    Ein normaler (dummer) Switch muß alle Frames auf allen Ports ausgeben, da auf der Ethernet-Ebene (Ebene 2) keine Multicast-Logik möglich ist. Im Ethernet wird Multicast-Traffic als Broadcast verteilt, also an alle Teilnehmer. Die Teilnehmer müssen selbst auseinanderhalten, ob der Traffic für sie bestimmt ist.

    Ein IGMP-fähiger Switch kann das IGMP-Protokoll mitlesen, und weiß daher über die membership reports, joins, und leaves, jederzeit, an welchen Ports Konsumenten welcher Multicast-Gruppen hängen. Entsprechenden Multicast-Traffic leitet er dann über genau diese Ports weiter, über die anderen nicht. IGMP-Pakete selbst werden durch den Switch nicht gefiltert.



  • Hi flo,

    sorry dass ich mich solange nicht gemeldet habe, aber ich habe keine Emailbenachrichtung bekommen.

    Das mit dem Entertain 2.0 welches ja seit 2.5. vermarktet, hab ich schon etwas länger.

    Es ist so dass das "alte Entertain" im LAN auch mit igmpv2 geht, der igmpporxy spricht nach aussen igmpv3. Irgenwo steht auch dass der igmpproxy im Downstream (LAN-Seitig) nur igmpv2 sprechen kann. Weiß der Geier warum der/die das damals so programmiert haben, da er im Upstream auf die Kernelimplementierung von igmp zurückgreift.

    Es gibt wohl viele patche, von denen ich mal einen unter freeBSD 10.3 amd64 kompilliert habe, aber wenn ich dann den igmpprxy auf meiner pfsense damit ersetze geht nix mehr, nach umschalten auf Multicast bleibt das Bild stehen. Laufen tut der igmpproxy aber (wird zumindest angezeigt!)

    Das Problem mit dem VLAN hatte ich noch nie, das alte läuft ja. (VLAN8 wanseitig, im LAN kein VLAN auf der pfsense)



  • @kdk:

    Das mit dem Entertain 2.0 welches ja seit 2.5. vermarktet, hab ich schon etwas länger.

    Aha! Das erklärt, warum Du im April schon wissen konntest, daß Entertain 2.0 mit pfSense 2.3 nicht geht!

    Das Problem dürfte sein, daß der Kanal nur einige Sekunden lang angezeigt wird. Ist das so?

    Bist Du eigentlich Betatester? Oder ist das bei Dir einfach schon früher verfügbar gewesen?

    @kdk:

    Es ist so dass das "alte Entertain" im LAN auch mit igmpv2 geht, der igmpporxy spricht nach aussen igmpv3. Irgenwo steht auch dass der igmpproxy im Downstream (LAN-Seitig) nur igmpv2 sprechen kann. Weiß der Geier warum der/die das damals so programmiert haben, da er im Upstream auf die Kernelimplementierung von igmp zurückgreift.

    Heißt das "da er" oder "dass er"? Wenn der igmpproxy im Upstream eine Kernelimplementierung verwendet, dann ist das doch eine plausible Erklärung dafür, daß das Verhalten zwischen Upstream und Downstream abweicht. Zudem erklärt es eine mögliche Veränderung des Verhaltens in verschiedenen FreeBSD-Versionen bei identischer Version des igmpproxy.

    Ob das die Ursache für das Problem mit Entertain 2.0 ist, ist damit noch nicht aus erster Hand geklärt.

    Wenn es das ist, dann kann ich mir nur eine einzige Hypothese vorstellen: Das source-specific multicasting wird tatsächlich benötigt, die Clients schicken auch entsprechende joins, der igmpproxy interpretiert den Anteil mit source-specific nicht und gibt den join im upstream nicht entsprechend weiter.

    Vielleicht hast Du mal Zeit einen tcpdump laufen zu lassen? Dann könnten wir den IGMP traffic bei Entertain 2.0 sezieren. Benötigt wird der Traffic am besten auf allen Interfaces über ein paar Minuten, gefiltert auf IGMP.

    @kdk:

    Es gibt wohl viele patche, von denen ich mal einen unter freeBSD 10.3 amd64 kompilliert habe, aber wenn ich dann den igmpprxy auf meiner pfsense damit ersetze geht nix mehr, nach umschalten auf Multicast bleibt das Bild stehen. Laufen tut der igmpproxy aber (wird zumindest angezeigt!)

    Bezieht sich auf pfSense 2.3 und Entertain 2.0? Wenn die o.a. Hypothese stimmt, dann kann das nur eine Version des igmpproxy beheben, die source specific multicast interpretiert. Wenn jemand das beim igmpproxy hinzugefügt hat, dann dürfte das in release notes sichtbar sein.



  • @-flo-:

    Vielleicht hast Du mal Zeit einen tcpdump laufen zu lassen? Dann könnten wir den IGMP traffic bei Entertain 2.0 sezieren. Benötigt wird der Traffic am besten auf allen Interfaces über ein paar Minuten, gefiltert auf IGMP.

    Das geht auf der Shell, hier Beispiele.

    Beispiel für WAN (VLAN und Interface anpassen):

    tcpdump -v -e -n -i igb1 -w tmp1.pcap vlan 7 && igmp
    

    Beispiel für LAN (kein VLAN, Interface anpassen):

    tcpdump -v -e -n -i igb0 -w tmp1.pcap igmp
    

    Mit -v bekommst Du die Anzahl der Pakete angezeigt, die tcpdump einsammelt.



  • @-flo-:

    Das Problem dürfte sein, daß der Kanal nur einige Sekunden lang angezeigt wird. Ist das so?

    Das ist richtig. Der Unterscheid zum alten Entertain ist, dass dort das Bild einfach stehen geblieben ist wenn nicht auf Multicast umgeschaltet wird. Beim neuen ist es zumindest bei mir so, dass der Unicast weiterläuft, aber nur mir 1 Mbt/s, was natürlich nicht lange gut geht.

    Das angefügte Bild zeigt wie ein so ein igmpv3 SSM ausehen muss. Dort ist zusätzlich zur Multicastadresse noch die Sourceadresse angegeben. (Ist nicht von Entertain!!)

    Im igmpv2 gibt es das nicht, somit kann er trotz igmpv3 dies nicht nach aussen tragen.

    Ich hab mir auch einen Speedport W723V zugelegt um zu prüfen dass es überhaupt geht. -> funktioniert

    Ich werde nochmal ein paar traces machen und die dann anhängen. Ich weiß aber nicht wie schnell ich das machen kann.

    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.




  • Das mit der Fortsetzung des Unicast finde ich keine schlechte Idee. Gut, die Qualität dürfte im Vergleich zu HD stark abfallen, aber immerhin.

    Ich habe selbst mal IGMP traffic auf der LAN-Seite eingefangen. Interessantes Ergebnis: pfSense sendet periodisch membership queries (Typ 0x11) sowohl mit IGMPv2 als auch mit IGMPv3. Die Unterscheidung hier liegt nicht im Typ des Paketes. Bei IGMPv3 gibt es im Paket ein paar Felder mehr.

    Das bedeutet, daß der igmpproxy auch auf LAN-Seite durchaus zumindest in Teilen IGMPv3-fähig ist. Ob er IGMPv3 membership reports und insb. source specific multicast interpretieren kann, kann ich nicht testen.

    Die Antworten der hosts im LAN sind in meinem Fall ausnahmslos IGMPv2 (Typ 0x16), nicht IGMPv3 (wäre Typ 0x22). Ein MediaReceiver ist da übrigens aktuell nicht dabei, ich verwende mittlerweile TVheadend zum Fernsehen.

    Wenn Du Traces erstellen kannst, können wir das weiter untersuchen:

    • Was sendet ein Entertain 2.0 MediaReceiver?
    • Was sendet ein igmpproxy als Ergebnis auf der WAN-Seite weiter?

    Die Traces sind nicht eilig. Es ist ja leider nicht so, daß man daraus gleich eine Lösung ableiten könnte.  :(

    WAN-seitig werde ich aus dem traffic nicht ganz schlau. Der igmpproxy versendet join requests mit IGMPv3, membership reports aber mit IGMPv2. Warum? ??? Queries aus dem Netz kommen mit IGMPv3.

    Auch da ist ein Trace mit Entertain 2.0 dann aufschlußreicher.



  • Der Unicast läuft ja nicht arg lange, dann meldet der Receiver Fehler.

    Übrigens:

    Es gibt 2 Programme die über rtsp "ausgestrahlt" werden: Joiz und Dog-TV, das ist dann unicast.

    Was mir im System-Log auffällt:

    igmpproxy 3033 RECV unk: 0x22/0x00 from 10.237.146.195 to 224.0.0.22

    Warum meldet der igmpproxy RECV unkown?? Ist das seine Meldung vom Downstream Interface wenn er eine IGMPv3 Meldung erhält?? Würde es erklären.

    Es hieß ja früher schon Entertain benötigt igmpv3. Ich habe mich immer gewindert warum das bei mir im LAN mit v2 funktionierte. Ist aber jetzt klar, nach aussen v3 gesprochen wird und für das "alte" Entertain SSM nicht benötigt wird.

    Es kämpft übrigens auch AVM mit dem Problem, die sind aber für fast alle Modelle durch.

    Die Speedport haben auch angepasste Firmewares bekommen - aud denen läuft ja auch Linux!!



  • @kdk:

    Der Unicast läuft ja nicht arg lange, dann meldet der Receiver Fehler.

    Ok, also bricht das im Zweifelsfall noch vor dem ersten Tor ab.  ;)

    Aber im Ernst, wozu diese Veränderung dann gut ist, erschließt sich mir nicht. Als Puffer, bis der Multicast läuft, gab es ja vorher schon ein paar Sekunden Unicast.

    Es könnte natürlich sein, daß das dauerhaft gesendet wird, aber daß der Receiver damit nicht dauerhaft klarkommt. Nützt dann aber auch nichts.

    @kdk:

    Es gibt 2 Programme die über rtsp "ausgestrahlt" werden: Joiz und Dog-TV, das ist dann unicast.

    Huch, gibt's dafür einen sinnvollen Grund???

    @kdk:

    Was mir im System-Log auffällt:

    igmpproxy 3033 RECV unk: 0x22/0x00 from 10.237.146.195 to 224.0.0.22

    Warum meldet der igmpproxy RECV unkown?? Ist das seine Meldung vom Downstream Interface wenn er eine IGMPv3 Meldung erhält?? Würde es erklären.

    Jau, das ist ein nicht interpretiertbarer membership report aus dem LAN. (Kann gar nicht aus dem WAN kommen, da dort keine membership reports aus dem Netz empfangen werden, der igmpproxy versendet die da nur.)

    Das dürfte von hier kommen ( pali / igmpproxy / master)

    /**
    *   Finds the textual name of the supplied IGMP request.
    */
    char *igmpPacketKind(u_int type, u_int code) {
        static char unknown[20];
    
        switch (type) {
        case IGMP_MEMBERSHIP_QUERY:     return  "Membership query  ";
        case IGMP_V1_MEMBERSHIP_REPORT:  return "V1 member report  ";
        case IGMP_V2_MEMBERSHIP_REPORT:  return "V2 member report  ";
        case IGMP_V2_LEAVE_GROUP:        return "Leave message     ";
    
        default:
            sprintf(unknown, "unk: 0x%02x/0x%02x    ", type, code);
            return unknown;
        }
    }
    
    

    Hier fehlt noch IGMPv3. In dieser Version (pali / igmpproxy / pending) ist es dann drin:

    /**
    *   Finds the textual name of the supplied IGMP request.
    */
    static const char *igmpPacketKind(unsigned int type, unsigned int code) {
        static char unknown[20];
    
        switch (type) {
        case IGMP_MEMBERSHIP_QUERY:     return  "Membership query  ";
        case IGMP_V1_MEMBERSHIP_REPORT:  return "V1 member report  ";
        case IGMP_V2_MEMBERSHIP_REPORT:  return "V2 member report  ";
        case IGMP_V3_MEMBERSHIP_REPORT:  return "V3 member report  ";
        case IGMP_V2_LEAVE_GROUP:        return "Leave message     ";
    
        default:
            sprintf(unknown, "unk: 0x%02x/0x%02x    ", type, code);
            return unknown;
        }
    }
    

    @kdk:

    Es hieß ja früher schon Entertain benötigt igmpv3. Ich habe mich immer gewindert warum das bei mir im LAN mit v2 funktionierte. Ist aber jetzt klar, nach aussen v3 gesprochen wird und für das "alte" Entertain SSM nicht benötigt wird.

    Es kämpft übrigens auch AVM mit dem Problem, die sind aber für fast alle Modelle durch.

    Die Speedport haben auch angepasste Firmewares bekommen - aud denen läuft ja auch Linux!!

    Wie lösen die das? Auch mit dem igmpproxy? Und passen die das selbst an oder bedienen die sich einer verfügbaren Version? Das müßte doch von AVM im source verfügbar sein, oder?



  • @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!



  • @TeeConnector:

    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

    EntertainTrace.zip



  • @-flo-:

    @TeeConnector:

    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.



  • @-flo-:

    @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/DSL

    Was 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 sources
    

    Hier 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/



  • @-flo-:

    @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):

    ![2016-05-07 23_53_13-IPv4 Multicast Address Space Registry.png](/public/imported_attachments/1/2016-05-07 23_53_13-IPv4 Multicast Address Space Registry.png)
    ![2016-05-07 23_53_13-IPv4 Multicast Address Space Registry.png_thumb](/public/imported_attachments/1/2016-05-07 23_53_13-IPv4 Multicast Address Space Registry.png_thumb)



  • @kdk:

    Die neuen Multicast Adressen sind aus diesem Bereich (RFC4607):

    Ja, das muß auch so sein:

    SSM destination addresses must be in the ranges 232.0.0.0/8 for IPv4.

    (Quelle: Wikipedia)



  • 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