Fritzbox 6490 Cable Firmware Update?

Sehr interessant das Ganze.
Ich selbst blicke jetzt da noch nicht zu hunderprozent durch, wie ich die abgeänderte post_install wieder auf die Fritz!Box bringe.


Was ich bis dato verstanden habe muss ich mir eine spezielle provideradditive.tar bauen in der die angepasste post_install enthalten ist.
provideradditive.tar wird, wie vorangehend beschrieben, bei jedem Start der Box entpackt - man nutzt den busybox tar Bug aus um die post_install nach /var zu schreiben. Dann die Box neustarten und post_install wird beim nächsten Start ausgeführt.


Über die Supportdaten komme ich an die provideradditive.tar. (erstellt mit den auf Github angebotenen YourFritz tffs Tools)
Wüsste nicht wie man das ohne telnet Zugriff anstellt.


Wie bringe ich die provideradditive.tar wieder auf die Box? Bastel ich das in ein TFFS-Image und spiele das über EVA ein? Die Settings der Fritz!Box sind mir ja egal - im Zweifel spiel ich den export wieder ein.

Ahja, das ist die "/var/post_install" aus der 06.62, falls jemand nicht selbst entpacken möchte.

Code:
## ! /bin/sh
## Skip Startup (on very early reboot-cmd)
if ps | grep -v grep | grep -q 'rc.S'; then
echo "rc.S is running - set 'skip init'"
touch /var/skip_init
fi
## AHA
if ps | grep -v grep | grep -q /usr/bin/aha ; then
/usr/bin/aha -s
fi
## EWETEL
if [ -x /bin/smartmeter ] ; then
/bin/smartmeter stop
fi
## Telefon und was dran hängt
if ps | grep -v grep | grep -q telefon; then
killall telefon
sleep 2
fi
if [ -x /etc/hotplug/usb.pandu -a -d /sys/bus/usb/devices ] ; then
if grep -q 'tffs=/tffs/[1-2]' /proc/cmdline ; then
echo "SDK-System skip stopping USB-Subsystem .."
echo "remount / ro"
mount -o remount,ro /
else
echo "stopping USB-Subsystem .."
/etc/hotplug/usb.pandu stop
echo "USB-Subsystem .. stopped"
fi
fi
## WLAN
if [ -x /etc/init.d/rc.wlan ] ; then
echo "stopping WLAN ..."
/etc/init.d/rc.wlan stop
echo "WLAN ... stopped"
fi
## prohibit writing anything
if ps | grep -v grep | grep -q mediasrv; then
/sbin/stop_mediasrv
sleep 2
fi
## alle verbliebenen mountpoints unmounten (auch Internen Speicher, falls vorhanden)
if [ -d /var/media/ftp ]; then
## wer hat noch die finger drauf?
for i in /proc/[0-9]*/fd ; do if ls -l ${i} | grep -q '/var/media/ftp' ; then j=`echo ${i%*/fd}`; j=`echo ${j##*/}`; echo [$$] WARNING: '/var/media/ftp/*' still used by process ${j}; ps | grep -v grep | grep ${j} ; fi ; done
for i in /proc/[0-9]*/cwd ; do if ls -l ${i} | grep -q '/var/media/ftp' ; then j=`echo ${i%*/cwd}`; j=`echo ${j##*/}`; echo [$$] WARNING: '/var/media/ftp/*' still used by process ${j}; ps | grep -v grep | grep ${j} ; fi ; done
echo "unmounting '/var/media/ftp/*' .."
## rmdir /var/media/ftp/* > /dev/null 2>&1
for MP in /var/media/ftp/*; do
test -d "$MP" || continue
grep " $MP " /proc/mounts > /dev/null 2>&1 || continue
umount "$MP" > /dev/null 2>&1 || echo "unmounting '$MP' failed"
rmdir "$MP"
done
fi
## TAM auf Internem Speicher?
if mount | grep '^/var/dev/nand' | grep -q '/data/tam' ; then
echo "unmounting '/data/tam' .."
umount /data/tam > /dev/null 2>&1
fi
######################################
## NAND
## known candidates using nand (for smartstop)
POST_NAND_ACCESS_STOPLIST="ftpd smbd mediasrv mount.davfs"
post_mtd_nand=`grep nand-filesystem /proc/mtd`
for i in ${post_mtd_nand} ; do
post_mtd_nand=$i
break
done
if [ -n "${post_mtd_nand}" ] && mount | grep -q '^/var/dev/nand'; then
post_mtd_nand=${post_mtd_nand#mtd}
post_mtd_nand=${post_mtd_nand%:*}
INTERNAL_NAME=`echo internalflash.mountpoint | usbcfgctl -s | tr -d '"'`
## post_mountpoint="/var/media/ftp/$INTERNAL_NAME"
post_mountpoint="/var/media/ftp"
if [ -d "${post_mountpoint}" ] ; then
echo "[$$]++ ++ do internalflash 'prepare unmount'... ++ ++" > /dev/console
#########################
## wer hat hier die finger drauf? (known candidates using nand)
post_nand_access_pidlist=""
for pid in `pidof ${POST_NAND_ACCESS_STOPLIST}`; do
if `ls -l /proc/$pid/cwd /proc/$pid/fd | grep "/var/media/ftp" > /dev/null 2>&1` ; then
post_nand_access_pidlist="${post_nand_access_pidlist} ${pid}"
fi
done
if [ -n "${post_nand_access_pidlist}" ] ; then
## smartstop sequence, because we found something
for process in ${POST_NAND_ACCESS_STOPLIST} ; do
case ${process} in
ftpd|smbd)
for pid in `pidof ${process}`; do
for i in ${post_nand_access_pidlist}; do
if [ "${pid}" = "${i}" ] && pidof ${process} ; then
## ftp/samba: prevent re-forked access, then simple kill
echo "[$$][Internal Memory] smartstop: try to disconnect ${process} ${pid}" > /dev/console
test -x /bin/inetdctl && inetdctl disable ${process}
kill ${pid}
fi
done
done
;;
mediasrv)
for pid in `pidof ${process}`; do
for i in ${post_nand_access_pidlist}; do
if [ "${pid}" = "${i}" ] && pidof ${process} ; then
## mediasrv: stop cmd
echo "[$$][Internal Memory] smartstop: try to disconnect ${process} ${pid}" > /dev/console
test -x /sbin/stop_mediasrv && /sbin/stop_mediasrv
sleep 2
fi
done
done
;;
mount.davfs)
for pid in `pidof ${process}`; do
for i in ${post_nand_access_pidlist}; do
if [ "${pid}" = "${i}" ] && pidof ${process} ; then
## webdav: stop cmd (needs no sleep, returns after completion)
echo "[$$][Internal Memory] smartstop: try to disconnect ${process} ${pid}" > /dev/console
test -x /etc/webdav_control && /etc/webdav_control stop
fi
done
done
;;
*)
for pid in `pidof ${process}`; do
for i in ${post_nand_access_pidlist}; do
if [ "${pid}" = "${i}" ] && pidof ${process} ; then
echo "[$$][Internal Memory] smartstop: WARNING: try to disconnect unhandled NAME ${process} PID ${pid}" > /dev/console
kill ${pid}
fi
done
done
;;
esac
done
fi
## wer hat hier IMMERNOCH die finger drauf ('fd' fuer files, 'cwd' fuer verzeichnisse)?
## (handle known & unknown candidates using nand)
post_nand_access_pidlist=""
for i in /proc/[0-9]*/fd ; do if ls -l ${i} | grep -q "${post_mountpoint}" ; then j=`echo ${i%*/fd}`; j=`echo ${j##*/}`; post_nand_access_pidlist="${post_nand_access_pidlist} ${j}"; fi ; done
for i in /proc/[0-9]*/cwd ; do if ls -l ${i} | grep -q "${post_mountpoint}" ; then j=`echo ${i%*/cwd}`; j=`echo ${j##*/}`; post_nand_access_pidlist="${post_nand_access_pidlist} ${j}"; fi ; done
for i in ${post_nand_access_pidlist} ; do echo "[$$] WARNING: ${post_mountpoint} still used by process ${i}"; ps | grep -v grep | grep ${i} ; done > /dev/console
#########################
## Killer
post_killer9_stop_wdt=n
if [ -n "${post_nand_access_pidlist}" ] ; then
post_killer9_stop_wdt=y
fi
for i in ${post_nand_access_pidlist} ; do
## stop watchdog (once)
if [ -c /dev/watchdog ] && [ "${post_killer9_stop_wdt}" = "y" ]; then
echo "[$$][Internal Memory] killer9: disable watchdog"; echo disable > /dev/watchdog
post_killer9_stop_wdt=n
fi
## handle pid
[ -d "/proc/$i" ] && echo "[$$][Internal Memory] killer9: working on PID ${i}" && kill -9 ${i} && sleep 5 > /dev/console
done
## annahme: post_nand_access_state=unused
post_nand_access_state=unused
for i in ${post_nand_access_pidlist} ; do
[ -d "/proc/$i" ] && echo "[$$][Internal Memory] ERROR: killer9: failed on PID ${i} - ${post_mountpoint} still used by process ${i}" && ps | grep -v grep | grep ${i} > /dev/console
post_nand_access_state=busy
done
## fertig
echo "[$$]++ ++ ...done ++ ++" > /dev/console
fi
fi
######################################
######################################
## Internen Speicher unmounten, falls doch nochwas vorhanden
if mount | grep -q '^/var/dev/nand' ; then
echo "unmounting '/var/dev/nand' .."
## umount /var/dev/nand > /dev/null 2>&1
umount /var/dev/nand
fi
######################################
## TAM auf Internem Speicher? (ramdisk16)
if mount | grep '^/var/16MB' | grep -q '/data/tam' ; then
echo "unmounting '/data/tam' .."
umount /data/tam > /dev/null 2>&1
fi
## Internen Speicher unmounten, falls doch nochwas vorhanden
if mount | grep -q '^/var/16MB' ; then
echo "unmounting '/var/16MB' .."
umount /var/16MB > /dev/null 2>&1
fi
## TAM auf Internem Speicher? (ramdisk8)
if mount | grep '^/var/8MB' | grep -q '/data/tam' ; then
echo "unmounting '/data/tam' .."
umount /data/tam > /dev/null 2>&1
fi
## Internen Speicher unmounten, falls doch nochwas vorhanden
if mount | grep -q '^/var/8MB' ; then
echo "unmounting '/var/8MB' .."
umount /var/8MB > /dev/null 2>&1
fi
## TAM auf Internem Speicher? (ramdisk4)
if mount | grep '^/var/4MB' | grep -q '/data/tam' ; then
echo "unmounting '/data/tam' .."
umount /data/tam > /dev/null 2>&1
fi
## Internen Speicher unmounten, falls doch nochwas vorhanden
if mount | grep -q '^/var/4MB' ; then
echo "unmounting '/var/4MB' .."
umount /var/4MB > /dev/null 2>&1
fi
## TAM auf Internem Speicher? (ramdisk2)
if mount | grep '^/var/2MB' | grep -q '/data/tam' ; then
echo "unmounting '/data/tam' .."
umount /data/tam > /dev/null 2>&1
fi
## Internen Speicher unmounten, falls doch nochwas vorhanden
if mount | grep -q '^/var/2MB' ; then
echo "unmounting '/var/2MB' .."
umount /var/2MB > /dev/null 2>&1
fi
######################################
rm -f /var/InternerSpeicher
if [ -x /etc/init.d/e40-dsl ] ; then
echo "unload dsl and dependend driver .."
/etc/init.d/e40-dsl
fi
set -x
## prohibit further access
if ps | grep -v grep | grep -q dtrace; then killall dtrace ; fi
ps
echo "stopping applications using ubik2/pcmlink .."
if ps | grep -v grep | grep -q capiotcp_server ; then killall capiotcp_server ; fi
if ps | grep -v grep | grep -q telefon ; then killall telefon ; fi
if ps | grep -v grep | grep -q dect_manager ; then killall dect_manager ; fi
if ps | grep -v grep | grep -q voipd ; then voipd -s ; fi
sleep 2
if ps | grep -v grep | grep -q voipd ; then killall -9 voipd ; fi
## unload if still running
lsmod
echo "stopping modules using ubik2/pcmlink .."
if lsmod | grep -q ulpcmlink ; then rmmod ulpcmlink ; fi
if lsmod | grep -q dect_io ; then rmmod dect_io ; fi
if lsmod | grep -q avm_dect ; then rmmod avm_dect ; fi
if lsmod | grep -q capi_codec ; then rmmod capi_codec ; fi
if lsmod | grep -q isdn_fbox_fon5 ; then rmmod isdn_fbox_fon5 ; sleep 2; fi
if lsmod | grep -q pcmlink ; then rmmod pcmlink ; fi
set +x
echo "still running:"
ps
lsmod
echo "system is going down .."
echo "disable watchdog ..."
echo disable > /dev/watchdog
echo "reinit watchdog 20 sek ..."
echo init-start 20 >/dev/watchdog
if grep -q 'tffs=/tffs/[1-2]' /proc/cmdline ; then
sync
echo "SDK-System: stopping USB-Subsystem .."
/etc/hotplug/usb.pandu stop
echo "SDK-System: USB-Subsystem .. stopped"
fi
## UBIK2 Nutzer freigeben
## if lsmod | grep -q ubik2 ; then
## echo "stopping applications using ubik2 .."
## if ps | grep -v grep | grep -q capiotcp_server ; then killall capiotcp_server ; fi
## if ps | grep -v grep | grep -q telefon ; then killall telefon ; fi
## if ps | grep -v grep | grep -q voipd ; then voipd -s ; fi
## sleep 2
## if ps | grep -v grep | grep -q voipd ; then killall voipd ; fi
## sleep 3
## if lsmod | grep -q isdn_fbox ; then rmmod isdn_fbox ; fi
## sleep 3
## if lsmod | grep -q ubik2 ; then rmmod ubik2 ; fi
## fi
## return 0
 
