tr069 verstehen und nutzen

hermann72pb

IPPF-Promi
Mitglied seit
6 Nov 2005
Beiträge
3,724
Punkte für Reaktionen
16
Punkte
38
Hallo zusammen. Ich hatte heute mit einer 7141 gespielt, die ich für 1und1 einrichten sollte und wie immer mit ds-mod versehen wollte. Da das bekannte tr069-Problem bei 1und1 Boxen existiert, ich aber den bequemen Assistenten bei der Ersteinrichtung nutzen wollte, hatte ich zunächst die jungfreuliche ungemoddete Box mit 1und1 über Zugangscode verbunden. Der Anmeldevorgang hat zwar diesmal nicht geklapt, dies hat aber andere Gründe, die hier nicht näher diskutiert werden sollen. Dadurch war ich aber mit diesem verdammten Assistenten zwangsläufig etwas länger beschäftigt. Und wie immer kommt man dabei auf dumme (oder vielleicht auch nicht) Gedanken. Und da fragte ich mich, warum hat man denn seit geräumter Zeit diesen Assistenten im ds-mod verdrängt, ohne zu verstehen, wie er überhaupt funktioniert und was sich AVM dabei gedacht hat?
Ich habe diesen Thread eröffnet, um der Sache mit tr069 näher zu kommen, vielleicht seine interne Mechanismen zu verstehen und womöglich auch für ds-mod zu nutzen.

Meine bisherige Erkentnisse:
1. Mit tr069 gibt AVM den Internetbetreibern die Möglichkeit die Boxen automatisch aus der Ferne einzurichten und danach auch fernzuwarten (ja, auch fernwarten! s. das Bilderchen unten über automatische Updates).
2. 1und1 nutzt diese Möglichkeit aktiv für ihren Einrichtungsassistenten (übrigens eine ganz gute Sache!) und wie man aus dem Bilderchen sieht plant auch darüber Boxen automatisch upzudaten.
3. Das ganze funktioniert anscheinend über eine ssh-Verbindung, weil Probleme zwischen dem Mod und tr069 auftreten, wenn libavmssl ausgetauscht wird.
4. Als meine Einrichtungsversuche scheiterten, hatte ich eine interessante Sache beobachtet:
1und1 vergibt für den Assistenten ein Start-Code der Art: ABCD-EFGH-IJKL
Im Kennungsfeld der Verbindung am Anfang stand als Kennung 1und1/[email protected] Das Passwort ist vermutlich GHIJKL. Das heißt, die Box meldet sich beim ersten Mal bei 1und1 mit diesem Code an, wobei ein Teil davon als Kennung und ein Teil als Passwort benutzt werden. Darauf hin kriegt die Box eine Verbindung zum SSH-Server von 1und1, wo sie sich einerseits die Daten holt, andererseits einige Sachen (VOIP-Accounts) anlegt und aktiviert.

Ideen (was kann man davon nutzen und was kann man damit machen):
1. Man könnte bestimmt diesen Registrierungsvorgang auch vom PC starten, wenn man die internen Vorgänge genauer wissen würde. Eine DSL-Verbindung mit oben diskutierter Kennung und eine anschließende Verbindung zu 1und1-SSH-Server wären dann realisierbar. Wofür? Wenn man tr069 komplett von der Box weg entfernt und dennoch den Assistenten starten muss, um den Account (nicht die Box) einzurichten. Diese Geschichte wäre hier jedoch OT, weil es sich dann komplett auf dem PC abspielen würde.
2. Man könnte andererseits auf der Box den 1und1 Serverstring mit dem String von seinem eigenem Server ersetzen und diesen Server so programmieren, dass z.B. automatische Updates von dort geholt werden und nicht von 1und1. Vorteilig wäre es für diejenigen, die neben Ihrer Box noch die Boxen von der Mutti, vom Schwager, vom Freund und vom wem weiß ich noch betreuen. Dann kann man das neue ds-mod Image auf seinen Server irgendwo im Netz hochladen und die Boxen holen es automatisch ab.

