T-HOME über VPN

Sollte etwa tatsächlich für einen so langen Zeitraum der Stream via Unicast übertragen werden?
Nein, sicher nicht... Man kann im Onlinemonitor der Fritz-Box sehr schön beobachten, wie die Fritz-Box nach ein paar Sekunden von Uni- auf Multicast umschaltet... das ist irgendwas anderes

Ab morgen habe ich einen Speedport W920V zum Freetzen & Testen im Haus.
:) Sehr gut.. ich fühle mich nämlich ein wenig überfordert so langsam...:blonk:

Upstream Interface altnet 192.168.110.22/32 (IP des MR) => Das macht keinen Sinn. Warum sollte ich einen Routingeintrag zu einer IP-Adresse und dann noch im selben Subnetz anlegen?!
Ich weiß auch nicht ob das Sinn macht. Das habe ich von hier:
http://wiki.freakempire.de/doku.php/linux/t-home_iptv_ohne_speedport_unter_linux_vdsl
Der hat die IP von seinem Receiver dort eingetragen und bei Ihm scheints zu tun. Außerdem behebt das diese Fehlermeldung.

phyint lan0 downstream ratelimit 0 threshold 1 => ändere das mal testweise wie beschrieben mal auf das aktive Interface, dass du via ifconfig siehst (tiwlanX).
Das scheint aber zu tun. Der MR, der über Kabel an der Box hängt läuft hier direkt neben mir ohne zu hängen... Daher würde ich da nichts mehr ändern... Außerdem habe ich grade nochmal per ifconfig nachgeschaut und tiwlan kommt da auch nicht vor.

Upstream Interface altnet 193.158.35.0/24 => könnte Sinn machen.
Ich glaub, das ist der wichtigeste Eintrag. Seitdem ich den im upstream habe tut der MR über Kabel...

Upstream Interface altnet 217.0.119.194/24 => sehe ich keinen Sinn drin. Könntest du bitte den Eintrag entfernen und probieren?
Jup, scheint auch ohne zu tun... Habe ich jetzt wieder raus.

Bei mir sieht die Server-Config jetzt erstmal so aus:
Code:
quickleave
phyint dsl upstream ratelimit 0 threshold 1
altnet 193.158.35.0/24
altnet 192.168.110.22/32
phyint lan0 downstream ratelimit 0 threshold 1

Ich versuche jetzt mal noch den MR hinter der Brücke zum laufen zu bekommen.
Habe folgendes probiert:
Code:
phyint wdsdw0 downstream ratelimit 0 threshold 1
Das hat aber nicht getan... Dieses Interface taucht bei mir unter ifconfig auch nirgends auf...

Update: Mein Vater ist grade heimgekommen und er möchte jetzt Fußball schaun :) d.h. ich kann jetzt erstmal nichts mehr machen... Vielleicht komme ich später heute Abend noch einmal dazu.
Aber wenn zero°|K3nnY dann selbst testen kann geht das ganze bestimmt iel schneller voran, als wenn ich das mache... :)
 
Zuletzt bearbeitet:
Ich weiß auch nicht ob das Sinn macht. Das habe ich von hier:
http://wiki.freakempire.de/doku.php/linux/t-home_iptv_ohne_speedport_unter_linux_vdsl
Der hat die IP von seinem Receiver dort eingetragen und bei Ihm scheints zu tun. Außerdem behebt das diese Fehlermeldung.
Im gleichen Blog ist folgender Kommentar zu finden:
Link. Der User beschreibt eine funktionstüchtige Konfig ohne MediaReceiver IP im Upstream.

Das scheint aber zu tun. Der MR, der über Kabel an der Box hängt läuft hier direkt neben mir ohne zu hängen... Daher würde ich da nichts mehr ändern... Außerdem habe ich grade nochmal per ifconfig nachgeschaut und tiwlan kommt da auch nicht vor.
Du verwendest ja auch einen anderen Router als ich (FritzBox?). Offensichtlich werden die Interfaces bei dir anders bezeichnet (warum auch immer). Daher gibts bei dir auch kein tiwlanX, sondern es scheint halt lanX zu sein. Eine wichtige Erkenntnis!