Dann die Box neustarten und post_install wird beim nächsten Start ausgeführt.
Wenn es nur um den "Angriff" geht, dann ist der umgehende Neustart notwendig - ansonsten wird die "/var/post_install" halt immer im Rahmen des Reboots ausgeführt (sieht man ja auch in den Statements, daß da die Dienste der Box heruntergefahren werden) und das kann zu irgendeinem beliebigen Zeitpunkt sein.

Die "/var/post_install" ist ja auch nur ein möglicher Ansatz ... da diese bereits ausreicht, um eine geänderte Firmware zu installieren oder die installierte Firmware vor dem Neustart noch auf den NAS-Speicher zu kopieren, habe ich die eben immer besonders im Fokus - sie ist auch für "proof of concepts" immer ein dankbares Ziel der Demonstration (noch besser ist nur das Schreiben mit "eventadd" ins Ereignisprotokoll bei einer Demo).

Mit ein wenig Überlegung findet man auch noch andere "Hebel", wo das Schreiben nach "/var" der Aufhänger ist. Wobei ... woanders ist das Dateisystem ja gar nicht zu beschreiben, wenn man mal von "/wrapper" bei den NAND-Boxen und "/nvram" bei DOCSIS (hierhin schreibt ja auch @fesc die SSH-Keys) absieht, was man nun nicht unbedingt als primäres Ziel für eigene Dateien ansehen sollte (auch wegen beschränktem Platzangebot an diesen Stellen).