Es gibt bestimmt noch andere Möglichkeiten. Ich will damit nur anreizen, dass AVM mit diesem tr069 eigentlich "verdeckt" ähnliche Sachen macht, die hier im mod angeboten werden (ssh, fernwartung, remote-update). Man sollte es nicht komplett verwerfen, sondern versuchen soweit es geht zu verstehen und anzuwenden.
Ich weiß, dass der Weg nicht leicht ist, weil die Sourcen für diese tr069-mechanismen wahrscheinlich komplett fehlen. Ich glaube aber wenig, dass AVM sich ein eigenes SSH ausdenkt. Eher die bauen auf einer klassischen Lösung auf, so dass wenn man weiß, was da gesendet wird, es nachbilden könnte.

Damit eröffne ich hier die Diskussion zu dem Thema und freue mich, wenn hier auch weitere Kenntnisse über tr069-Internas einfließen werden.

MfG
 

Anhänge

  • autoupdate.jpg
    autoupdate.jpg
    38.6 KB · Aufrufe: 441
aehm, 'tschuldigung das ich mal wieder oberlehrerhaft mich einmische, aber ...nur so... TR-069 ist ein Standard, das kann man alles nachlesen.
1und1 hat wenn ueberhaupt hoechstens irgendwelche Vendor Specific extensions.

==> Hier anfangen, links folgen, ansonsten bevorzugte Suchmaschine benutzen

http://en.wikipedia.org/wiki/TR-069

Alles nich so schwer ;-)

bye
-slz
 
gut zu wissen... Und den Namen für den Standard haben sie wiederum passend gefunden "technical report"...
@masterSLZ: Bist du denn Experte auf dem Feld oder weiß du nur zufällig von diesem Standard?
Mögen sich bitte die Experten melden und äußern, ob das was ich oben geschrieben habe machbar ist, oder ob da ein grundsätzlicher Denkfehler vorliegt.
Leider habe ich keine Kenne und keine Zeit dazu den tr069 vollständig zu lesen. Das was ich jedoch diagonal überflogen hatte bestätigte nur meine Vermutungen aus dem ersten Post.

Meine weitere Studie von tr069.cfg ergab, dass es wahrscheinlich zunächst eine https-Verbindung mit Benutzernamen und Passwort aus DSL-Zugangsdaten aufgebaut wird (im Standard ist die Rede von mehreren Möglichkeiten, nicht nur https). Außerdem werden zwei SSL-Zertifikate für irgendwas benutzt.

Ich schaue mal weiter.

MfG
 
Der Link ist gut, jetzt weiß ich wenigstens auch, was die Abkürzung bedeutet. Wie der Einrichtungs-Assistent funktioniert, war mir vorher bereits klar, ich habe ihn bei der Ersteinrichtung meiner Box verwendet. Unnötig, aber tatsächlich sehr bequem. Seitdem habe ich immer Voll-Backups meiner Konfiguration über Backup/Restore im Mod gemacht, das ist noch einfacher, denn nach der Verbindung will ja noch der Rest der Box eingerichtet werden.

Mit den Zertifikaten wird geprüft, ob auch die Verbindung zum richtigen Server aufgebaut wurde (Authentifizierung): Vereinfacht gesagt, müssen die auf der Box gespeicherten Public Keys zu den privaten Server Keys passen. Damit wird sichergestellt, daß einem keine "falsche" Firmware untergeschoben wird von außen.
 
Ich bin weder Entwickler/Programmierer noch Protokollexperte, ich bin nur Engineer der die Protokolle dann in den Netzwerken die ich baue benutzt ;-)

Es hat mich hier eigentlich nur getriggert, das offenbar das Missverstaendnis existiert, das TR-069 hier irgendwas hochgeheimes von AVM oder 1und1 ist, was nicht der Fall ist.

Grundsaetzlich ist der Standard gut beschrieben, wenn jemand den Server-Part nachprogrammiert spricht absolut rein gar nichts dagegen das ueber den eigenen Server laufen zu lassen von den Fritzboxen aus (oder jedem beliebigen anderen CPE wo man die Server aendern kann).
Mir ist allerdings keine (Open-Source) Implementation bekannt. Das wird also einige Mannstunden brauchen.

Ob es euch das Wert ist, weiss ich nicht.
Bei der Implementation bin ich keine Hilfe aus eingangs genannten Gruenden.
Ich sitze auch normal am anderen Ende der Leitung und beschaeftige mich seltenst mit Enduser Problemen, weshalb ich mich hier auch mit Posten sehr zurueckhalte, weil das hat mir nur eine Arroganz-Medallie zuletzt eingebracht von irgendeinem komischen User :)

