FritzBox auf AVM oder 1und1 setzen, ANNEX umsetzen

wäre ja auch gelacht gewesen, wenn ich etwas hinbekommen hätte...

läuft alles scheisse zzt, warte wohl besser bis nächstes jahr. dann wird sicher - miraculum miraculum - alles funktionieren...

danke vorerst für die tipps
 
würde es evtl. helfen auf eine ältere fw downzugraden um mit der die umstellung auf A zu probieren?

Mach mal ein ordentliches (Anleitung dazu GENAU befolgen)RECOVER mit der RECOVER 04.15 DEUTSCH (nicht D-A-CH!)! Das hatte ich Dir schon einmal empfohlen. Danach laß nochmal die TELEFONICUS-Datei "fritz_as_annex_a_kernel_args_newer.tar" drüberlaufen. Danach sollte eigentlich alles im GRÜNEN sein. Und wenn Du dann auf die D-A-CH-Version umsteigen willst, können wir den Versuch auf der Basis der 04.15 unternehmen. Dazu musst Du Dir allerdings die Recover-Version der D-A-CH 04.15 besorgen (Anfrage im Sammelthread dieses Forums).

dürfte ich mit dieser (ftp://ftp.avm.de/fritz.box/fritzbox.fon_5010/x_misc/deutsch_a-ch/) recovery fw drüberfahren oder schieß ich mir damit die box?
Die Box wirst Du vermutlich nicht an die Wand fahren - es wird halt einfach nicht gehen.
 
Mach mal ein ordentliches (Anleitung dazu GENAU befolgen)RECOVER mit der RECOVER 04.15 DEUTSCH (nicht D-A-CH!)! Das hatte ich Dir schon einmal empfohlen. Danach laß nochmal die TELEFONICUS-Datei "fritz_as_annex_a_kernel_args_newer.tar" drüberlaufen. Danach sollte eigentlich alles im GRÜNEN sein. Und wenn Du dann auf die D-A-CH-Version umsteigen willst, können wir den Versuch auf der Basis der 04.15 unternehmen. Dazu musst Du Dir allerdings die Recover-Version der D-A-CH 04.15 besorgen (Anfrage im Sammelthread dieses Forums).


Die Box wirst Du vermutlich nicht an die Wand fahren - es wird halt einfach nicht gehen.
okidoki, die 04.15er ist nun drauf (die D-A-CH version hat sich wie du es prophezeit nicht aufspielen lassen)
(ich hab mir jetzt nochmal die support-datei geholt und es steht immer noch kernel_args annex=A, wird das nicht durch das recovern wieder auf B geändert? wenn ja, wieso tuts das nicht?)

ich werf jetzt nach dem frischen recovern nochmal die fritz_as_annex_a_kernel_args_newer.tar hinein. anschließend werde ich dieses posting editieren und das ergebnis schreiben.

eine interessensfrage noch: warum muss es gerade die D-A-CH 04.15 recover version sein? danke!

//edit:
nachdem ich auf "update fortsetzen" geklickt hab -> timeout "seite konnte nicht geladen werden"
die box startete nicht mehr neu, sie war nicht mehr unter fritz.box zu erreichen und bei eingabe der IP kam nur ein "Internal communication error (login -1). Exiting."
das problem hatte ich gaaaanz am anfang auch schon, daher hab ich die ...new.tar version (oder wars die aller erste) verwendet und damit hat es klaglos funktioniert, das updaten jedenfalls. wirklich "online sein" ist noch nicht in blickweite. :(
mir fehlt irgendwie der plan woran es liegen könnte.
 
Zuletzt bearbeitet:
hier die grafik, die ich ansprach:

Wer hat die denn verbrochen? DSL liegt in der FRITZ genau mittig, also auf den PINS 4 und 5 - Dein Verdacht war schon richtig. Aber wenn Du ein normales Telefonkabel mit RJ11 Stecker auf beiden Seiten nimmst und die Kontakte jeweils "straight" in der Mitte durchgeführt werden, müsstest Du eigentlich DSL Sync erhalten - vorausgesetzt, Du steckst den filterseitigen Stecker in das richtige "Loch" (bezeichnet als "Modem") des Filters und auch FRITZ-seitig ins dort richtige "Loch" = die (hellgraue) Buchse mit der Aufschrift DSL/Tel . Diese FRITZ-Buchse ist zwar größer als der RJ11-Stecker, der aber trotzdem passt und Dir DSL Signal bringen sollte, wenn die PINS auf beiden Seiten mittig kontakten.
 
es steht immer noch kernel_args annex=A, wird das nicht durch das recovern wieder auf B geändert?

Das Umstellen der Modem Funktion überlebt jedes Upgrade und sogar ein Recover.

eine interessensfrage noch: warum muss es gerade die D-A-CH 04.15 recover version sein?

Weil beides die letzten Recover Versionen für Hardware-Annex-B (D) und Hardware-Annex-A (D-A-CH) sind, die mit dem selben Linux Kernel 2.4 arbeiten. Mit unterschiedlichen Kerneln (ab ca. fw 04.30 benutzt AVM den 2.6) und unterschiedlicher Flashspeicheraufteilung ist ein Umstieg von einer für B-Boxen designten FW auf eine solche für A-Boxen, die teilweise unterschiedliche Hardware nutzen, völlig aussichtslos.

Im Hinblick auf Dein edit: Ich hoffe jetzt nur, daß der untaugliche Versuch, mit der recover 04.43 (Kernel 2.6 mit 4 Flash-Bereichen) eine Box mit einem 2.4 Kernel und nur 2 Flashbereichen (=mtd) zu recovern, nicht doch noch Unheil angerichtet hat. Die Meldung, die Du erhältst (login -1) lässt mich so etwas befürchten.

Du kommt jetzt also nicht mehr auf die Box? Versucht mit IP 192.168.178.1 und fritz.box. Auch schon versucht mit 192.168.178.254 und 192.168.179.1?

Falls Du mit keiner dieser IP das Interface aufrufen kannst, mach erst mal einen Werksreset mit einem Analog-Telefon an einer der Analog-Buchsen der Box. In dem Telefon wählen: #991*15901590* und warten bis die Verbindung beendet wird. Danach erneut mit den IPs den Aufruf versuchen und Ergebnis posten.
 
hab ich mir gedacht, dass das nicht so stimmt. nehme das bild vorsichtshalber heraus, bevor es noch jemand für korrekt hält.
 
Moin,

sorry, wenn ich mich da einmische, aber bist du sicher, dass die Kernel_args Methode beim 2.4-er Kernel funktioniert? Konnte/Musste man da nicht einfach den anderen Annex in die Umgebungsvariablen schreiben? Also "...new.tar" statt "...newer.tar"?

@master blue
Ein "Internal communication error" lag am nicht laufenden ctlmgr oder am falschen oem, wenn ich mich recht erinnere... Starte doch mal Telnet auf der Box (per Telefon #96*7* wählen) und versuche, dich mit "telnet <die Box>" auf deine Box zu verbinden (<deine-Box> ist der Name oder die IP, unter der du die Box sonst im Browser ansprichst). Wenn das klappt, mache mal
Code:
cat /proc/avalanche/env

Jörg
 
Zuletzt bearbeitet:
Das Umstellen der Modem Funktion überlebt jedes Upgrade und sogar ein Recover.
verstehe, alles klar.

Im Hinblick auf Dein edit: Ich hoffe jetzt nur, daß der untaugliche Versuch, mit der recover 04.43 (Kernel 2.6 mit 4 Flash-Bereichen) eine Box mit einem 2.4 Kernel und nur 2 Flashbereichen (=mtd) zu recovern, nicht doch noch Unheil angerichtet hat. Die Meldung, die Du erhältst (login -1) lässt mich so etwas befürchten.
nein nein, ist nichts passiert, sobald ich die box vom strom nehme und wieder anstecke pfeift wieder alles. der flashversuch der D-A-CH war aber sowieso schon vorher, wobei mir die recover sw ein "firmware inkompatibel" entgegen geworfen hat, und erst garnichts an der box geändert hat.
ich hab jetzt in der zwischenzeit die newer.tar nochmal gezogen und jetzt hat auch das updaten funktioniert (fehlermeldung: kein fehler), vielleicht war die alte einfach korrupt und hat dadurch das obige problem ausgelöst. whatelse...

gehn tut aber immer noch nichts:
also fb5010 + 04.15 (fritz.box_fon_5010.04.15.recover-image.exe) + ...newer.tar geht definitiv nicht.

sorry, wenn ich mich da einmische, aber bist du sicher, dass die Kernel_args Methode beim 2.4-er Kernel funktioniert? Konnte/Musste man da nicht einfach den anderen Annex in die Umgebungsvariablen schreiben? Also "...new.tar" statt "...newer.tar"?
ich bin grundsätzlich für alles offen. :)
wobei lt. telefonicus das mit newer.tar funktionieren sollte: http://ippf.eu/showthread.php?p=971638
 
sorry, wenn ich mich da einmische, aber bist du sicher, dass die Kernel_args Methode beim 2.4-er Kernel funktioniert?

Hilfreiche Eimischungen sind sogar erwünscht! Zu dieser Kategorie gehören Deine eigentlich immer. Zur Frage: TELEFONICUS sagt, daß die "newer" auch für ältere Boxen funktionieren. Habe auch selbst schon 04.15er Boxen damit im Modem umgestellt. Funktioniert also prinzipiell. Bei master blue hat dagegen offensichtlich die "new" zwar einen Teil der Umstellung geschafft (in Support Daten: kernel_args annex = A), einen anderen Teil aber offensichtlich nicht (im Interface wird unter DSL Info weiter Annex B angezeigt). Ein solches Phänomen ist mir noch nicht untergekommen und habe auch im Forum dazu nichts gelesen.

@master blue: Heisst das jetzt: Sowohl die Support-Daten werfen "kernel_args annex = A" aus als auch unter DSL Info hast Du jetzt Annex A stehen? Was ist dann unter "gehen tut immer noch nichts" zu verstehen?
 
...ja, die Datei unterscheidet zwischen 2.4 und 2.6-er Kernel. Aber setzt halt immer auf "kernel_args", was ich halt mit dem 2.6-er Kernel in Verbindung bringe. Vielleicht irre ich mich dabei ja auch...
Im "newer" steht:
Code:
if [ "${kversion}" = 24 ] ; then
	echo "kernel_args annex=A" > /proc/avalanche/env
else
	echo "kernel_args annex=A" > /proc/sys/urlader/environment    
fi
in "new":
Code:
echo "annex A" > /proc/avalanche/env

Kommst du denn per Telnet auf die Box?
Jörg
 
Hallo,

noch mal die dringende Bitte an alle in diesem Thread: Bitte keine Beiträge unmittelbar hintereinander erzeugen innerhalb von 24 Stunden! Will man Informationen hinzufügen, kann man die Ändern-Funktion benutzen.
 
Kommst du denn per Telnet auf die Box?
ja das geht. mit deinem obigen befehl zeigt er mir die support-daten:

# cat /proc/avalanche/env
HWRevision 86
ProductID Fritz_Box_5010
SerialNumber 0000000000000000
annex B
autoload yes
bootloaderVersion 1.99
bootserport tty0
bluetooth 00:04:0E:7F:FF:07
cpufrequency 150000000
firstfreeaddress 0x946ABA30
firmware_version avm
firmware_info 23.04.15
flashsize 0x00400000
kernel_args annex=A
maca 00:15:0C:78:EB:62
macb 00:15:0C:78:EB:63
macwlan 00:15:0C:78:EB:64
macdsl 00:15:0C:78:EB:65
memsize 0x01000000
modetty0 38400,n,8,1,hw
modetty1 38400,n,8,1,hw
mtd0 0x90000000,0x90000000
mtd1 0x90010000,0x903C0000
mtd2 0x90000000,0x90010000
mtd3 0x903C0000,0x903E0000
mtd4 0x903E0000,0x90400000
my_ipaddress 192.168.178.2
prompt AVM_Ar7
ptest
reserved 00:04:0E:7F:FF:00
req_fullrate_freq 125000000
sysfrequency 125000000
urlader-version 1099
usb_board_mac 00:15:0C:78:EB:66
usb_rndis_mac 00:15:0C:78:EB:67
usb_device_id 0x3A00
usb_revision_id 0x0200
usb_device_name USB DSL Device
usb_manufacturer_name AVM
 
Außer der Fw-Version (jetzt 04.15 - zuvor 04.27) keine Veränderungen gegenüber #1474. Deshalb nochmal die Frage: Welcher Annex wird jetzt unter "DSL Informationen" angezeigt? Immer noch B? Falls jetzt A muß das Problem fehlenden Syncs woanders gesucht werden.
 
Außer der Fw-Version (jetzt 04.15 - zuvor 04.27) keine Veränderungen gegenüber #1474. Deshalb nochmal die Frage: Welcher Annex wird jetzt unter "DSL Informationen" angezeigt? Immer noch B? Falls jetzt A muß das Problem fehlenden Syncs woanders gesucht werden.
B, ich hab dort leider noch kein einziges mal A stehen sehen.
 
Support-Daten sind offensichtlich in Ordnung, Modem Mode ist umgestellt auf A; weshalb läuft die Box trotzdem nicht? ODER WAS IST UNTER "GEHEN TUT IMMER NOCH NICHTS" ZU VERSTEHEN?? Nach mehreren Berichten im Forum, daß Recover teilweise mehrfach wiederholt werden musste, folgender Vorschlag:

Stell das Modem noch einmal zurück auf B mit der Telefonicus-Datei ".......as_annex_b_kernel_args_newer.tar" und lasse anschliessend die Recover-Exe mehrmals vollständig laufen. Danach stellst Du den Modem-Annex wieder um auf A mit der Telefonicus-Datei "fritz_as_annex_a_kernel_args_newer.tar" (oder sicherheiitshalber mit der von HAVEANICEDAY = "......new.tar
 
Zuletzt bearbeitet:
Entschuldige, imagomundi, dass ich mich hier einschalte, aber ich denke, ich kann konstruktiv beitragen.

Es handelt sich um die FW Version 23.04.15 mit dem alten Kernel 2.4.
Um diese "alten" FW Version auf AnnexA zu patchen, muss man einfach die environment Variable "annex B" in "annex A" ändern (5. Zeile in der support Datei)
Eigentlich gehört der Parameter "kernel_args..." da gar nicht hin.
MaxMuster hat das ja auch vermutet und auch schön beschrieben, was die Pseudo-Images "...new.tar" und "...newer.tar" eigentlich machen - nämlich genau diese beiden patch Varianten.

Jetzt meine Empfehlung an master blue:

1. Entferne "kernel_args annex=A" aus dem environment!
Das erreichst Du via telnet mit der Eingabe echo "kernel_args" > /proc/avalanche/env

2. Zur Kontrolle cat /proc/avalanche/env eingeben: die Zeile mit "kernel_args annex=A" sollte nicht mehr erscheinen

3. Jetzt setzt Du den Annex in Zeile 5 auf A. Das könntest Du mit der Datei "fritz_as_annex_a_new.tar" machen. Da Du aber schon in telnet bist, schreibe einfach echo "annex A" > /proc/avalanche/env

4. Zur Kontrolle wieder cat /proc/avalanche/env eingeben: In Zeile 5 sollte jetzt "annex A" stehen

5. Telnet beenden und FB resetten. Die FB 5010 sollte jetzt auf AnnexA gepatcht sein ...

Noch ein Hinweis: Mit der von imagomundi empfohlenen Datei "fritz _as_annex_B_kernel_args_newer.tar" wird der Parameter "kernel_args" nicht entfernt, sondern auf "kernel_args annex=B" gesetzt. Bei den neuen FW-Versionen ist das ok, aber ob es bei den alten gut ist, bezweifle ich (die verstehen den Parameter "kernel_args..." evtl. gar nicht).
Es könnte auch sein, dass die alte FW für bestimmte FBen das toleriert (wie von imagomundi berichtet), aber eben die FB 5010 nicht.

Good Luck!

-------------------------------

Edit:
MaxMuster hat die Sachlage jetzt sehr gut beleuchtet. Danke, Jörg.
Meine Vermutung, dass es am Parameter "kernel_args" liegt, scheint also nicht zuzutreffen.

Auch ich kann mich erinnern, dass es FW-Versionen bei bestimmten FB-Typen gab, bei denen das Umstellen von AnnexB auf AnnexA nicht möglich ist. Langsam fürchte ich, dass hier so eine Situation vorliegt.
Falls das so ist, muss man wirklich die FW Version A/CH laden (mit Ändern der HWRevision etc.). Scheint schon mit neuem Kernel zu sein: fritz.box_fon_5010.annexa.48.04.43.image (auf dem FTP-Server von AVM)

.
 
Zuletzt bearbeitet:
Moin,

ich habe mir das nochmal angesehen und in allen FW's, die ich so auf die schnelle finden konnte, sind die beiden entscheidenden Einträge für kernel_args ("annex_param") vorhanden:

Code:
etc/init.d> echo "**********rc.S**********"; sed -n '/avm_event_param=/,/done/p' rc.S ;echo "**********rc.conf**********"; sed -n '/-z \"\$annex_param\"/,/^[ ]*fi/p' rc.conf
**********rc.S**********
avm_event_param=
atm_param=
ar7wdt_param=
cpmac_param=
i2c_param=
annex_param=
[B]for i in `cat /proc/cmdline` ; do[/B]
 case $i in
 avm_event_*)
 avm_event_param=$i
 ;;
 atm_*)
 atm_param="$atm_param $i"
 ;;
 ar7wdt_*)
 ar7wdt_param="$ar7wdt_param $i"
 ;;
 cfg_*)
 cpmac_param="$cpmac_param $i"
 ;;
 i2c_*)
 i2c_param="$i2c_param $i"
 ;;
