T-Home IPTV ohne Speedport unter Linux (VDSL)

(23.07.2007: Diese Anleitung steht nun im Wiki zur Verfügung. Verbesserungen, Anregungen, Vorschlage usw. sind immer willkommen: T-Home IPTV ohne Speedport unter Linux (VDSL))

(17.02.2009: UPDATE – Telekom stellt derzeit ihre Technik auf zwei VLANs um. In Zukunft wird es vlan id 7 und 8 geben. Wie man das unter Linux/Debian einrichtet findet ihr hier: /2009/02/17/t-home-vdsl-unter-debian-linux-einrichten-vlan-id-7-und-8/)

(14.12.2009: UPDATE – Die MTU für ppp0 scheint doch besser 1454 zu sein. 1492 ist definitiv falsch. Einstellen mit ‘ifconfig ppp0 mtu 1454’ oder in den entsprechenden Debian Konfigurationen)

Nach langem basteln habe ich es nun geschafft. Ich habe endlich den billigen mitgelieferten Router in die Tonne getreten und mein Debian System wieder zum Router gemacht. Das ist mir schon deshalb lieber, weil ich viel mehr Kontrolle über Firewall, Proxy und alles andere habe.

Netter Nebeneffekt ist, dass man bei vollem Upload keine Bildprobleme bekommt. Auch wenn manch einer nun sagen mag, dass man dann den Router einfach den priorisierten Port hängen soll. Das ist defintiv falsch. Fakt ist, dass der Telekom Router einfach Mist baut. Der Reciever hängt nun in meinem Netz und Daten werden alle über iptables ins Internet geroutet und zurück. Es läuft perfekt.

Leicht war die Sache allerdings nicht. Vor allem weil man bis dato kaum Informationen dazu findet (das hat ja nun ein Ende *g*). Und für alle, die sich auch an dem T-Com Router stören berichte ich nun wie ich es gemacht habe. In meinem Blog zuvor hatte ich ein Verkabelungsbild gezeichnet. Das ist Vergangenheit. Man kann mit 0815-Switches einfach keine Netze von einander trennen.

Beginnen tut die Geschichte damit, dass man seine pppoe Verbindung modifizieren muss. Außerdem wird eine Netzwerkkarte benötigt, die VLAN unterstützt. Diese Karte wird mit dem VDSL2 Modem verbunden. Wie man heraus findet ob die Karte es unterstützt, weiß ich nicht. Das werde ich noch in Erfahrung bringen. Aber meine beiden ur-alten Karten (Realtek, 3com) unterstützen es. Also denke ich, dass die meisten mithalten können.

Der Kernel muss mit VLAN Unterstützung kompiliert werden (modular oder
monolithisch). eth1 ist im folgenden die NIC, die mit dem Modem
verbunden ist.

Man braucht noch aus apt folgendes Paket:

vlan - user mode programs to enable VLANs on your ethernet devices

Und diese Einstellungen in den interfaces. Die ID ‘7’ ist scheinbar
zwingend notwendig für (Telekom) VDSL:

# /etc/network/interfaces
auto eth1
iface eth1 inet manual
post-up vconfig add eth1 7
post-down vconfig rem eth1.7

Nun muss man dem pppoe nur noch sagen, dass eth1.7 das zu verwendende
Device ist:

# /etc/ppp/pppoe.conf
# Ethernet card connected to DSL modem
ETH='eth1.7'

Damit müsste man sich nun einwählen können. Natürlich müssen die Benutzerdaten usw. stimmen (/etc/ppp).

Jetzt zum IPTV, was mich die meiste Arbeit gekostet hat. Der Kernel braucht hierfür Multicasting und Multicasting Routing Support. Und ohne folgendes kleines Programm hat man das Problem, dass man nach 10 Sekunden immer ein Standbild bekommt. Hierfür wird ein igmpproxy installiert:

http://sourceforge.net/projects/igmpproxy

Entpacken, in ‘src’ wechseln und mit make kompilieren und mit make install installieren.

Nun muss die /etc/igmpproxy.conf konfiguriert werden:

quickleave
# upstream = Internet Device
phyint ppp0 upstream ratelimit 0 threshold 1
altnet 217.0.119.194/24
altnet 193.158.35.0/24;
# IP der TV-Box
altnet 192.168.1.5/32;


# eth0 ist das LAN-Interface
phyint eth0 downstream ratelimit 0 threshold 1