bye
-slz
 
kriegaex schrieb:
Mit den Zertifikaten wird geprüft, ob auch die Verbindung zum richtigen Server aufgebaut wurde (Authentifizierung): Vereinfacht gesagt, müssen die auf der Box gespeicherten Public Keys zu den privaten Server Keys passen. Damit wird sichergestellt, daß einem keine "falsche" Firmware untergeschoben wird von außen.

Und es könnte sogar im von hermann72pb vermuteten Sinne nützlich sein, wenn a) der Anwender die updateberechtigten Keys vergeben könnte und es b) die Sicherheit (beispielsweise in Form der Offenlegung des Quellcodes) gäbe, dass keine weiteren Hintertüren (in Form "alternativer" Keysets) mehr offen sind. Die Konfiguration automatisch vom Provider zu bekommen ist die eine Sache. Ihm (möglicherweise ohne sich dessen bewusst zu sein) die Berechtigung zum Firmwareupdate auf dem eigenen Besitz und Eigentum zu geben, hat eine ganz andere Qualität. Solange der tr069-Kram nicht im Quellcode veröffentlicht ist, würde ich persönlich dafür plädieren, es so ersatzlos wie möglich aus der Firmware zu entfernen, statt Energie auf seine eventuelle Unterstützung zu verschwenden.

Ansonsten verweise ich auf das, was telepolis schon im März dazu schrieb:
http://www.heise.de/tp/r4/artikel/24/24763/1.html
 
Ich sehe das genauso. Die Keys zu ändern, wäre ja kein Problem, und wenn wir einen selbst gebastelten Update-Server hätten, könnten wir leicht eine Authentifikation gegen diesen arrangieren. Aber da wir das nicht vorhaben, lassen wir es mal gut sein...
 
Ich wollte auch nicht, dass daraus ein zentraler ds-mod-Update-Server für alle entsteht. Das dürfen wir auch nicht. Es ging mir darum, was ich oben beschrieben hatte: für private Zwecke, um Paar Verwandte und Bekannte abzudecken. Und wenn man den Serverpfad in tr069.cfg gegen sein eigenes ersetzt, macht man den "Bundestrojaner" auch dazu noch unwirksam, selbst wenn die tr069-Geschichte laufen würde.
Mir ging es auch nicht darum, dass alle jetzt wie verrückt anfangen diese Funktion zu programmieren, vor allem wenn keine Quellen da sind und auch nicht zu erwarten sind. Aber mir persönlich macht schon etwas Spass Reverse-Engineering in dieser Sache zu betreiben. Deswegen versuche ich hier am Ball zu bleiben und nerve euch doch mit ein Paar fragen. Es bleibt euch überlassen, ob ihr meine Fragen ignoriert. Auch dafür werde ich Verständnis haben. Nun konkret zur Sache:

Mir ist es gelungen auf der https-Seite von 1und1 mich mit meinen Benutzerdaten anzumelden. Darauf hin bekomme ich im Browser nur
Code:
And now... Some Services

    * TR069ACSPort (wsdl)
          o getRPCMethods
          o inform
          o transferComplete
(s. auch Bild) zu sehen. Damit komme ich aber nicht weiter.
Für mich heißt es, dass über https eine primäre Anmeldung bei 1und1 nur mit dem Benutzernamen und mit dem Passwort erfolgt. Für weitergehende Massnamen ist wahrscheinlich die Autorisierung mit Zertiffikaten erforderlich. Aber wird es denn auch über https gemacht? Zusätzlich zu Passwort-Methode? Oder wird da so eine Art von SSH-Tunnel aufgebaut?
Alexander, du sagtest, dass für dich die Sache mit Zertiffikaten klar ist. Kannst du da mehr darüber sagen, wenn du es verstanden hast? Oder kann sich hier bitte jemand äußern, der sich mit https-Servern auskennt?

Danke im voraus!

MfG
 

Anhänge

  • acs1-online.jpg
    acs1-online.jpg
    21.6 KB · Aufrufe: 228
Die Approved Technical Reports (TR) des DSL-Forums enthalten auch TR-069 sowie eine Ergänzung (Amendment) sowie diverse Zusatz-Spezifikationen. Viel Spaß beim Stöbern.

Kurz gesagt, handelt es sich um eine SAOP-basierte RPC-Implementierung. Die Spezifikation erklärt, welche Kommandos ein Server an einen Client (Fritz!Box) senden kann, z.B. Reboot u.v.m. Auch die Client-Requests, die ein Server verstehen muß, sind aufgeführt. Was wie wo wann signiert wird, wird auch erklärt. Ich habe es nur überflogen, kenne mich mit SOAP nicht besonders gut aus. Aber ich denke, es sollte mit einer Skriptsprache mit SOAP-Layer oder mit Java möglich sein, einen Test-Client zu schreiben, der sich ein wenig mit dem Server unterhalten kann - wenn man zu sowas Lust hat...
 
Zuletzt bearbeitet:
Ok, erstmal ein kurzer Hinweis auf meinen Thread.

Um hier ein paar Missverständnisse auszuräumen und etwas technischen Background zu bringen:
TR-069 verwendet keine SSH-Verbindungen, sondern SSL/TLS Verbindungen über TCP, wobei die Verwendung von SSL/TLS optional ist. Für die RPC wird in TR-069 SOAP über HTTP verwendet.

Ich fasse hier mal zusammen, für was TR-069 gedacht ist:
1.) Automatische Konfiguration
2.) Software/Firmware Image Management
3.) Status- und Leistungs-Überwachung
4.) Diagnose-Zwecke
 
Daß er die ganze Zeit von SSH gesprochen hat, ist mir gar nicht aufgefallen. Das ist Humbug, klar. Sollte durch meine Anmerkung bzgl. SOAP und seine Erkenntnis, daß es über HTTPS läuft, ja auch klar sein. Übrigens hat nicht nur die englische Wikipedia einen Übersichtsartikel zu TR-069, sondern auch die deutsche: http://de.wikipedia.org/wiki/TR-069
 
1. Die deutsche WIKI ist nicht so vollständig, wie die englische.
2. Ich bin weit nicht der Experte in Protokollen und dieses "technical report" kann ich nur schwer lesen, weil dort in einem Haufen der unnötigen Details (zumindest für mich in diesem Fall) der rote Faden verloren geht.
Aber soweit kam ich schon, dass ich die Anzeige im Browser (s. Post #9) als ACS-Antwort für den Fall "ACS implementing only the baseline methods" identifizieren kann. Also steckt das Ganze bei 1und1 anscheinend noch in Kinderschuhen, sodass momentan keine "reboots" und "downloads" möglich sind.
3. SSL scheint bei 1und1 nicht nur optional zu sein, sondern wird tatsächlich benutzt (https). Mit SSH hatte ich mich falsch ausgedruckt, bzw. war etwas verwirrt, ich meinte SSL-Zertiffikate, die für mehrere SSL-basierte Sachen (SSH, https, OpenVPN) benutzt werden. Meine Frage dazu scheint jedoch irgdendwie untergegangen zu sein. Deswegen wiederhole ich sie nochmal:
Wofür werden die Zertiffikate benötigt, wenn man sich per HTTPS mit user/pwd identifizieren kann und auch eine Antwort vom tr069-Server bekommt? Gibt es noch eine zweite Etage der Autorisierung?

MfG
 
HTTPS ohne Zertifikate geht gar nicht. Zumindest der Server muß sich dem Client gegenüber durch ein Zertifikat ausweisen. Client-Authentifizierung ist optional und für unsere Diskussion momentan außer Betracht, weil von 1&1 nicht eingesetzt. Das Server-Zertifikat von 1&1 kannst Du Dir übrigens nach dem HTTPS-Login bequem im Browser anschauen, indem Du auf das Schloß-Symbol unten im IE klickst. Bei anderen Browsern geht es analog. Daß dem Zertifikat seitens des Browsers vertraut wird, liegt darin begründet, daß das zugehörige Root-Zertifikat des Ausstellers vorinstalliert ist im Browser und somit als vertrauenswürdig gilt.

Wie kann aber die Fritz!Box prüfen, ob der Server der ist, auf dessen Benutzung sie werksseitig eingerichtet wurde? Ebenfalls durch ein "trusted certificate", dessen Pfadangabe in tr069.cfg steht:
Code:
trusted_ca_file = "/etc/default/1und1/root_ca.pem"
Damit kann die Fritz!Box prüfen, ob der Server der richtige ist und nicht etwa ein "man in the middle" sich für den 1&1-Server ausgibt.

Da mit Client-Zertifikaten nicht gearbeitet wird - es müßte zigtausende (pro Box eine) davon geben, deren Gegenstücke der 1&1-Server alle kennen müßte - authentifiziert sich der Kunde (nicht die Box!) gegenüber 1&1 durch seine Zugangsdaten. Somit kann jegliche Kommunikation einer Fritz!Box mit dem Server einem Kundenkonto zugeordnet werden. Wären hingegen Client-Zertifikate auf der Box gespeichert und würden diese verwendet, könnte die Hardware identifiziert werden, nicht aber der Kunde, weil man Hardware ja weiter verkaufen kann. Außerdem gäbe es Probleme beim Firmware-Update: Das Zertifikat pro Box müßte immer erhalten bleiben, d.h. in die neue Firmware übernommen werden. Das ist unpraktikabel und ginge nur, wenn das Zertifikat fest in die Box "eingebrannt" wäre, ähnlich der IMEI beim Handy, nur ein größerer Datensatz.

War das genau genug? In die Grundlagen asymmetrischer Kryptographie möchte ich hier nicht einsteigen, das würde zu weit führen. Ich kann ja mal meinen alten Einsteiger-Artikel aus der früheren Zeitschrift "IT-Security" (8 Seiten, glaube ich) herauskramen, aber mit diesem Forum hätte das wenig zu tun.

Nochmal eine kleine Ergänzung als Quiz des Tages: Wer errät, wie man mit einer eleganten (und gewollten) Man-in-the-Middle-Methode schön (im Klartext) protokollieren kann, wie die Kommunikation zwischen Fritz!Box und 1&1-Server abläuft?
 
Zuletzt bearbeitet:
@kriegaex

ich wuerd sagen: nen transprenten proxy in die verbing fritzbox-server einschleifen und der firzbox gleich von anfang an das cert von dem proxy "mitgeben" dann sollte mans als klartext bekommen.
 
@Alexander: Danke für die Lektüre. Jetzt habe ich es mit diesen Zertifikaten in tr069.cfg kapiert. Die Box braucht sie, der Browser nicht. Mehr will ich darüber auch nicht wissen.
Du sprichst mir aber gerade aus dem Munde mit deiner Quiz-Frage. Das wollte ich auch nachfragen. Denn wenn man weiß, was da die Box beim 1und1-Server nachfragt, kann man es evtl. mit den Browser-CGI-Nachfragen (oder auch mit einem Skript) nachbilden.
@bofh: Kannst du uns bitte etwas mehr Informationen geben? Paar Namen / Links von diesen Proxies. Und vielleicht etwas mehr über die Zertifikate. Muss dann diese Proxy die gleichen Zertifikatte haben wie 1und1-Server? Kann eigentlich nicht. Das heißt, die Proxy würde mit einem eigenen Zertifikat mit der Box kommunizieren (dafür neue Zertifikate erstellen), dann die Daten im Klartext haben und sie anschließend weiter verschlüsselt mit dem 1und1-Zertifikat an 1und1-Server weiter geben. Gibt es gute SSL-fähige-Proxies auch unter Windows? Sonst kann man natürlich es unter Linux machen.

MfG
 
Hallo,

ich finde den Thread erst jetzt, muss mich aber beruflich momentan ein bisschen mit TR069 beschäftigen. Von einer ernsthaften Umsetzung ist das Projekt aber noch mindestens 6 Monate entfernt. Deshalb würde ich mich gern frühzeitig in die Entwicklung mit einklinken, da kann ich vielleicht noch was lernen. ;)

Ergänzend zu den hier diskutierten Fakten gibt es auch TR069 Clients, die eine UPD Übertragung erlauben.
Der Client wendet sich zu bestimmten, definierten Ereignissen (BOOTSTRAP, PERIODIC) an den Server mit einer Anfrage nach Neuigkeiten. "Echte" Aktionen, wie Firmwareupdates, Konfigurationsupdates oder anderes werden aber vom Server ausgelöst.
Da lässt sich auch wesentlich mehr realisieren, als reine Routerkonfiguration, so denkt ein US-amerikanisches Konsortium aus Internetprovidern und Energieversorgern momentan darüber nach, per TR069 eine Zählerfernauslesung zu realisieren.

Eine Freeware-Implementierung ist mir momentan auch nicht bekannt, weder für den Server, noch für den Client.

bofh schrieb:
ich wuerd sagen: nen transprenten proxy in die verbing fritzbox-server einschleifen und der firzbox gleich von anfang an das cert von dem proxy "mitgeben" dann sollte mans als klartext bekommen
Da bin ich mir nicht sicher, ob das funktioniert. Wie stellst du dir die Realsierung genau vor? Du willst, dass die SSL Sitzung bereits im Proxy terminiert? Und der Proxy baut dann seinerseits eine zum 1&1 Server auf?

Viele Grüße

Frank
 
Die Dokumentation auf dslforum.org finde ich nicht so toll. Obwohl es mehr als 100 Seiten sind, gibt es keine Anwendungsbeispiele. Ich habe mich mit einem einfachen Trick in die Materie eingearbeitet und einiges über die TR-069 Funktionsweise erfahren können:

1. Auf dem CPE (z.B. Fritz!Box 7170) den Intervall von TR-069 so einstellen, dass alle 30 Sekunden eine Inform an den Server gesandt wird. Die ACS Server Adresse wird natürlich auf einen eigenen Server umgebogen, auf dem ein Apache läuft...

2. Jetzt kann der Inform Request entweder mit ngrep oder mit einem kleinen CGI Script angezeigt werden. Als Antwort muss nun eine InformResponse an das CPE gesendet werden. Wie diese auszusehen hat, ist in der Doku unter Annex A beschrieben. Wichtig: bei AVM muss dieselbe Sequenz geliefert werden, die im Header des Inform Request steht!

3. Sobald ein gültiger InformResponse beim CPE angekommen ist, gilt die Session als gültig und der ACS kann nun nach Belieben das CPE abfragen. Als erstes am besten mit GetRPCMethods. Mit GetParameterValueRequest lassen sich einzelne Konfigurationswerte des CPE auslesen. Bei einem AVM 7170 sind dies mehr als 400!

Auch mit einer eigenen CPE TR69 Software liessen sich allerlei Spiele spielen, zum Beispiel dem Provider ein "seltsames" Modem vorgaukeln...
 
@bstocker: zur Dokumentation gebe ich dir Recht. Aber das ist eben "Technical Report", kein "Application Notes". Die Ingeneure und Programmer sind eben so, dass es mit der Doku meistens nicht deren Ding ist. Sonst wären sie Deutschlehrer oder Schriftsteller geworden. Aber zurück zum Thema.
Hast du es bereits alles gemacht, oder sind es nur Ideen?

zum 1. Heißt es, dass dein Apache nur http anbietet und CPE nimmt es an, weil https nicht zwingend notwendig ist? Das heißt die Übertragung läuft dann im Klartext? Dann kann man es natürlich loggen...

zum 2. ist das, was ich im Posting #9 gezeigt hatte ein InformRequest von 1und1 ACS? Das heißt ich kann dann auf dem Apache als z.B. index.html zunächst mal den Inhalt dieser Ausgabe hinlegen? Wie sendet man dann die Antwort an CPE? Ich meine, wie lässt sich das überhaupt realisieren? Hast du es schon gemacht? Poste bitte ein Beispiel dazu. Mit dem Header für AVM habe ich ebenfalls nicht ganz kapiert.

zum 3. Nochmals, wie machst du dass denn? Bitte Beispiele posten. Quittiert denn CPE dem ACS irgendwie, dass die Session gültig ist bevor ACS mit der Abfragerei loslegen kann? Wie sieht es dann aus?

MfG
 
Was bofh geschrieben hat, ist genau, was ich meinte. Dem ist im Grunde nichts hinzuzufügen, aber von mir aus gern ein bißchen ausführlicher:

Client <--> Proxy <--> Server

Dem Client wir ein selbst generiertes Zertifikat des Proxy anstatt des Servers mitgegeben. Der Proxy wiederum bekommt das des Servers. Der Proxy entschlüsselt, was er vom Client (Fritz!Box) bekommt, protokolliert es, verschlüsselt es erneut und schickt es an den Server. Dessen Antwort entschlüsselt er wieder, protokolliert sie und verschlüsselt sie neu für den Client. Sehr simpel.
 

Neueste Beiträge

Statistik des Forums

Themen
244,691
Beiträge
2,216,608
Mitglieder
371,308
Neuestes Mitglied
Chrischan 79
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.