[B] annex=*)
 annex_param=${i##annex=}[/B]
 ;;
 *)
 ;;
 esac
done
**********rc.conf**********
 if [ [B]-z "$annex_param"[/B] ] ; then
 export ANNEX=`cat $CONFIG_ENVIRONMENT_PATH/annex` # annex aus /proc nehmen, nicht von Config!
 if [ -z "${ANNEX}" ] ; then export ANNEX=B ; fi # nur wenn vom /proc nix kommt, default setzen.
[B] else
 echo "overwrite annex"
 export ANNEX=$annex_param
 fi[/B]

Will sagen "es müsste eigentlich auch in der 2.4-er FW mit kernel_args gehen". Ob das übrigens geklappt hat, egal auf welche Weise den Annex zu ändern, findet man in in dem Eintrag "<? setvariable var:Annex '${ANNEX}' ?>" in der Datei "/var/config.def".

Entweder hat also hier der Patch nicht richtig gewirkt, oder aber (gab es das nicht auchmal?) diese FW kann nicht zwischen Annex B und A umgestellt werden.

Letztlich könnte man versuchen, per Telnet direkt das Modul mit expliziter Annex-Angabe zu starten:
Code:
rmmod tiatm
FW="`find /lib/modules -name "*.bin" | grep -e 'ar07\|dsl'`"
echo "Versuche Modemfirmware $FW"
insmod tiatm firmware_load_file=${FW}  annex=A