Über die Supportdaten komme ich an die provideradditive.tar. (...) Wüsste nicht wie man das ohne telnet Zugriff anstellt.
Die braucht man ja eigentlich gar nicht ... entscheidend ist ja nur die Feststellung, daß vorhandener Inhalt von TFFS-Node 29 beim Start des Systems mittels "tar" entpackt wird. Nirgendwo steht, daß dieser Datenstrom einen auch nur ähnlichen Inhalt wie eine vom Provider bereitgestellte "provideradditive.tar" haben muß - es ist sogar kontraproduktiv (komme ich später zu).

Wie bringe ich die provideradditive.tar wieder auf die Box? Bastel ich das in ein TFFS-Image und spiele das über EVA ein? Die Settings der Fritz!Box sind mir ja egal - im Zweifel spiel ich den export wieder ein.
Das ist zumindest ein denkbarer Weg ... man muß nur wissen, daß es sich beim Payload um einen mittels "zlib_deflate" komprimierten Datenstrom handelt. Dieses Komprimieren geht im Zweifel mit "gzip" (wenn man die Daten da herausfummelt), einfacher ist aber z.B. die Verwendung von "openssl" auch für diesen Zweck.

Wie man aus einem TFFS-Dump und einer eigenen Datei für Node 29 wieder ein TFFS-Image erstellen kann (mit den Tools aus "tffs" sollte das machbar sein), habe ich irgendwo hier mal mit @Kingtutt diskutiert (IIRC), das sollte sich noch finden lassen und im Prinzip ist es dasselbe wie beim "Löschen" der falschen Einstellungen über ein neues TFFS-Image, nur daß eben noch der Payload für Node 29 (als 001d.bin) dazugepackt wird.