# andere Devices werden deaktiviert
phyint eth1 disabled
phyint eth1.7 disabled
hyint lo disabled

Gestartet wird das ganze dann mit:

igmpproxy -d -c /etc/igmpproxy.conf > /dev/null 2>&1 &

Die Umleitung ins Nirvana kann man für Debug Zwecke vielleicht erst Mal nicht verwenden. Aber in der Syslog wird auch nochmal alles protokolliert, was ich später dann aber deaktiviert habe, weil es zu viel zu großen Log-Dateien führt und nicht wirklich informativ ist, wenn es mal läuft. Das muss über den syslog-ng (oder alternativ ksyslogd) gelöst werden.

Als letztes müssen noch ein paar iptables Regeln hinzugefügt werden. Und zwar müssen alle Multicast Pakete durchgelassen werden (dafür haben wir den Kernel neu kompiliert):

iptables -I FORWARD -s 217.0.119.0/24 -d 224.0.0.0/4 -j ACCEPT
iptables -I FORWARD -s 193.158.35.0/24 -d 224.0.0.0/4 -j ACCEPT
iptables -I INPUT -d 224.0.0.0/4 -j ACCEPT
iptables -I FORWARD -d 224.0.0.0/4 -j ACCEPT

Und damit hat man dann einen super Zugang zu VDSL und IPTV mit dem netten Nebeneffekt, dass das Umschalten durch den igmpproxy in Windeseile funktioniert.

Viel Spass