Ich versuche jetzt mal noch den MR hinter der Brücke zum laufen zu bekommen.
Habe folgendes probiert:
Code:
phyint wdsdw0 downstream ratelimit 0 threshold 1
Das hat aber nicht getan... Dieses Interface taucht bei mir unter ifconfig auch nirgends auf...
Poste doch mal die Ausgabe von ifconfig

Aber wenn zero°|K3nnY dann selbst testen kann geht das ganze bestimmt iel schneller voran, als wenn ich das mache... :)
Ich habe nächste Woche dummerweise Spätdienst, werde morgen also erst sehr spät oder erst Dienstag zum Testen kommen. Außerdem hab ich keine Bridge zum Testen da...
 
Code:
root@fritz:/var/mod/root# ifconfig
ath0      Link encap:Ethernet  HWaddr BC:05:43:6D:CE:6C
          UP BROADCAST RUNNING ALLMULTI MULTICAST  MTU:2290  Metric:1
          RX packets:14232 errors:0 dropped:0 overruns:0 frame:0
          TX packets:26809 errors:0 dropped:1585 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:5107284 (4.8 MiB)  TX bytes:8998795 (8.5 MiB)

ath1      Link encap:Ethernet  HWaddr BC:05:43:6D:CE:68
          UP BROADCAST RUNNING ALLMULTI MULTICAST  MTU:2290  Metric:1
          RX packets:4414 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1930602 errors:0 dropped:86884 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:1909292 (1.8 MiB)  TX bytes:2627437659 (2.4 GiB)

cpmac0    Link encap:Ethernet  HWaddr BC:05:43:6D:CE:66
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:24479 errors:0 dropped:0 overruns:0 frame:0
          TX packets:704803 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:5625090 (5.3 MiB)  TX bytes:948560398 (904.6 MiB)
          Interrupt:14

dsl       Link encap:Point-to-Point Protocol
          inet addr:192.168.110.1  P-t-P:192.168.110.1  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP ALLMULTI MULTICAST  MTU:1500  Metric:1
          RX packets:34204 errors:0 dropped:0 overruns:0 frame:0
          TX packets:5149 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:38216201 (36.4 MiB)  TX bytes:541338 (528.6 KiB)

eth0      Link encap:Ethernet  HWaddr BC:05:43:6D:CE:66
          UP BROADCAST RUNNING ALLMULTI MULTICAST  MTU:1500  Metric:1
          RX packets:24441 errors:0 dropped:0 overruns:0 frame:0
          TX packets:20919 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:128
          RX bytes:5275681 (5.0 MiB)  TX bytes:11321895 (10.7 MiB)

guest     Link encap:Ethernet  HWaddr BC:05:43:6D:CE:66
          inet addr:192.168.179.1  Bcast:192.168.179.255  Mask:255.255.255.0
          UP BROADCAST RUNNING ALLMULTI MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:174 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 B)  TX bytes:9044 (8.8 KiB)

lan       Link encap:Ethernet  HWaddr BC:05:43:6D:CE:66
          inet addr:192.168.110.1  Bcast:192.168.110.255  Mask:255.255.255.0
          UP BROADCAST RUNNING ALLMULTI MULTICAST  MTU:1500  Metric:1
          RX packets:29644 errors:0 dropped:0 overruns:0 frame:0
          TX packets:39592 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:8436652 (8.0 MiB)  TX bytes:39677003 (37.8 MiB)

lan:0     Link encap:Ethernet  HWaddr BC:05:43:6D:CE:66
          inet addr:169.254.1.1  Bcast:169.254.255.255  Mask:255.255.0.0
          UP BROADCAST RUNNING ALLMULTI MULTICAST  MTU:1500  Metric:1

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:728 errors:0 dropped:0 overruns:0 frame:0
          TX packets:728 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:93122 (90.9 KiB)  TX bytes:93122 (90.9 KiB)

tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet addr:192.168.200.1  P-t-P:192.168.200.2  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP ALLMULTI MULTICAST  MTU:1500  Metric:1
          RX packets:70 errors:0 dropped:0 overruns:0 frame:0
          TX packets:113 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:2928 (2.8 KiB)  TX bytes:3772 (3.6 KiB)

vdsl      Link encap:Ethernet  HWaddr BC:05:43:6D:CE:69
          UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1
          RX packets:2695566 errors:0 dropped:0 overruns:0 frame:0
          TX packets:11894 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:3654293101 (3.4 GiB)  TX bytes:2513410 (2.3 MiB)
          Interrupt:36

wifi0     Link encap:Ethernet  HWaddr BC:05:43:6D:CE:68
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:4430 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1930424 errors:165 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:2095848 (1.9 MiB)  TX bytes:2704365668 (2.5 GiB)
          Interrupt:25 Memory:ba000000-ba010000

wifi1     Link encap:Ethernet  HWaddr BC:05:43:6D:CE:6C
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:19595 errors:0 dropped:0 overruns:0 frame:31934
          TX packets:27762 errors:1 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:6208727 (5.9 MiB)  TX bytes:10163540 (9.6 MiB)
          Interrupt:25 Memory:ba010000-ba020000

Gruß
 
Tja dürfte m.E. wifi0 oder wifi1 sein, ath0 oder ath1 sagt mir nichts. Ob es wifiX oder athX ist kannst du eingrenzen, indem du mit einem Laptop, der über WLAN angebunden ist, die ARP Tabelle anzeigen lässt (Kommando "arp -a")(Meistens ist der AccessPoint aller WLAN Hosts bei Bridge im Netzwerk nicht der Router sondern die Bridge, daher dürfte das zum Erfolg führen). Besser ist noch, wenn du mit einem Rechner an den Lan Port der Bridge gehst und die ARP Tabelle aufrufst. Die MAC Adresse der FritzBox entspricht dann der Hardwareadresse unseres gesuchten Interfaces. Sollte die FritzBox nicht in der ARP Tabelle aufgelistet sein, einfach vorher mal einen Ping in diese Richtung absetzen und nochmal probieren.

Bei mir heist witzigerweise das WLAN Interface am Router "wan" - ich glaube die Firmware ist stark verbuggt...
 
Ich denke das duerfte eine 7390 sein. Ath0/1 sind die beiden 2,4 GHz und 5 Ghz Chips. ath ist wohl das physikalische Interface und wifi das logische. (ich habe uebrigens den den selben ifconfig auf meiner 7390) In der tat sind die interfaces da ein bischen anders als sonst. Ich sehe aber ganz interessiert die entwicklung des altnet parameters hier, scheint doch ein ischen mehr zu koennen. Wenn ich das richtig verstehe muesste mal also immer die jedweilige source des jedweiligen Nachbarn hinzufuegen ? (Sprich Client muesste muesste die selben eintraege wie der Server haben PLUS die IP Ranges der Server FB.

Ich bin auch schon ganz gespannt. Ich kann leider nicht weiter testen (bin schon ganz wild das zu tun) weil ich den MR300 auf der gegenseite nicht anmachen kann um zu sehen ob da bild kommt ;) Der ist 12.000 km weg in meinen privat Raeumen ;)

/Gompf
 
Es ist ja noch nicht geklärt ob nun Bridge oder Routing Mode im VPN. Ich favorisiere Bridge Mode, da wäre das Upstream-Interface mit altnet 193.158.35.0/24. Da im Bridge Mode Server- und Client-Subnetz identisch sind, ist kein weiter Routing Eintrag notwendig.
Routing Mode wird vermutlich zu den bereits erwähnten Problemen führen. Sollte es wider Erwarten doch möglich sein, dann mit altnet $servernetz clientseitigt und altnet 193.158.35.0/24 serverseitig.
 
Ich verstehe ChrisZ schon, denn auch bei mir waere ein Bridgemode mit gleichen IPs nicht wirklich was ich wollen wuerde, schon wegen DHCP und allem anderen routing. Aber selbst wenn, das hatte ich wie gesagt auch nicht hinbekommen, das die FB wirklich als bridge getan haette. Ich hatte eine 5124 (hinter einer 7390) dazu verwendet nur alle meine Geraete hinter der 5124 per OPENVPN zu bruecken. Das ging nicht, und ich habe es oft versucht, habe den tunnel nie zum laufen gebracht, sobald ich wirklich bruecken wollte. TAP ohne bruecken ging.

altnet $servernetz clientseitigt und altnet 193.158.35.0/24 serverseitig.

Genauso stell ich mir das vor, ja. Allerdings wuerde ich zur Not am Clientnetz auch noch das openVPN Netz angeben. Ich denke da der igmpproxy es ja wohl umsetzt wuerde in dem Fall die ganze sache als Nachbar zu sehen sein. Schoen waers. Ich denke die Einschraengung wie im Man ist wenn es ueber mehrere Hobs gehen wuerde zwischen den zwei igmpproxys. Schoen waers jedenfalls ;) Hoffentlich ist nicht der Wunsch der Vater des gedanken ;)

/Gompf

p.s.: Schoen das dieser Thread mittlerweile so alive ist !
 
Zuletzt bearbeitet:
Tja dürfte m.E. wifi0 oder wifi1 sein, ath0 oder ath1 sagt mir nichts. Ob es wifiX oder athX ist kannst du eingrenzen, indem du mit einem Laptop, der über WLAN angebunden ist, die ARP Tabelle anzeigen lässt (Kommando "arp -a")(Meistens ist der AccessPoint aller WLAN Hosts bei Bridge im Netzwerk nicht der Router sondern die Bridge, daher dürfte das zum Erfolg führen). Besser ist noch, wenn du mit einem Rechner an den Lan Port der Bridge gehst und die ARP Tabelle aufrufst. Die MAC Adresse der FritzBox entspricht dann der Hardwareadresse unseres gesuchten Interfaces. Sollte die FritzBox nicht in der ARP Tabelle aufgelistet sein, einfach vorher mal einen Ping in diese Richtung absetzen und nochmal probieren.

Bei mir heist witzigerweise das WLAN Interface am Router "wan" - ich glaube die Firmware ist stark verbuggt...

Bingo! Ist eindeutig wifi0 bei mir.... Die SpeedportBridge hat auch eine kleine html-Oberfläche fürs Setup und da ist die MAC vom wifi0-interface eingetragen.
Ich bin jetzt leider nicht mehr bei meinen Eltern sondern wieder 160km entfernt in meiner Wohnung und kann daher leider nicht mehr vor Ort testen. Ich werde aber in den nächsten Tagen nochmal versuchen, den Multicast hier her ins Client-Netz zu bekommen. Gibt ja jetzt ein paar neue Ansätze, die funktionieren könnten.
 
Zuletzt bearbeitet:
Habe gestern zum Testen einen Speedport W920V erhalten und umgeflasht.
IGMPProxy habe ich auf folgende Minimalkonfiguration gesetzt:

Code:
quickleave
# upstream = Internet Device
phyint dsl upstream ratelimit 0 threshold 1
altnet 193.158.35.0/24;
# xxxY ist das LAN-Interface
phyint xxxY downstream ratelimit 0 threshold 1

Der Multicast läuft wie erwartet unterbrechungsfrei, Umschalten etc. funktioniert soweit ebenfalls störungsfrei.

