IPTV (T-Home) mit pfsense 2.0
-
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_vlan8Bei 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 pppoe1Mein 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 disabledHier 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.
-
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.
-
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