32 Gedanken zu „T-Home IPTV ohne Speedport unter Linux (VDSL)

  1. Hallo,
    es gibt meines wissens keine VLAN Unterstützung bei Netzwerkkarten. Das Vlan-Tag wird Softwareseitig einfach dem TCP-IP Protokoll angehängt (mit z.B vconfig). Am anderen Ende muss lediglich ein Gerät stehen das mit dem VLAN-Tag etwas anfangen kann (und natürlich auch eine Firewall(elementar wichtig), damit die Packete Ihre Route bekommen). Das kann ein Software Router (der machts wieder Software-Seitig) oder ein Layer2-Switch (hier geschied es auf der Hardware-Seite) sein. Also nicht das jemand in den nächsten Computerschuppen rennt und nach ner VLAN fähigen Netzwerkkarte Fragt :).
    VLAN Netze sind übrigens super (darf ich GEIL schreiben??) GEIL. Hab selber ein Vlan-Netz, allerdings auch mit einen Layer2-Switch (was nichts anderés bedeutet als: ist Konfigurierbar) von 3Com. Wenn man da noch ‘ne richtige Firewall (ich nehme hier Astaro, weil für priv. kostenlos, und sehr prof.) draufsetzt, kann man sein Netz super managen. Besser geht’s da im priv-Bereich nicht mehr. So ein Layer 2 Swicht kostet mit ein wenig Glück bei ebay ca. 50.- Euronen.

  2. Interesting piece of work. I have a similar situation tying to get IPTV via ADSL into my intranet without installing extra cables for the TV part. Unfortunately my German is a little weak so I would like to get into contact with you by email. You should have access to my email address from this reply. Thanks.

  3. An vielen Ecken im Netz findet man den Hinweis, dass für VDSL eine VLAN-fähige Netzwerkkarte benötigt würde. Wie bruder-c schon richtig schreibt, ist das kein Feature der Netzwerkkarte, sondern des Protokolls. Unter Windows ist es allerdings so, dass der Netzwerkkartentreiber die Unterstützung für VLAN mitbringen muss – unter den “richtigen” ( 🙂 ) Betriebssystemen ist der Treiber der Netzwerkkarte kein Stolperstein.
    Für den, der mit Windows arbeitet, ist die Aussage “Die Netzwerkkarte muss VLAN können” zwar nicht ganz korrekt, es läuft aber auf’s gleiche wie “Die Netzwerkkarte muss einen Treiber haben, der VLAN unterstützt” heraus. Für die ist allerdings der igmpproxy sowie auch der mrouted ohnehin nicht von Interesse 😉

  4. Hi!

    Leider gibt es bei uns noch kein VDSL. Ist aber in der Mache. Eine kleine Anmerkung zu den zur interfaces Datei:

    Mit dem pre-up und post-down geht es zwar, “richtiger” waere aber folgendes:

    auto eth1
    iface eth1 inet loopback

    auto eth1.7
    iface eth1.7 inet loopback

    Damit sollte es auch gehen. Debian hat VLAN Support beim konfigurieren mittels interfaces eingebaut. Das ist also die elegantere Methode.

    Ob Du bei iface eth1.7 inet dann loopback nimmst oder manuel kann ich nicht genau sagen, da ich nicht weiss wie die PPPOE Session aufgebaut wird.

    Gruss Torge

  5. Also ich habe die Erfahrung gemacht, dass es schon benötigt wird. Aber du klingst so, als hättest du auch Ahnung 😉 Deswegen nehme ich deine Anregung einfach mal so auf. Falls wer anders das mal probiert, könnte man das ja mal bestätigen.

  6. Ich habe jetzt versucht, das unter Suse 10.2 nachzustellen, aber es funktioniert nicht richtig. Verbindung wird aufgebaut und steht auch (via vlan7, das mit vconfig anlegbare eth2:7 funktioniert dafür nicht), aber man bekommt fast für alles ein Timeout. Pings und ssh gehen, ftp auch, imap und smtp aber nicht. Es ist so zufällig, das ich nicht an einen Fehler glaube, irgendwas habe ich falsch konfiguriert. Knoppix erkennt leider meine Netzwerkkarten nicht.
    Kann also jemand mal Holzfäller spielen, denn der Router möchte so gern das große Auktionshaus kennenlernen?

  7. Ok, damit niemand sich genauso einen Wolf sucht wie ich: mtu und nru müssen sowohl für vlan7, dsl0 als auch in /etc/ppp/options auf 1476 (1492-16 Byte) eingestellt werden. Dann geht es. Keine Ahnung, warum das nirgendwo steht/stand.

  8. Die Änderung der MTU/MRU Größe kann man aus dem Syslog entnehmen, wenn man in den Optionen “debug” und “kdebug 7” angibt. Leider überschreibt bei der Aushandlung der voreingestellte Wert von 1492 diese Empfehlung der Gegenstelle. Mit Knoppix, also vermutlich allen Debian-basierten Systemen, wird dies berücksichtigt und man muss es nirgendwo angeben. Aber der pppd von Opensuse ist ohnehin mit einigen zusätzlichen Patches versehen, da klappt das wohl nicht mehr.

  9. Hi,

    vlan und Multicastpackages schoen und gut aber wie siehts mit der Infrastruktur dahinter aus? Dass ein Switch mit Broadcast richtig umgehen kann, da bin ich mir 100% sicher aber wie siehts mit Switches(nicht managebaren 40,- Euro billiggigabitswitches) aus?

    Soweit ich das in der Wiki gelesen habe, verwendet man fuer Multicast auch die Broadcast?

    Will halt ungern jetzt richtig Kohle in nen guten Gigabitswitch reinstecken, n durchschnittlicher reicht mir noch aus.

  10. Also ein 0815-Switch, wie ich ihn auch nutze hat gerade mal 15€ gekostet und kommt damit natürlich klar. Der genaue Unterschied zwischen Multicast (dabei handelt es sich bei T-Home) und Broadcast ist mir auf Abruf nun nicht im Hirn verblieben, aber beide befinden sich im OSI-Layer auf Ebene 2. Der Switch, wie billig er auch sein mag, kommt mit diesem Layer gar nicht in Berührung. Also keine Sorge. Am Switch wird es am wenigsten scheitern.
    Probleme gibt es mit dem Multicast leider schon. Sobald man fern schaut bekommt jeder Rechner im Netz die Daten ab. Das könnte man evtl. mit einem teuren Switch verhindern. Evtl auch mit dem Router, den ich in die Tonne gekickt habe.

  11. Bezüglich Broadcast vs Multicast. Primitive Switches handhaben Multicast Pakete wie Broadcasts und pusten die Pakete auf allen Ports raus. Ein guter Switch mit Multicast Support beachtet auch die IGMP Pakete und erkennt so, welche Multicast Group an welchem Port gebraucht wird und schickt dann diese Multicast Pakete auch nur an die Abonnenten raus. Dafür muss der Switch dann intelligent genug sein, um Pakete auf Layer 3 analysieren zu können.
    In einem kleinen Netzwerk dürfte das jedoch wohl ehr von geringerer Bedeutung sein.

    Summa summarum:
    – bei Multicast Switch: Multicast Pakete nur an die, die wollen.
    – Bei nicht Multicast Switch gehen die Pakete an allen Ports raus.

  12. hi claus,
    danke für deine anleitung, ich habe heute nach fast 6 monaten ärger mit der t-com auch endlich vdsl bekommen, und dank deiner tips funktioniert IPTV auch länger als 10 sekunden 😉

    ich nutze den speedport router für die einwahl, dahinter hängt mein linux server, und dahinter kommt dann mein normales netzwerk, daher passte deine anleitung nicht so ganz. zusätzlich zu den firewall rules habe ich folgende igmpproxy config verwendet:

    quickleave
    phyint eth2 upstream ratelimit 0 threshold 1
    altnet 192.168.254.0/24
    altnet 217.0.119.194/24
    altnet 193.158.35.0/24
    phyint br0 downstream ratelimit 0 threshold 1
    altnet 192.168.0.13/32

    (eth2 ist das interface zum router und br0 die interne bridge, an der auch der X301T mit der IP 192.168.0.13 hängt)

  13. hallo claus,
    ich versuche das ganze auf openWRT auch irgendwie für mein bluewinTV (der swisscom) hinzubekommen, kriege aber beim start des igmpproxy jeweils die (fehler)meldung “No downstream listeners for group 239.255.255.250. No join sent.” …hmmm… habe schon zig optionen versucht. freeze nach 10 sekunden 🙁
    verstehe wohl die bedeutung des keywords “altnet” ned richtig, wann braucht’s des für up- & downstream? – bin verwirrt!

  14. Hallo,

    hier vllt. noch etwas technischen Hintergrund warum VLANs eingesetzt werden.

    (A)DSL(2) wird über ATM realisiert, die DSL- Modems bauen eine ATM-Verbindung zum DSLAM auf (dafür sind die VPI/VCI- Werte 1/36 in den Modemeinstellungen wichtig). Der Modem bridged dann die virtuelle Verbindung auf die LAN-Schnittstelle und darüber läuft dann PPPoE (Point-to-Point-Protocol over Ethernet) für die Benutzerauthentifizierung (Einwahl). Das hier gilt für xDSL bis 16 mbit/s.

    Bei ADSL2 16+ läuft die Anbindung der DSLAMs über Gigabit-Ethernet. Es kommt also schon Ethernet am Modem an. Damit jetzt Internet, IPTV und VoIP getrennt werden können, und jedes die Bandbreite erhält die es braucht, werden VLANs genutzt. Das “DSL” liegt jetzt in VLAN-ID 7 und PPPoE muss in diesem VLAN genutzt werden.

    Die MTU von 1467 kommt hier her: Ethernet hat eine MTU von 1500. Hier gehen jetzt 8 Bit für den PPPoE Header weg. Ergibt die von DSL bekannte MTU von 1492. Jetzt muss aber bei VDSL noch der Header für die VLANs genutzt werden (-12 Bit) und die Werte für QoS (-4 Bit). So landen wir dann bei 1467 Nutzendatenrate, der Rest ist der sog. Protocol-Overhead.

    Ich hoffe, ich meine Erkärungen sind verständlich. Sonst hilft Wikipedia bei den Abkürzungen der DSL-Technik weiter.

    Neelix

  15. Wie sieht es nach der Umstellung auf 2 Vlan ID’s aus. Die Telekom hat vor Vlan7 pppoe fürs Internet und Vlan 8 für IPTV DHCP zu verwenden.

    Wie geht dann die Einwahl von statten?

    Gruß
    Jörg

  16. Pingback: Claus’ Blog » Blog Archive » T-Home (VDSL) unter Debian Linux einrichten (vlan id 7 und 8)

  17. Informationen… Ich haette es fast nicht mehr geglaubt… 😉

    Aber: Wenn nicht ohne Speedport, mit was dann? Hast du ein VDSL2+ faehiges Modem gefunden, das mit Debilian tut oder uebersehe ich da etwas?

  18. Speedport ist auch die Bezeichnung des Routers. Ich hätte das evtl. ein wenig genauer definieren sollen. Ich verwende weiterhin das Modem von der Telekom nur den Router eben nicht mehr.

  19. Hi Claus

    Hab jetzt den Proxy am laufen, leider gibt ab un zu Probleme beim umschalten.
    Die conf Dateien sind richtig erstellt, bin ein wenig ratlos

    Gruß
    Jörg

  20. Hi zusammen,

    @Jan: Hättest du nicht einfach die eth2 an die Bridge hängen können? Welche Funktion hat in deinem Fall der IGMP-Proxy?

    Grüße
    Fux

  21. Hi zusammen,
    igmpproxy auf VLAN8, inet auf VLAN7, alles OK, läuft perfekt. Wird aber das System ausserplanmäßig neu gestartet, hatte ich das Poroblem, dass das INET weg ist, b.z.w. pppoe keine Verbindung mehr aufbaut. Wenn dhcpclient3 eth1.8 eine IP bezogen hat, ist für lange Zeit keine pppoe Einwahl mehr möglich. Ursache scheint eine MAC-Adressensperre bei T-Com zu sein. Die beiden VLANS eth1.7 und eth1.8 erhalten automatisch die selbe HW-Adresse wie eth1. Unterschiedliche MACs der VLANS löste das Problem.
    Jack

  22. Interessant. Bei mir haben eth1.8 und eth1.7 auch die selbe MAC-Adresse, aber das Problem hatte ich noch nicht.

    Danke für den Tipp. Wäre interessant zu wissen, wieso das bei mir nicht auftritt.

  23. igmpproxy -> syslog
    Hi zusammen,
    igmpproxy läuft einwandfrei, aber verursacht unschöne Einträge im Syslog
    —->
    Aug 24 16:22:42 debian10 igmpproxy[2145]: The source address 192.168.37.220 for group 239.255.255.25
    0, is not in any valid net for upstream VIF.
    —–<
    Diese Meldung erscheint alle 20s im syslog und müllt dieses total zu !
    Wie können die nervigen Meldungen (normal) unterdrückt werden ?
    Genau das wurde schon weiter oben von @jakommo gefragt.
    Als Workaround habe ich im Quellcode von igmpproxy alle Ausgaben ins syslog kommentiert und dann igmpproxy kompiliert. Nun ist zwar Ruhe mit Syslogeinträgen, aber das kann es doch nicht sein, oder ?
    Ein zweites kleines Problem ist dhclient3 und die Gültigkeit der IP-Adresse für VLAN8. T-Home IP-TV funktioniert einwandfrei, dhclient3 auf VLAN8 (eth1.8) ist geladen, igmpproxy ebenfalls, jedoch nach einigen Stunden wird offensichtlich die IP-Adresse für VLAN8 ungültig und das Bild bleibt stehen ( 10s bei Kanalumschaltung, dann wieder Stop ). Kille ich den dhclient3 und starte ihn händisch neu, bekommt er sofort wieder eine neue IP und es geht unmittelbar dannach sofort weiter mit IP-TV, aber wieder nur für einige Stunden….
    Wie kann man dhclient3 dazu zwingen z.B. alle 4h eine neue IP anzufordern bzw. wie sieht eine perfekt funktionierende dhclient.conf aus ?
    Jack

  24. Hi Jack,

    ich habe das selbe Problem wie du anscheinend wenn ich eine Ip über Vlan8 zugewiesen gekriegt habe, kann ich mich nicht mehr einwählen. Könntest du mir mal bitte erklären, wie du dieses Problem gelöst hast?

    mad9

  25. Hi,

    ich habe gerade bei mir die Erfahrung gemacht, dass es bei (der neuesten Version von) igmpproxy auf die Reihenfolge ankommt:

    # IP der TV-Box
    altnet 192.168.0.16/32;

    # eth0 ist das LAN-Interface
    phyint eth0 downstream ratelimit 0 threshold 1

    funktioniert bei mir nicht, nur andersrum. Also erst der phyint Eintrag, dann altnet für die IP am Downstream Interface. Sonst bekomme ich immer

    The found if for 192.168.0.16 was not downstream. Ignoring leave request.

    Grüße
    r2-d2

  26. Hi,

    ich stehe vor genau dem beschriebenen Problem und habe einen W723V Speedport.
    Aus den Anleitungen, die ich hier gefunden habe und auch aus dem Manual, habe ich gelesen, dass dieses super-Teil die VDSL-Pakete nicht durchlaesst. Bevor ich jedoch das Teil “in die Tonne haue”, wuerde mich brennend interessieren, mit welcher Hardware Du das System zum Laufen gebracht hast.
    In diesem Sinne, vielen Dank schonmal
    Ruesselkalle

Hinterlasse einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *