PfSense 2.3 mit Telekom Entertain
-
PPPoE habe ich einfach konfiguriert gelassen. An einem BNG-Anschluß müßte das m.W. auch ohne PPPoE gehen. Ob das bei mir klappen würde, habe ich nie probiert.
Dazu müsste Dein Modem über TR-069 von der Telekom provisioniert werden. Dazu fehlen ihm aber meist die Daten.
Ich habe ein ZyXEL VMG1312, das ich nicht über die Telekom bezogen habe. Dort fehlen die Angaben zum ACS Server und finden konnte ich die Daten auch nirgendwo.Telekom schaltet PPPoE wohl auf Antrag im Kundencenter ein, wenn man das will.
unter https://kundencenter.telekom.de kann mal das selbst machen:
Automatischer Internet-Zugang
Mit dem automatischen Internet-Zugang müssen ihre Zugangsdaten nicht mehr in ihrem Router (z.B. Telekom Speedport) gespeichert werden. Der Aufbau der Internet-Verbindung erfolgt automatisch. -
Hast Du dazu eine Quelle?
https://www.telekom.com/webinar-All-IP
Das ist aber schon etwas älter …
-
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
Die Doku hatte recht. Allerdings habe ich das ganze auf FreeBSD portiert bzw. kompilierfähig gemacht:
https://github.com/ViToni/mcproxy/tree/portingNehme gerne Feedback dazu ;)
Momentan sind meine Entwicklungsumgebung (10-3) und pfSense (10-1) nicht kompatibel, daher kann ich nicht live testen …
-
Ja da ist doch ein zünftiger Applaus fällig!!
-
:D ;D 8)
zu Entertain 2.0: ich hab nur einen 16MBit Anschluss, aber ich finde die Bildqualität richtig super, ebenso das unkomplizierte Umscvhalten zwischen SD und HD. Nur die Bedienung ist ein wenig gewöhnungsbedürftig.
-
Würde deinen Port des mcproxy gerne testen, hast du eine Anleitung zur Installation?
Leider bin ich auf FreeBSD nicht zu Hause sondern will eigentlich nur eine Pfsense am zukünftigen FTTH Anschluss betreiben. Aktuell unter VDSL 50 hab ich massive Probleme über igmpproxy Multicast an meine 4 Telekom Receiver zu verteilen. Sobald mehr als einer aktiv ist, kommt es zu sporadischen Hängern . -
Frage am Rande:
Ist Entertain bereits am Hybrid-Anschluss verfügbar? Die Telekom-Seite gibt da etwas positives aus, allerdings neigt die Webseite auch manchmal zu Fehlinformationen. -
Nehme gerne Feedback dazu ;)
Hallo, habe mir heute Zeit genommen und eine Entwicklungsumgebung unter FreeBSD 10.3 aufgesetzt, deinen Port heruntergeladen und
kompiliert. Soweit in Ordnung.Das ganze dann auf einer pfSense 2.3.1 konfiguriert und ausgeführt. War ein kurzes Vergnügen ;)
[2.3.1-RELEASE][root@router]/root: ./mcproxy -d
ERROR: failed to add VIF! Error: Can't assign requested address errno: 49
ERROR: failed to add VIF! Error: Can't assign requested address errno: 49
ERROR: failed to set source filter! Error: Invalid argument errno: 22
ERROR: failed to subscribe multicast router groups
Abort (core dumped)Anbei meine Konfigurationsdatei:
######################################
##– mcproxy configuration script --##
######################################
protocol IGMPv3; #IPv4pinstance myProxy: igb0_vlan8 ==> igb1;
und meine Interfacekonfiguration
igb0_vlan8: flags=8843 <up,broadcast,running,simplex,multicast>metric 0 mtu 1500
options=3 <rxcsum,txcsum>ether 0c:c4:7a:6d:02:24
inet6 fe80::ec4:7aff:fe6d:224%igb0_vlan8 prefixlen 64 scopeid 0x9
inet 10.239.22.18 netmask 0xffffe000 broadcast 10.239.31.255
nd6 options=21 <performnud,auto_linklocal>media: Ethernet autoselect (100baseTX <full-duplex>)
status: active
vlan: 8 vlanpcp: 5 parent interface: igb0igb1: flags=8943 <up,broadcast,running,promisc,simplex,multicast>metric 0 mtu 1500
options=400bb <rxcsum,txcsum,vlan_mtu,vlan_hwtagging,jumbo_mtu,vlan_hwcsum,vlan_hwtso>ether 0c:c4:7a:6d:02:25
inet 192.168.1.254 netmask 0xffffff00 broadcast 192.168.1.255
inet6 2003:7a:44c:3300:ec4:7aff:fe6d:225 prefixlen 64
inet6 fe80::1:1%igb1 prefixlen 64 scopeid 0x2
nd6 options=21 <performnud,auto_linklocal>media: Ethernet autoselect (1000baseT <full-duplex>)
status: activeIrgend eine Idee?</full-duplex></performnud,auto_linklocal></rxcsum,txcsum,vlan_mtu,vlan_hwtagging,jumbo_mtu,vlan_hwcsum,vlan_hwtso></up,broadcast,running,promisc,simplex,multicast></full-duplex></performnud,auto_linklocal></rxcsum,txcsum></up,broadcast,running,simplex,multicast>
-
Hi, ich sehe mit mcproxy dasselbe Verhalten, ich würde vermuten, das
die Interface-Erkennung nicht sauber funktioniert - dies Problem ist ja auch im igmpproxy (Bug 6099) vorhanden.
Ggf. müssten man die Codestrecke für die Erkennung aus dem gepatchten igmpproxy in den mcproxy überführen - wobei dann sicherlich allerlei anderes kaputt geht :D -
Nehme gerne Feedback dazu ;)
Hallo, habe mir heute Zeit genommen und eine Entwicklungsumgebung unter FreeBSD 10.3 aufgesetzt, deinen Port heruntergeladen und
kompiliert. Soweit in Ordnung.Das ganze dann auf einer pfSense 2.3.1 konfiguriert und ausgeführt. War ein kurzes Vergnügen ;)
[2.3.1-RELEASE][root@router]/root: ./mcproxy -d
ERROR: failed to add VIF! Error: Can't assign requested address errno: 49
ERROR: failed to add VIF! Error: Can't assign requested address errno: 49
ERROR: failed to set source filter! Error: Invalid argument errno: 22
ERROR: failed to subscribe multicast router groups
Abort (core dumped)…
Irgend eine Idee?
Hi, ich sehe mit mcproxy dasselbe Verhalten, ich würde vermuten, das
die Interface-Erkennung nicht sauber funktioniert - dies Problem ist ja auch im igmpproxy (Bug 6099) vorhanden.
Ggf. müssten man die Codestrecke für die Erkennung aus dem gepatchten igmpproxy in den mcproxy überführen - wobei dann sicherlich allerlei anderes kaputt geht :DÄhnlich aber nicht dasselbe!
Der Fehler rührt daher, dass mcproxy Linux-Eigenheiten nutzt, die es unter FreeBSD nicht gibt.
Das zu adaptieren ist sicherlich aufwendiger als die includes sauber nach OS zu trennen, daher an der Stelle erstmal kein Fortkommen (es sei den jemand möchte das gerne übernehmen, nachdem der erste Schritt schon getan ist ;))
-
Hallo zusammen,
ich habe mir vor ungefähr zwei Wochen eine APU besorgt um zu Hause eine Fritzbox abzulösen. Bei meiner vorhergehenden Recherche hatte ich leider nicht das Problem mit igmpproxy und EntertainTV (Plus) auf dem Radar.
Ich habe meine Informationen zur aktuellen Situation hauptsächlich aus folgenden Quellen zusammengetragen:- Beitrag: pfSense 2.3 mit Telekom Entertain
- Report: #6099
- Blogeintrag: Telekom IPTV mit pfSense
Könntet ihr mir bitte zum Verständnis folgende Erkenntnisse verifizieren? (Entertain (v1.0) = E1, EntertainTV (Plus) (v2.0) = E2)
- Probleme mit igmpproxy
+ bestehen nur in pfSense 2.3.
+ betreffen E1 und E2 gleichermaßen. - E1
+ benötigt IGMPv2 für das Downstream Interface (LAN).
+ funktioniert mit der im Report modifizierten Version von igmpproxy. - E2 benötigt IGMPv3 mit SSM (Source Specific Multicast) für das Downstream Interface (LAN).
- igmpproxy beherrscht
+ Upstream (WAN) IGMPv{2,3}.
+ Downstream (LAN) nur IGMPv2. - Es ist ungewiss, ob igmpproxy IGMPv3 im Downstream unterstützen kann/wird.
- Es existiert derzeit keine geeignete Alternative zu igmpproxy.
- Es ist nicht bekannt welche Komponente AVM oder Telekom in der Rolle des igmpproxy benutzen.
- Außer Speedport und Fritzbox Routern funktioniert kein anderer Router mit E2.
- BNG (Broadband Network Gateway)
+ löst die Einwahl zum Provider per PPPoE ab.
+ der Telekom stellt Multicast und regulären Traffic über VLAN7 bereit.
+ kann bei der Telekom vom Kunden deaktiviert werden um stattdessen PPPoE (VLAN{7,8}) zu nutzen.
Bekannte IGMP proxy Implementierungen:
Versuch einer IGMPv3 Implementierung:
Bis denn
-
Du hast Dir eine Menge Mühe gemacht das mal zusammenzufassen, das finde ich prima.
Ein paar Anmerkungen:
Statt "setzt auf IGMPv2 im Downstream" würde ich eher formulieren, daß Entertain IGMPv2 benötigt, EntertainTV jedoch IGMPv3 mit SSM (source specific Multicast).
Der IGMPproxy kann nicht IGMPv3, daher ist er nicht für EntertainTV geeignet. Dazu gibt es offenbar aktuell auch keine Alternative.
Der Bug #6099 scheint nur bei einer großen Zahl konfigurierter Interfaces relevant sein. Auch mit 2.3 läuft Entertain bei einigen Leuten.
-
Ich habe deine Vorschläge in meinen Beitrag einfließen lassen. Wie sieht es mit den anderen Punkten der Liste aus, liege ich damit richtig?
Der IGMPproxy kann nicht IGMPv3, daher ist er nicht für EntertainTV geeignet. Dazu gibt es offenbar aktuell auch keine Alternative.
Ok, aber habe ich es richtig verstanden, dass igmpproxy zwar IGMPv3 für das Upstream Interface aber nicht für das Downstream Interface unterstützt, was letzten Endes dazu führt, dass E2 nicht funktioniert?
Der Bug #6099 scheint nur bei einer großen Zahl konfigurierter Interfaces relevant sein.
D.h.?
Auch mit 2.3 läuft Entertain bei einigen Leuten.
Dann aber nur E1 und nicht E2, oder?
-
@yay:
Der IGMPproxy kann nicht IGMPv3, daher ist er nicht für EntertainTV geeignet. Dazu gibt es offenbar aktuell auch keine Alternative.
Ok, aber habe ich es richtig verstanden, dass igmpproxy zwar IGMPv3 für das Upstream Interface aber nicht für das Downstream Interface unterstützt, was letzten Endes dazu führt, dass E2 nicht funktioniert?
Ist letztlich wurscht. Hintergrund für das Durcheinander: Der IGMPproxy erzeugt teilweise IGMPv2-Nachrichten direkt selbst (im Downstream) und teilweise mittelbar durch das OS (im Upstream). Letzteres kann je nach OS und Konfiguration auch noch unterschiedlich ausfallen. Was fehlt ist die Implementierung des Source Specific Multicast. Ohne das SSM wird Multicast-Traffic nur durch die Zieladresse unterschieden, mit SSM auch anhand der Absenderadresse. Der IGMPproxy kriegt schon gar nicht mit, wenn ein Client einen Multicast-Traffic nur von einer bestimmten Quelle abonniert und reicht das an den Upstream nicht durch.
Das fehlende SSM sorgt vermutlich dafür, daß EntertainTV nicht funktioniert. Ganz sicher ist das nicht, aber es ist scheinbar der einzige Unterschied.
Die Senderlisten unterscheiden sich bei Entertain und EntertainTV auch in der Angabe der Adressen:
ARD bei Entertain: rtp://@239.35.10.4:10000
ARD bei EntertainTV: rtp://87.141.215.251@232.0.20.35:10000Abgesehen davon gibt es bei EntertainTV diverse Kanäle, die gar nicht mehr per Multicast kommen, nur per Unicast. Da ist der IGMPproxy dann komplett außen vor.
@yay:
Der Bug #6099 scheint nur bei einer großen Zahl konfigurierter Interfaces relevant sein.
D.h.?
Ein Teil der Diskussion in dem Bug hat sich um die Zahl (und auch Benennung bei VLANs) von Interfaces gedreht. Genau habe ich das aber nicht mehr im Kopf.
@yay:
Auch mit 2.3 läuft Entertain bei einigen Leuten.
Dann aber nur E1 und nicht E2, oder?
Ja genau.
-
Könnte denn ein Switch nach der pfSense Box den Job des igmpproxy übernehmen, sofern dieser manged wäre und IGMP Snooping unterstützt?
-
Nein, der Proxy muss zwischen WAN und LAN sitzen
-
Korrekt. Begründung dafür: Das Switch leitet nur Frames weiter, aber er erzeugt nicht selbst welche. Das muß ein Proxy aber tun, z.B. membership queries aus dem WAN beantworten und selbst membership queries erzeugen.
-
@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.
@kdk
Darf ich fragen wie Du das konfiguriert hast?EDIT:
Hier gelöst: https://forum.pfsense.org/index.php?topic=114045.msg634399#msg634399 -
@yay:
[…]
Bekannte IGMP proxy Implementierungen:Versuch einer IGMPv3 Implementierung:
Hier noch einige:
und es gibt noch ein paar mehr, die ich gerade nicht finde ;-)
Die meisten sind jedoch für Linux geschrieben, und deshalb ist es schwierig, sie unter FreeBSD zum Laufen zu bringen, weil es im Netzwerkbereich doch ganz ordentliche Unterscheide zwischen den Systemen gibt…
-
Sorry für das Rauschen, aber was für eine IP Adresse wird denn normalerweise auf VLAN8 zugewiesen? Meine liegt derzeit in einem Klasse A/privat (10.0.0.0.) Bereich. Ist das normal?
