IPTV (T-Home) mit pfsense 2.0



  • Also das TV geht immer 1-1,5 Minuten und dann wieder 1-1,5 Minuten nicht und dies immer fleissigem wechsel. Ich habe dies mit dem Mediareceiver wie auch mit dem vlc und auf dem frame genau. Startet man den igmpproxy auf der consol mit -dv sieht man das er kurz vor dem Standbild "stehen" bleibt und nach rund einer Minute wieder weiter läuft.

    Ich kann mir dies nicht erklären und habe auch keine Lösung irgendwo gefunden …

    Jemand einen Einfall ?

    Danke im voraus.



  • Rofl .. wenige sekunden später habe ich die Lösung gefunden. Eine Regel und zwar die zweite auf dem vlan8 Interface hat noch gefehlt.



  • Hallo,

    kannst Du mir evtl. mal sagen wie Du die PfSende generell konfiguriert hast für IPTV?

    Internet über VLAN 7 funktioniert bei mir soweit. Eine IP-Adresse auf das VLAN 8 bekommen ich inzwischen auch. Allerdings bleibt der TV schwarz, ich bekomme kein Bild.

    Kannst Du mir evtl. sagen wie du den igmp proxy konfiguriert hast? Ich habe auch gelesen das man evtl. noch Routing Einträge machen muss. Aber genauere Angaben habe ich leider im Netz so nirgends gefunden.

    Danke im Vorraus!



  • Über eine kleine, feine Anleitung würde ich mich ebenfalls sehr freuen. :D

    Besten Dank schon mal im Voraus. :)



  • Ich hab mal schnell eine Anleitung erstellt (genutzt wurde pfsense 2.0 Beta4 - build vom 08.10.2010 - welches seid Tagen stabil läuft).

    http://www.x-embedded.de/fileadmin/x-embedded/download/pfsense-iptv.pdf

    Viel Spass damit ;)

    Nachtrag:

    Ich hab mir ein kleines script geschrieben welches ich per cron-addon minütlich starte und somit prüfe ob der igmpproxy noch läuft und diesen ggf startet:

    /usr/local/bin/igmpproxy-check.sh

    if pgrep -l igmpproxy
    then
           echo "igmpproxy is runing"
    else
           echo "start igmpproxy…."
           /usr/local/sbin/igmpproxy -c /tmp/igmpproxy.conf
    fi

    die echos kann man auch entfernen, hab ich nur eingefügt damit man auf der Console eine sinnvolle Ausgabe hat.

    (falls wer eine elegantere Lösung hat, immer her damit)



  • Hi,

    erst mal vielen Dank für die Mühe, die Du Dir gemacht hast.  :)

    Bei mir funktioniert es irgendwie nicht, ich mache sicher was falsch.  ???
    Der Mediareceiver bekommt seine IP aber es kommt kein Bild. Internet geht.

    Wie bekommst Du denn das WAN Interface auf VLAN7? Ich kann mein WAN Interface nur auf PPPoE setzen.
    Der Rest ist gleich, wie bei Dir…

    Danke schon mal für eine Antwort
    Gruß
    Matz



  • Also über "Interfaces" -> (assign) -> Reiter VALN kann man auf dem WAN-Interface zwei VLAN's erstellen. Dann ordnet man eben ID7 WAN und ID8 WAN_IPTV zu.



  • Ja, das habe ich gemacht. Aber im Bereich Interfaces Assign steht bei mir dann nix von VLAN7, wie bei Dir.
    Da kann ich dem WAN Port eben nur die PPPoE Verbindung zuweisen.



  • Wenn du die zwei VLAN's erstellt hast kannst du im Reiter "Interface assignments" im Dropdown-Menu der jeweiligen Schnittstelle auch die VLAN's auswählen. Dann direkt unter "Interfaces" -> "WAN" erst wieder pppoe anwählen. Für "Interfaces" -> "WAN_IPTV" (was erst so benannt werden muss bzw kann) DHCP auswählen.



  • Danke für die Antwort.
    Das habe ich alles so gemacht. Ich denke, der IGMP Proxy tut es nicht….



  • Läuft der Service ? zu sehen unter Status - > Service und sind in den igmpproxy Einstellungen die richtigen Netze mit definiert ?



  • Ja, der Service läuft (ist grün) und die Netze sind analog zu Deinen definiert.
    Der Mediareceiver bekommt die Adresse über DHCP und zeigt mir auch das Fernsehprogramm an (im EPG). Nur das Bild ist schwarz…



  • Also geht TV überhaupt nicht ?, 10 sekunden? oder wie ?

    Hast du die erweiterten Optionen in den Firewall-rules eingestellt ?



  • Ja, die Optionen sind gesetzt, aber keine 10 sec, nur alles schwarz….



  • Hast du block-Meldungen im Firewall-Log für WAN_IPTV ?



  • Vielen Dank für die Anleitung. :)
    Werde sie anwenden, sobald die Hardware da ist. :D



  • Vielen Dank für die Anleitung!!

    Habe jetzt endlich auch ein Bild!  ;D

    Habe nur folgendes Problem:

    Die Umschaltzeiten sind bei mir nun erheblich länger als vorher mit dem Speedport. Teilweise funktioniert das Umschalten auch gar nicht, sprich das Bild bleibt nach dem Umschalten schwarz (bzw. das Bild des vorherigen Programms bleibt stehen). Komischerweise ist dies bisher nur bei RTL passiert… (ist evtl. aber auch nur Zufall)

    Kann man da noch was tunen, damit die Schaltzeiten wieder schneller werden?



  • Ich versuche gerade, mit pfSense meinen T-Home Linux Router zu ersetzen. Der hängt nur auf VLAN8, auf VLAN7 habe ich ein OpenBSD Gateway zum Surfen.
    Leider scheint aber schon der DHCP Client von pfSense die Option option classless-routes nicht zu beachten, die dort angegebenen Routen werden zumindest bei meiner 2.0 Beta von heute gar nicht gesetzt. Ich habe das pfSense dhclient-script mal gegen das hier http://www.freebsd.org/cgi/cvsweb.cgi/src/sbin/dhclient/dhclient-script ausgetauscht, nun scheint das mit den Routen zu funktionieren.
    Es wundert mich, dass IPTV bei einigen von Euch überhaupt funktioniert, da die nötigen statischen Routen in Richtung VLAN8 ja eigentlich nicht vorhanden sein können.



  • Hallo,
    von welchen "statischen Routen" sprichst Du hier denn?

    Bei mir geht es übrigens jetzt, es lag an der IP in der Regel fürs WAN_IPTV. Da musste ich eine andere IP eintragen. Wahrscheinlich, weil ich ja wo anders wohne…

    Aber jetzt rennt es und bei mir stürzt der IGMP Proxy nicht ab.



  • Hi,

    die nötigen Routen werden per DHCP übermittelt, hier der Auszug aus meinem Lease /var/db/dhclient.leases.fxp0_vlan8:

    option classless-routes 32,193,158,132,189,93,228,191,254,25,87,140,255,0,93,228,191,254,17,87,141,128,93,228,191,254,23,193,158,34,93,228,191,254,24,212,184,168,93,228,191,254,29,217,6,164,48,93,228,191,254,32,217,6,164,45,93,228,191,254,26,217,6,167,128,93,228,191,254;
    

    und hier die IP TV Routen, die Richtung VLAN8 zeigen müssen:

    87.140.255.0/25 	93.228.191.254 	UGS 	0 	98 	1500 	fxp0_vlan8 	 
    87.141.128.0/17 	93.228.191.254 	UGS 	0 	352 	1500 	fxp0_vlan8 	  
    193.158.34.0/23 	93.228.191.254 	UGS 	0 	99 	1500 	fxp0_vlan8 	 
    193.158.132.189/32 	93.228.191.254 	UGS 	0 	0 	1500 	fxp0_vlan8 	 
    212.184.168.0/24 	93.228.191.254 	UGS 	0 	3538 	1500 	fxp0_vlan8 	 
    217.6.164.45/32 	93.228.191.254 	UGS 	0 	0 	1500 	fxp0_vlan8 	 
    217.6.164.48/29 	93.228.191.254 	UGS 	0 	0 	1500 	fxp0_vlan8 	 
    217.6.167.128/26 	93.228.191.254 	UGS 	0 	0 	1500 	fxp0_vlan8
    

    Bei mir läuft es jetzt einigermaßen, leider ruckelt es beim Umschalten der Sender öfter mal. So nach ca 10 Sekunden wenn aus dem Unicast Stream auf Multicast gewechselt wird. Hat das noch jemand festgestellt? Passiert z.B. beim WDR ab und an.



  • Wenn man den igmpproxy mit Ausgabe auf der Console startet, sieht man das er versucht Routen zu setzen, falls diese nicht existieren. Dazu muss man aber dem igmpproxy sagen auf welchem if diese liegen.

    [2.0-BETA4][root@fw.jaq-me]/root(8): netstat -rn
    Routing tables
    
    Internet:
    Destination        Gateway            Flags    Refs      Use  Netif Expire
    default            87.186.224.31      UGS         0       78 pppoe1
    79.246.219.160     link#9             UHS         0        0    lo0
    87.151.112.0/20    link#7             U           0        0 vr1_vl
    87.151.126.112     link#7             UHS         0        0    lo0
    87.186.224.31      link#9             UH          0     1830 pppoe1
    127.0.0.1          link#4             UH          0       99    lo0
    127.0.0.2          127.0.0.1          UHS         0        0    lo0
    192.168.50.0/24    link#1             U           0   263342    vr0
    192.168.50.1       link#1             UHS         0        0    lo0
    217.0.43.65        87.186.224.31      UGHS        0      362 pppoe1
    217.0.43.81        87.186.224.31      UGHS        0      388 pppoe1
    
    

    Mein TV läuft gerade und wie man sieht sind keine routen für iptv gesetzt.



  • Funktionieren bei Dir denn alle anderen Dienste, wie EPG, Videorecorder, TV Archiv?



  • Jabs, ausser wie gesagt wahrscheinlich kein udp für die ersten 10 Sekunden. Weil umschalten dauert auch bei mir mal 2-3 Sekunden.



  • Dann setz mal die Routen bzw. tausch einfach mal das dhclient Script und hol Dir den DHCP Lease neu. Danach geht auch der Unicast Stream für die ersten 10 Sekunden.



  • Danke für den Tipp mit den Routen!!  :)

    Funktioniert bei mir zwar auch ohne, aber evtl. sind dann die Umschaltprobleme ja dann verschwunden.. hoff :)

    Übrigens sind die Routen bei jedem unterschiedlich. Je nachdem in welchem Netz man sich befindet. Man bekommt eine Adresse aus einem /19 Netz. Darin befindet sich das GW für die Routen (bei mir übrigens die 93.213.255.254).

    In dem jeweiligen /19 Netz befindet sich auch ein Server für den Multicast Traffic. Deswegen funktioniert TV auch ohne diese Routen.

    Würde mal wissen wollen, wofür die Routen eigentlich gut sind…  ???

    Weiss jemand ob das aktuelle DHCP-script noch in pfsense einfliesst?



  • Hab das script mal ausgetauscht, und gefühlt ist das umschalten nun schneller. Die Routen werden nun auch richtig gesetzt.

    [2.0-BETA4][root@fw.jaq-me]/tmp(9): netstat -rn
    Routing tables
    
    Internet:
    Destination        Gateway            Flags    Refs      Use  Netif Expire
    default            87.186.224.31      UGS         0      468 pppoe1
    79.246.217.158     link#9             UHS         0        0    lo0
    87.140.255.0/25    87.151.127.254     UGS         0        0 vr1_vl
    87.141.128.0/17    87.151.127.254     UGS         0        0 vr1_vl
    87.151.112.0/20    link#7             U           0        0 vr1_vl
    87.151.126.112     link#7             UHS         0        0    lo0
    87.186.224.31      link#9             UH          0    10910 pppoe1
    127.0.0.1          link#4             UH          0       99    lo0
    127.0.0.2          127.0.0.1          UHS         0        0    lo0
    192.168.50.0/24    link#1             U           0  4018062    vr0
    192.168.50.1       link#1             UHS         0        0    lo0
    193.158.34.0/23    87.151.127.254     UGS         0        0 vr1_vl
    193.158.137.14/32  87.151.127.254     UGS         0        0 vr1_vl
    212.184.168.0/24   87.151.127.254     UGS         0        0 vr1_vl
    217.0.43.65        87.186.224.31      UGHS        0      659 pppoe1
    217.0.43.81        87.186.224.31      UGHS        0      661 pppoe1
    217.6.164.45/32    87.151.127.254     UGS         0        0 vr1_vl
    217.6.164.48/29    87.151.127.254     UGS         0        0 vr1_vl
    217.6.167.128/26   87.151.127.254     UGS         0        0 vr1_vl
    
    


  • Bei mir ist leider immer noch der Übergang von Unicast auf Multicast unsanft. Umschalten geht sofort nach Tastendruck, aber nach 5-10 Sekunden bleibt das Bild/Ton kurz stehen und man sieht Artefakte. Meine Test-Routerhardware ist zwar sehr alt (Mini ITX mit 500 Mhz Via CPU), aber die CPU Last ist nie über 40-50%. Hat sonst noch jemand das Problem?

    Edit: @xpapa: Du hast da ein Alix Board (viele vr Interfaces), oder? Deine Antwort wäre also die Interessanteste ;)



  • Jabs ich nutze eine Alix und habe mit der Last und umschalten kein Problem. Jedoch stirbt bei mir der igmpproxy ab un an, was ich jedoch mit einem kleinen Script minütlich teste.

    Also mit der CPU-Last habe ich kein Problem und der Netzwerktreiber scheint auch zu funktionieren. Ich habe hier jedoch auch nur DSL16+. Mit VDSL kommt die Alix dann sicher an ihre Grenzen und ich erwarte in diesem Zusammenhang die neue Soekris.



  • Kannst Du aus dem Log ersehen, warum er stirbt? Er müllt das Log ja eh leider ziemlich zu, aber wenn Du ihn mal sterben lässt ohne ihn via Script neu zu starten, sollte der letzte Logeintrag von ihm ja Aufschluss bringen.

    Edit: Also, bevor die T-Com damals das IPTV von IGMP v2 auf v3 umgestellt hat, hatte ich alles zusammen unter VDSL 50 mit einem einzigen Alix Board unter OpenBSD laufen. Sogar Lasttests wie auf 2 Mediareceivern HD Streams schauen und nebenbei mit der verbleibenden vollen Geschwindigkeit runter laden hat das Board nicht an seine Grenzen gebracht.
    Das hier ist ein Download mit voller Geschwindigkeit:

    load averages:  0.16,  0.25,  0.24
    46 processes:  45 idle, 1 on processor
    CPU states:  0.8% user,  0.0% nice,  0.0% system, 67.9% interrupt, 31.3% idle
    Memory: Real: 100M/145M act/tot  Free: 98M  Swap: 0K/0K used/tot
    


  • @xpapa: Schreib Dir mal eine Rule direkt unter Deine IGMP Pass Rule für den Mediareceiver. Die neue Rule sollte Proto IGMP von any zu any einfach generell blocken. Dann nimm mal Dein IGMP Proxy Restart Script raus und schau ob er noch abstürzt.



  • Öhm normal ist doch alles verboten, somit brauch ich doch keine block-regel?!? Oder sehe ich da was falsch?

    Mein Restart-Script ist schon aus … und heut den ganzen Tag noch nicht gestorben. Mal sehen was heut morgen ist. Meist war er morgens down .. da schaue ich mal ob was im log steht.



  • Kommt drauf an, ob Du Anti Lockout an oder aus hast, glaube ich. Ist mir nur gestern beim Experimentieren aufgefallen, ich hatte kurzzeitig meine Alix Box zusätzlich mit IGMP Proxy im LAN und dabei hat es dann den IGMP Proxy auf meiner Testkiste gerissen. Ich kann mich erinnern, dass es mal so ein ähnliches Problem mit T-Home Routern und Vista / Win7 Workstations gab. Die Workstations geben sich als IGMP Router aus, genauso wie ein IGMP Proxy auf dem Downstream Interface. Das führte damals dazu, dass die T-Home Multicast Router immer für kurze Zeit den Dienst eingestellt haben, weil die T-Home Router zu viel durchgelassen haben ;)
    U.u. ist der IGMP Proxy von FreeBSD ebenso empfindlich, daher sollte auf der LAN Seite ausser dem Mediareceiver und der LAN IP des Routers kein Traffic Richtung 224.0.0.0/4 dürfen.



  • Hm vielleicht hät ich mal eher ins log schauen sollen -> "igmpproxy: ERRO: setsockopt IP_MULTICAST_IF 79.246.21X.XXX; Errno(49): Can't assign requested address" , der reconnect des pppoe Interfaces reisst den igmp in den Tod.

    Edit: Hm die conf des igmpproxy ist nicht ganz richtig:

    ##------------------------------------------------------
    ## Enable Quickleave mode (Sends Leave instantly)
    ##------------------------------------------------------
    quickleave
    phyint vr1_vlan8 upstream ratelimit 0 threshold 1
    altnet 239.35.0.0/16
    altnet 193.158.35.0/24
    
    phyint vr0 downstream ratelimit 0 threshold 1
    altnet 192.168.50.61/32
    
    phyint pppoe1 disabled
    
    

    Hier müssten mehr devices auf disable stehen. Aber das entsprechende dev (pppoe1 steht eigentlich auf disabled und sollte somit ja nicht an den proxy gebunden werden ?!?)

    Edit2:

    Ich habe nun mein Prozess-check-script auf 5:03 gesetzt, zu dieser Zeit sollt der igmpproxy gestorben sein. Natürlich funzt es nun nicht wenn das dsl mal zwischendurch ausfällt und stellt somit nur einen schlechten workaround dar.



  • Ich weiss nicht, wie sich der IGMP Proxy von pfSense verhält, aber dem von OpenBSD hat das nicht so besonders viel ausgemacht mit den Interfaces, die vorhanden, aber nicht disabled waren.
    Falls man irgendwie ifstated unter pfSense zum laufen bekommt, liesse sich damit ein eleganterer Workaround fürs Neustarten beim PPPoE Reconnect schaffen.

    Leider hat mein Versuch mit dem Alix Board keine Besserung gebracht. Es hakt immer noch kurz nach dem Umschalten, ab und zu bleibt der Stream auch ganz stehen. An der Hardware kanns auch nicht liegen, wenn ich die CF Karte mit dem Voyage Linux und IGMP Proxy wieder in das Board stecke, läuft alles wie geschmiert. Mal sehen, ob ich am Wochenende noch was debuggen kann…



  • Starte mal den igmpproxy auf der Console mit -dv , dann siehst du die ausgaben direkt und kannst schauen was er im Moment des stehen bleibens macht. Also ich habe bis auf den Reconnect keine probs mehr.



  • @Beerman:

    Weiss jemand ob das aktuelle DHCP-script noch in pfsense einfliesst?

    Ich hab gestern nen Bug Report aufgegeben und es wurde sofort übernommen, wenn ich das richtig sehe :) Sollte also in den nächsten Beta Builds vorhanden sein.

    Wegen der IGMP Proxy Probleme stehe ich gerade mit dem Autor in Kontakt.



  • @xpapa:

    Also ich habe bis auf den Reconnect keine probs mehr.

    Wenn ich die Logik richtig verstehe, sollte es reichen, ein ausführbares IGMP Proxy Startscript mit Endung .sh in /usr/local/etc/rc.d zu legen.
    /etc/rc.newwanip ruft nämlich am Ende /etc/rc.start_packages auf, welches dann folgendes tut:

        echo "Executing rc.d items... "
        for FILE in /usr/local/etc/rc.d/*.sh; do
                    echo -n " Starting ${FILE}..."
                    sh $FILE start >>/tmp/bootup_messages 2>&1 &
                    echo "done."
        done
    
    


  • Es ist noch ein weiterer Workaround notwendig, damit DHCP richtig funktioniert. Zumindest bei mir liefert der DHCP Server der Telekom folgende Option:
    option routers 255.255.255.255;
    Das ist ein wenig doof, da pfSense dann brav versucht, 255.255.255.255 als Gateway zu setzen. Schlägt zwar beim route add fehl, wird aber trotzdem für die pf route-to Firewall Rules übernommen und auch als Gateway unter Routing eingetragen. Dadurch funktioniert dann leider das NATen/Firewalling auf VLAN8 nicht und z.B. die ersten 10 Sekunden Unicast Stream kommen nicht durch.
    Man kann das unfein umgehen, indem man die Route in der Interface Definition hart einträgt:
    /etc/inc/interfaces.inc editieren, nach {$wanif} suchen (bei mir ist VLAN8 auf dem WAN Interface), und dort an passender Stelle etwas wie
    supersede routers 93.228.191.254;
    eintragen. Dann sieht
    /var/etc/dhclient_wan.conf so aus und der Traffic kann fliessen…

    interface "fxp0_vlan8" {
    timeout 60;
    retry 1;
    select-timeout 0;
    initial-interval 1;
    
            supersede routers 93.228.191.254;
            script "/sbin/dhclient-script";
    }
    


  • @athurdent:

    @Beerman:

    Weiss jemand ob das aktuelle DHCP-script noch in pfsense einfliesst?

    Ich hab gestern nen Bug Report aufgegeben und es wurde sofort übernommen, wenn ich das richtig sehe :) Sollte also in den nächsten Beta Builds vorhanden sein.

    Wegen der IGMP Proxy Probleme stehe ich gerade mit dem Autor in Kontakt.

    Super, vielen Dank!

    Ich habe allerdings nach dem Update festgestellt, dass die nicht das neueste dhcp-script verwenden!

    Nach dem Update hatte ich die Version:

     1.4 2005/06/10 03:41:18
    

    die neueste auf der CVS Seite http://www.freebsd.org/cgi/cvsweb.cgi/src/sbin/dhclient/dhclient-script?f=u&only_with_tag=RELENG_8_1&logsort=date ist allerdings:

    1.20.2.1.4.1 2010/06/14 02:09:06
    

    Mit dem originalen script 1.4 2005/06/10 03:41:18 hatte ich auch wieder Umschaltprobleme, trotz gesetzten Routen. Wahrscheinlich das Problem, wie von Dir zuletzt beschrieben.

    Mit dem neuesten Script 1.20.2.1.4.1 2010/06/14 02:09:06 habe ich keine Probleme beim Umschalten mehr.

    Hast Du schon eine Rückmeldung von den IGMP-Proxy Jungs?



  • @Beerman:

    Hast Du schon eine Rückmeldung von den IGMP-Proxy Jungs?

    Der Autor hat das Problem bestätigt, aber leider keine Zeit es zu beheben. Ich habe festgestellt, dass man einfach den IGMP Proxy aus den FreeBSD 8.1 Ports nehmen kann. Ich habe die Binary per Hand aus dem Archiv entpackt und auf die pfSense Box gelegt. Der Proxy muss dann zwar per Hand auf der Konsole gestartet werden, er hat ne andere Syntax (kein -c für die Konfig, Pfad einfach so hinten dranschreiben), aber er bleibt nicht hängen. Auch mit dem geht es nicht perfekt, ich hab immer recht oft noch nach ca. 10 Sekunden einen kurzen Aussetzer. Der Übergang zwischen Unicast und Mulitcast klappt nicht sauber. Habe mir zum Testen mal eine FreeBSD 8.1 Box aufgesetzt, bei der ist es leider das Gleiche.


Log in to reply