Damit ist die Konfigurationsfile für's Netz ohne VPN optimiert. Momentan fehlt's mir an einem Client Netz bzw. an Hardware für mein Ziel-Clientnetz.

Des Weiteren überlege ich, ob zwangsläufig OpenVPN zum Einsatz kommen muss, oder ob auch ein IPSec VPN a'la AVM machbar wäre (Hintergrund ist der geringe Flash Speicher auf den Speedport's 701/721/900, der den Einsatz von OpenVPN mangels USB Schnittstelle schwierig macht)
 
Supi!
Damit hätte man ja schonmal einen wichtigen Teil geschafft.
Ich wollte gestern Abend noch versuchen, den Multicast zu mir ins Clientnetz zu bekommen, bin aber leide rnicht mehr dazu gekommen.

Wenn man die AVM-VPN Verbindung nutzen könnte, wäre das natürlich super, weil es viel einfacher umzusetzen wäre als mit OpenVPN und viel weniger Speicher benötigt. Alleine die Auslagerung der Freetz-Packages auf einen USB-Stick zum Laufen zu bekommen hat mich sehr viel Zeit gekostet.

Eine grundlegende Frage hätte ich jetzt mal noch zum IgmpProxy: Wie kann man den im "Hintergrund" laufen lassen, also so wie die anderen Dienste im Freetz? Und es müsste doch (für jemand mit Ahnung) recht einfach sein, eine IgmpProxy-Gui fürs Freetz zu scrheiben, oder? Fände ich z.B. super nützlich.

Heute Abend kann ich hoffentlich wieder etwas neues berichten :)
 
Zuletzt bearbeitet:
habe den Thread aufmerksam durch gelesen,aber mit euerm Wissensstand kann ich leider nicht mit halten.
Was mir aber jetzt unklar ist,funktioniert denn nun das Liga Total schauen im Ausland?
 
Supi!
Wenn man die AVM-VPN Verbindung nutzen könnte, wäre das natürlich super, weil es viel einfacher umzusetzen wäre als mit OpenVPN und viel weniger Speicher benötigt. Alleine die Auslagerung der Freetz-Packages auf einen USB-Stick zum Laufen zu bekommen hat mich sehr viel Zeit gekostet.

Daran hatte ich damals auch gedacht (was natuerlich Sinn macht wenn man es auch mit tun statt tab hinbekommen wuerde). Aber ich habe zu AVM VPN einfach kein physicalishes interface indentifizieren koennen. Auch ist das (jedenfalls bei mir) Multipoint<>Multipoint.

/Gompf
 
,funktioniert denn nun das Liga Total schauen im Ausland?

In der Theorie geht dass, wenn der ANschluss es hergibt auf beiden Seiten. In der Praxis must Du noch ein bischen mitlesen bis einer Juhhuu Schreit.

/Gompf
 
Nabend zusammen,

also bin gerade fröhlich am teste, bis jetzt tut sich aber noch nichts.

Ich habe mir nochmal die Beiträge von Fux durchgelesen und er schreibt in #12:
Masquerading, damit T-Com-Router passende Absender-IP sieht:
Code:

iptables -t nat -A POSTROUTING -s <ip_der_box> -o eth1 -j MASQUERADE

Frage an die Leute mit Ahnung: Brauchen wir sowas nicht auch? Ich habe NHIPT auf der Server-FritzBox und IPTables auf der Client-FritzBox bereits installiert...
 