Das Putzige an der Behandlung des Inhalts von Node 29 ist es, daß der dort vorhandene Datenstrom zwar immer entpackt wird ... wenn sich daraus aber kein Verzeichnis "/var/tmp/providers/provider_additive" ergibt (weil der Payload gar kein Unterverzeichnis "provider_additive" enthielt), dann wird dort auch nichts neu gepackt und zurückgeschrieben ins TFFS. Ansonsten kann es nämlich durchaus auch passieren, daß der "ctlmgr" den (leicht modifizierten - z.B. in der "startinfo.txt") Inhalt des "provider_additive"-Verzeichnisses wieder zusammenpackt und damit den bisher vorhandenen Inhalt überschreibt (dafür dienen wohl die "tar c"-Aufrufe) ... dann natürlich ohne den Symlink und jeden weiteren Inhalt, den man dort gerne hätte, wenn man diese Lücke selbst ausnutzen möchte und die nicht nur als Geschenk an den Provider sieht.
 
Zuletzt bearbeitet:
Ah super, danke für die Klarstellung, da ist es für dieses Szenario tatsächlich irrelevant, dass die provideradditive.tar enthalten sein muss.
Deine Diskussion über das TFFS-Dump Thema mit Kingtutt ist hier zu finden: http://www.ip-phone-forum.de/showthread.php?t=284991&page=2