Jörg
 
Zuletzt bearbeitet:
Dank der akribischen Arbeit von MaxMuster ist jetzt klar, daß es auch im 2.4er Kernel die Variable "kernel_args Annex" bereits gab. Alle Überlegungen, die "el_valiente" (dieses Forum lebt auch von konstruktiven Einmischungen - danke) und MaxMuster angestellt haben, hatte ich im Hintergrund meines letzten Vorschlags auch schon angestellt. Grundidee war einfach "back to the roots" so weit das nach den schon erfolgten Aktivitäten noch möglich war. Das heißt aus meiner Sicht vor allem: (Kernel_args)Annex zurück auf das der Box originäre B und dann mehrfach recovern mit der 04.15. Es gibt ja genügend Berichte in diesem Forum, daß Recover erst nach mehrmaligem Durchlauf gegriffen hat. Nic ht zu vergessen, daß die Ausgangs-Fw eine 03.79 war. Mit einer "sauberen" 04.15 (letzte Basis-Recover für die 2.4er fw) sollte dann noch (erforderlichenfalls ebenfalls mehrfach) der Versuch der Annex-Umstellung mit der eigentlich für die 2.4 originär adäquaten HAVEANICEDAY "...new.tar" unternommen werden. Erst wenn das geklappt hat, würde ich den Umstieg auf die A-Fw 48.... mit der bekannten HWR-Methode versuchen.
 