Das ding bedeutet nur das der gesammte inet traffic deines receivers ueber das VPN gerouted wird. das kannst Du so machen (wenn Du entsprechende Kernel Module und Optionen einkompilierst (bei der 7390 nicht moeglich im Moment).

Da Du aber bereits Zappen kannst und unicast bereits bekommst ist dieser eintrag egal, Du hast offensichtlich den gesammten traffic umgeleitet. Allerdings statische routen in den tunnel hierfuer muessten auch reichen :

Code:
93.215.192.0/19
193.158.137.14/32
217.6.167.160/27
87.140.255.0/25
212.184.168.0/24
193.158.34.0/23
87.141.128.0/17

/Gompf
 
Ahso, okay, danke

Update:
Also von mir kommt heute Abend wohl kein "Juhuu!" mehr...
Habe die letzten 2h rumprobiert, getan hat sich aber nichts.

Server-Config:
Code:
quickleave
phyint dsl upstream ratelimit 0 threshold 1
        altnet 193.158.35.0/24

##      Für MR im Server-Netz an lan0
phyint lan0 downstream ratelimit 0 threshold 1

phyint tun0 downstream ratelimit 0 threshold 1
        altnet 192.168.200.0/24
Habe mal mit und mal ohne "altnet 192.168.200.0/24" probiert.

Client-Config:
Code:
quickleave
phyint tun0 upstream ratelimit 0 threshold 1
         altnet 192.168.200.0/24
         altnet 192.168.110.0/24

phyint <INTERFACE> downstream ratelimit 0 threshold 1

Als <Interface> (habe eine Fritz 7170) kommt meiner Meinung nach cpmac0, eth0, lan, lan0 oder wan in Frage. (Habe mein Notebook an die gleiche Buchse gehängt, wie später der MR und einen "arp -a" gemacht und dann die angeziegten MAC-Adressen mit den Mac-Adressen der Interfaces auf der FritzBox nach einem "ifconfig" verglichen. Die genannten Interfaces haben alle die gleiche MAC und stimmen mit der nach einem "arp -a" angezeigten überein.) Habe alle Interfaces der Reihe nach durchprobiert.
Außerdem habe ich in der Client-Config im upstream verschiedene Sachen ausprobiert:
Code:
altnet 192.168.200.0/24
altnet 192.168.110.0/24
altnet 193.158.35.0/24 ##<- Beitrag von Fux, der hatte diese IP auch im upstream des Clients.

Leider hat nichts getan...

Vorschläge?
 
Zuletzt bearbeitet:
habe den Thread aufmerksam durch gelesen,aber mit euerm Wissensstand kann ich leider nicht mit halten.
Was mir aber jetzt unklar ist,funktioniert denn nun das Liga Total schauen im Ausland?

Also was schonmal geht:
Alles aus dem TV-Archiv, Webradio und glaube auch Videoload.
Man muss dafür nur die beiden IPs 217.6.164.43 und 80.156.86.96 durch den Tunnel routen. Danach bootet der MR im Client-Netz ohne Probleme (also die Meldung "Kunde nicht vorhanden" kommt nicht und man kann wie gesagt aufs Archiv, WebRadio und Videoload zugreifen. Interessanter weise kommt der Stream -nicht- durch den Tunnel sondern durch die eigene Leitung (bei mir eben dsl). D.h. man kann schonmal alle Bundesliga-Spiele als Aufzeichnung anschauen.
Gruß
 
Klasse hört sich gut an
und hast du VDSL?
 
Zuletzt bearbeitet:
@dl2sbl
Entertain Comfort Standard v. T-com inkl. DSL 16000,Liga total
S/R 29/31, Dämpf: 22/15

Du wirst wohl auf VDSL umsteigen muessen...

@ChrisZ
Die Unicast Stremas gehen in der tat auch ueber den eigenen provider sobald der Receiver authorized ist, allerdings wuerde ich mich darauf nicht verlassen, die Telekom wird das sicher irgentwann mal mitkriegen (aber als ich vor 4 Monaten mit den ersten Tests angefangen habe, war das auch schon so). Trotzdem wuerde ich Dir empfehlen die ganzen bloecke oben zu Routen, dann bist du auf der sicheren Seite. Frage : Wo kommt die IP 80.156.86.96 her ? die ist naemlich in keinem der Bloecke, wuerde also nicht ueber VLAN 8 rausgehen....

/Gompf
 
muss ich in Dl erst mal checken wegen VDSL
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.