Auf jeden Fall viele Infos für mich, die ich erstmal ordnen muss.
Theoretisch ist jetzt auf jeden Fall schon mal klarer für mich - praktisch dauerts sicherlich noch bis ich ein modifiziertes TFFS-Image in die Box flashen kann. Muss einfach mal Schritt für Schritt vorgehen und das ganze selbst durchführen, dann ergeben sich sicherlich auch noch Fragen.
 
Ich hab meine 6490 (ehem. UM, weiß) Dank der vielen tollen Infos, Tipps und Anleitungen hier im Thread/Forum bei KDG wieder online gebracht. Die Box wurde am 1. August noch mit FW 6.50 schon einmal für 1 Woche aktiviert und flog dann wieder raus. Jetzt mit modfizierter FW 6.62 konnte ich sie endlich wieder aktivieren.

Ich nutze das script von fesc um dropbear und natives IPv6 zu aktivieren. Nochmals vielen Dank @fesc dafür.

IPv6 funktioniert hier bei KDG eigentlich super - leider nur bis zum nächsten Neustart, dann muß ich es wieder aktvieren.
Ich weiß, das steht auch in der README, aber gibt es dafür eine Erklärung? Warum deaktiviert AVM eigentlich das native IPv6 für die 6490?
 
IPv6 funktioniert hier bei KDG eigentlich super - leider nur bis zum nächsten Neustart, dann muß ich es wieder aktvieren.

Was mußt Du den in Web-IF tun, damit IPv6 aktiv ist;
könntest Du einen Screenshot posten ?
dann kann man den entsprechenden Befehl aus LUA-Skript nachsehen, der für Eintrag in debug.cfg erforderlich wäre.
BTW: Ist im fesc Image die debug.cfg (Minor ID 0x62) aktiv ?
 
Was mußt Du den in Web-IF tun, damit IPv6 aktiv ist;
könntest Du einen Screenshot posten ?
dann kann man den entsprechenden Befehl aus LUA-Skript nachsehen, der für Eintrag in debug.cfg erforderlich wäre.
hmm, wäre ein recht unschöner workaround...
Im Prinzip aber einfach nur wieder "Unterstützung für IPv6 aktiv" und "Immer eine native IPv6-Anbindung nutzen", der Rest bleibt gespeichert.
Screenshot.jpg
BTW: Ist im fesc Image die debug.cfg (Minor ID 0x62) aktiv ?