WAS IST UNTER "GEHEN TUT IMMER NOCH NICHTS" ZU VERSTEHEN??
ah, entschuldige bitte, die frage hab ich oben ganz übersehen.
an der syncro scheiters. (die leitung/kabel/stecker ist 100%ig in ordnung, da ich nebenbei eine andere FB betreibe.)

1. Entferne "kernel_args annex=A" aus dem environment!
Das erreichst Du via telnet mit der Eingabe echo "kernel_args" > /proc/avalanche/env

2. Zur Kontrolle cat /proc/avalanche/env eingeben: die Zeile mit "kernel_args annex=A" sollte nicht mehr erscheinen

3. Jetzt setzt Du den Annex in Zeile 5 auf A. Das könntest Du mit der Datei "fritz_as_annex_a_new.tar" machen. Da Du aber schon in telnet bist, schreibe einfach echo "annex A" > /proc/avalanche/env

4. Zur Kontrolle wieder cat /proc/avalanche/env eingeben: In Zeile 5 sollte jetzt "annex A" stehen

5. Telnet beenden und FB resetten. Die FB 5010 sollte jetzt auf AnnexA gepatcht sein ...


aktueller stand:
1. kernel_args wieder auf B gestellt (mit newer.tar)
2. recover 04.15 3x hintereinander geflasht -> problemlos
3. new.tar geflasht -> ergebnis: zeigt keinerlei wirkung
"annex B"
"kernel_args B"
"In Ihrer FRITZ!Box wurden vom Hersteller nicht unterstützte Änderungen durchgeführt." wird angezeigt
4. newer.tar geflasht -> ergebnis:
"In Ihrer FRITZ!Box wurden vom Hersteller nicht unterstützte Änderungen durchgeführt." ist verschwunden
"annex B"
"kernel_args A"
5. endergebnis: immer noch keine syncro, dsl-info "annex B"