Code:
release 6
---------
- Store/move dropbear keys to /nvram
- Kill telnetd after 5 minutes
- Do not start telnetd on atom by default
[COLOR=#ff0000][B]- Remove execution of /var/flash/debug.cfg[/B][/COLOR]
- Add ssh as symlink to dbclient
- Add /.ssh as symlink to /var/tmp/root-ssh, and 
  link this to nvram at startup
- Repack telnet-1.tar with busybox (same for release image)
 
Zuletzt bearbeitet:
IPv6 funktioniert hier bei KDG eigentlich super - leider nur bis zum nächsten Neustart, dann muß ich es wieder aktvieren.
Ich weiß, das steht auch in der README, aber gibt es dafür eine Erklärung? Warum deaktiviert AVM eigentlich das native IPv6 für die 6490?

Ich war bisher zu faul das herauszufinden. Es ist per default so dass nur ipv6 Tunnel moeglich sind, native ist in der Oberflaeche nicht waehlbar (ist das eigentlich bei allen so?).
Der entsprechende Eintrag in ar7.cfg (ipv6_native_hidden) wird bei jedem boot auf yes gesetzt. Weiss nicht wo und warum.
Ich habe im lua code einfach die entsprechende Abfrage geaendert, damit ist der "native button" waehlbar und es funktioniert einwandfrei ..
Beim naechsten reboot ist ipv6 wieder aus. Ich weiss nicht ob das an meinem Patch liegt oder ob das auch bei allen (ungepatchten) boxen so ist.
 
ipv6 Tunnel bleibt erhalten, falls das die Antwort auf Deine Frage ist.
 
Ab der 6.63 ist das IPv6 Problem gefixt, zumindestens funktioniert es in der Labor Version von AVM derzeit.
 
Labor 06.63-34331 für die 6490, weiß nicht wann die als Release raus kommt.
 
wo hast die gefunden? wäre auch sehr interessiert an der Labor :)
 
Die wird eher nicht öffentlich sein.
 
Nee die ist nicht öffentlich, nur weil es gerade um IPv6 ging, wollte ich mitteilen das es ab der 6.63 wohl nicht mehr so mühsam sein wird es zu aktivieren.
Eh man jetzt hier rumbastelt, wird es einfacher sein auf das nächste Release zu warten.
 
Nee die ist nicht öffentlich, nur weil es gerade um IPv6 ging, wollte ich mitteilen das es ab der 6.63 wohl nicht mehr so mühsam sein wird es zu aktivieren.
Eh man jetzt hier rumbastelt, wird es einfacher sein auf das nächste Release zu warten.
Es soll ja schonmal vorkommen das der passende Download im Netz auftaucht. :p
Gibt es schon eine Changelog zur 6.63 in irgendeiner Form?
 
hm, wollte mich mal mit den Dateien auf der 6490 beschäftigen....bin aber nicht in der Lage eine Verbindung aufzubauen wo ich die Verzeichnisstruktur einlesen/sehen kann
mit der Eingabeaufforderung (CMD) kann ich ja die bekannten Befehle ausführen... aber mit was komme ich an die Dateien? mit flashfxp komme ich auch nicht ins Verzeichnis...
(Ich weiß, für Euch Profis eine doofe Frage... aber so bin ich halt :) )
bitte um ein paar Hilfestellungen^^
danke
 
Es geht nicht, "von außen" auf die Dateien des FRITZ!OS zuzugreifen (nur auf die freigegebenen NAS-Verzeichnisse) ... die Dateien in so einer Firmware sieht man sich am besten an, indem man das Firmware-Image von AVM lädt und die dort enthaltenen Daten entpackt.
 
@Presswurst:
Nutze zum Entpacken der Firmware ein x86 Linux (wo auch immer, ne lokale VM oder ne virtual appliance in der Cloud reicht wohl leicht), dann kannst du das von PeterPawn fertig kompilierte unsquashfs nutzen (das findest du hier: https://github.com/PeterPawn/YourFritz/tree/[EDIT: Ein 'normales' / ungepatchtes unsquashfs funktioniert nicht - Ursache ist das verwendete / modifizierte squashfs-Format von avm, genaueres findest du über die Forensuche oder deine favorisierte Suchmaschine ...]

Das von AVM heruntergeladene image kannst du z. B. noch mit 7z entpacken und dir so z. B. die install genauer anschauen. Für filesystem.img führt dann aber kein Weg um unsquashfs herum.
 
Zuletzt bearbeitet:
@scuros
Was muss man machen, damit AVM diese Firmware rausgibt? Gibt es einen Betatest?
 
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.