punkt 3 und 4 hab ich mehrmals wiederholt, dazwischen auch wieder per newer.tar auf B umgestellt, das ergebnis bleibt aber auch nach mehrmaligen versuchen gleich.

1. Entferne "kernel_args annex=A" aus dem environment!
Das erreichst Du via telnet mit der Eingabe echo "kernel_args" > /proc/avalanche/env

2. Zur Kontrolle cat /proc/avalanche/env eingeben: die Zeile mit "kernel_args annex=A" sollte nicht mehr erscheinen

3. Jetzt setzt Du den Annex in Zeile 5 auf A. Das könntest Du mit der Datei "fritz_as_annex_a_new.tar" machen. Da Du aber schon in telnet bist, schreibe einfach echo "annex A" > /proc/avalanche/env

4. Zur Kontrolle wieder cat /proc/avalanche/env eingeben: In Zeile 5 sollte jetzt "annex A" stehen

5. Telnet beenden und FB resetten. Die FB 5010 sollte jetzt auf AnnexA gepatcht sein ...
1.+ 2. entfernen hat funktioniert
3. + 4. hat auch funktioniert, "annex A" wurde angezeigt
5. nach dem neustart -> "kernel_args" ist weg, "annex" aus zeile 5 steht wieder auf B.
(ich hab das ehrlichgesagt testhalber gestern auch schon versucht, weil ich wissen wollte, ob man die befehle auch im telnet verwenden kann. allerdings ohne kernel entfernen, ergebnis war wie heute das gleiche. die box merkt sich die einstellung nicht.)

Ob das übrigens geklappt hat, egal auf welche Weise den Annex zu ändern, findet man in in dem Eintrag "<? setvariable var:Annex '${ANNEX}' ?>" in der Datei "/var/config.def".
steht nach allen versuchen immer noch auf B.

Entweder hat also hier der Patch nicht richtig gewirkt, oder aber (gab es das nicht auchmal?) diese FW kann nicht zwischen Annex B und A umgestellt werden.
ich glaube mittlerweile das zweiteres zutrifft.

Code:
rmmod tiatm
FW="`find /lib/modules -name "*.bin" | grep -e 'ar07\|dsl'`"
echo "Versuche Modemfirmware $FW"
insmod tiatm firmware_load_file=${FW}  annex=A
wie verwende ich das? nacheinander im telnet eingeben? auf rmmod tiatm meldet die box "device or resource busy".
 
wie verwende ich das? nacheinander im telnet eingeben? auf rmmod tiatm meldet die box "device or resource busy".

Ja, genauso war es gedacht. Versuche vielleicht vorher mal den dsld komplett zu stoppen mit "dsld -s ; sleep 2 ; killall dsld"

Jörg
 
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.