[Gelöst] freetz-trunk erstellt .image und .image.in-memory

@WileC:
Das ist ein PowerShell-Skript ... dieses neue "command line interface" ist seit einigen Windows-Versionen Bestandteil des Systems.

Um unsignierte Skript-Dateien zu verwenden, muß man eine (Sicherheits-)Einstellung anpassen (die kann man ggf. im Anschluß wieder ändern) oder die Dateien selbst signieren (auch dazu muß man Einstellungen anpassen, daher ist die erste Option die einfachere) - das ist auch keine "Spezialität" meiner Dateien, das gilt für alle "ps1"-Dateien (bzw. die Verwendung von PowerShell). Wie das geht, steht im Internet ...

Dann kann man mit "EVA-Discover.ps1" die FRITZ!Box in Netzwerk suchen lassen (das ist optional und erleichtert die Handhabung, weil man die FRITZ!Box an den Computer anpassen kann und nicht den Computer (beim Netzwerk) umkonfigurieren muß) und bei der Verwendung von "EVA-FTP-Client.ps1" muß man entweder die Datei vorher anpassen (ab Zeile 605, wie steht in der Datei an dieser Stelle) oder man gibt beim Aufruf einen "ScriptBlock" als zweiten Parameter an (wie das geht, findet man im Internet bei der Suche nach "powershell script block") und führt darin die auszuführenden Aktionen auf. Hier düfte "BootDeviceFromImage" die richtige Wahl sein für das Thema dieses Threads ...
 
@PeterPawn:
Danke schonmal. Also müsste ich...

...unter Linux 1.) ./eva-discover ausführen und 2.) eva-to-memory /home/freetz/images/blaba.image.in-memory ?

... unter Windows 1.) eva_discover.ps1 und danach in der eva-ftp-client.ps1 die Zeile "BootDeviceFromImage d:\temp\blabla.image.in-memory" entkommentieren und dann nacheinander ausführen ?! bin ich so richtig oder mal iweder auf dem Holzweg ?!

Vielen Dank schonmal für die Unterstützung.
 
Bei passender Ergänzung von Parametern für so ziemlich jeden Aufruf, paßt das dann.

Bei den PowerShell-Skripten steht die Parameter-Beschreibung am Beginn der Dateien und bei den (Linux-)Shell-Skripten steht sie entweder im Header der Datei als Kommentar oder die ersten Zeilen weisen die Parameter internen Variablen zu, wo man dann auch die Standardwerte für ausgelassene Parameter sehen kann.

Ich betone einfach noch einmal, daß praktisch alle Skript-Dateien von mir ("modfs" ist ein wenig davon abweichend zu sehen) darauf ausgelegt sind, daß sich der "Verwender" mit den Prinzipien der jeweiligen Plattform und des verwendeten Shell-Interpreters zumindest ein wenig auskennt. Ist das bei irgendjemandem nicht gegeben, wäre vor der Anwendung der Blick ins Internet anzuraten.

Das geht jetzt nicht direkt an die Adresse von @WileC, das ist die Zusammenfassung von mehreren Beiträgen anderer IPPF-Member in diversen anderen Threads, die mit den Skript-Dateien nicht klarkommen. Das ist keine Zauberei, sie zu verwenden ... aber auch nichts (absichtlich) für Fr. Kasulske, die gerade mal den PC einschalten kann und das ginge vielleicht an einigen Stellen sogar einfacher, aber ein Minimum an Beschäftigung mit der verwendeten Umgebung setze ich einfach voraus.
 
Also ich hab mich jetzt mal mit meiner 3490 herumgespielt, doch irgendwie klappt das nicht, bzw. ich finde den Fehler nicht :(

Ergebnis "EVA-Discover.ps1"
Code:
EVA_IP=192.168.178.1
true

Ergebnis "EVA-FTP-Client.ps1 192.168.178.1 { BootDeviceFromImage d:\temp\3490_06.80.image.in-memory }"
Code:
Ausnahme beim Aufrufen von "Invoke" mit 1 Argument(en):  "Error uploading image file."
Bei D:\temp\EVA-FTP-Client.ps1:602 Zeichen:36
+                 $ScriptBlock.Invoke <<<< ()
    + CategoryInfo          : NotSpecified: (:) [], MethodInvocationException
    + FullyQualifiedErrorId : DotNetMethodException

Fehler beim Aufrufen der Methode, da [System.Net.Sockets.TcpClient] keine Methode mit dem Namen "Dispose" enthält.
Bei D:\temp\EVA-FTP-Client.ps1:662 Zeichen:30
+ $Global:EVAConnection.Dispose <<<< ()
    + CategoryInfo          : InvalidOperation: (Dispose:String) [], RuntimeException
    + FullyQualifiedErrorId : MethodNotFound

Was mache ich verkehrt??

Mit "EVA-FTP-Client.ps1 192.168.178.1 { RebootTheDevice }" kommt folgende Ausgabe:
Code:
True
Fehler beim Aufrufen der Methode, da [System.Net.Sockets.TcpClient] keine Methode mit dem Namen "Dispose" enthält.
Bei D:\temp\EVA-FTP-Client.ps1:662 Zeichen:30
+ $Global:EVAConnection.Dispose <<<< ()
    + CategoryInfo          : InvalidOperation: (Dispose:String) [], RuntimeException
    + FullyQualifiedErrorId : MethodNotFound
Dennoch startet die Box neu.
 
Zuletzt bearbeitet:
Ich tippe mal auf eine alte Version der PowerShell bzw. der .NET-Runtime. Wenn die Klasse "System.Net.Sockets.TcpClient" keine "Dispose()"-Methode anbietet, dann müßte die schon "etwas älter" sein.

Im Script-File steht ab Zeile 354, welche Versionen mindestens vorhanden sein sollten - m.W. sind hier auch keine Methoden bei steigenden Versionsnummern wieder "abgeschafft" worden.

Ich habe keine Ahnung, auf welchem Basis-System Du das gestartet hast - ggf. braucht dieses System ein Update (wobei das eigentlich schon sehr lange "im Angebot" ist). Grob würde ich mal schreiben, es braucht PowerShell 3.0 und die .NET-4.0-Runtime - aber ohne Garantie meinerseits.
 
Du hast richtig getippt. Ich habe auf meinem Win7 SP1 mal ein Update auf das WMF5.1 durchgeführt und schon klappt's auch "mit dem Nachbarn"... sowas...

Im EVA-FTP-Client.ps1 habe ich die Zeile mit dem "BootDeviceFromImage" auskommentiert und die image-datei angegeben. Hat auch geklappt.

Nun habe ich aber noch eine Frage wegen dem Aufruf des Skripts mit Parametern; Wo habe ich hier den "Denk"-Fehler drin?!

PS> .\EVA-FTP-Client.ps1 192.168.178.1 { BootDeviceFromImage .\3490_06.80.image.in-memory }

Danke.
 
Auch da könnte ich jetzt raten (und würde dann darauf tippen, daß der relative Pfad zur Image-Datei nicht funktioniert) ... aber dafür gibt es ja die Möglichkeit, z.B. durch die Angabe der "-Debug"-Option beim Aufruf, sich etwas genauer anzusehen (weil man den FTP-Dialog verfolgen kann), wo es am Ende wirklich klemmt.
 
Aber der Aufruf stimmt so? Dann werde ich mal den Debug versuchen und das Ergebnis posten.

---

Mit der absoluten Pfadangabe klappt auch der Upload des Images über den ScriptBlock.

Hier der Debug mit relativen Pfad zur Image-Datei :
Code:
PS D:\Temp> .\EVA-FTP-Client.ps1 -ScriptBlock { BootDeviceFromImage -filename [B].\3490_06.80.image.in-memory[/B] -debug }
DEBUG: Sent
GETENV memsize
================
DEBUG: Response:
memsize               0x10000000

200 GETENV command successful

================
DEBUG: Memory size found    : 0x10000000
DEBUG: Image size found     : 0x0176a100
DEBUG: Set memory size to   : 0x0e895f00
DEBUG: Set MTD ram device to: 0x8e895f00,0x90000000
DEBUG: Sent
SETENV memsize 0x0e895f00
================
DEBUG: Response:
200 SETENV command successful

================
DEBUG: Sent
SETENV kernel_args_tmp mtdram1=0x8e895f00,0x90000000
================
DEBUG: Response:
200 SETENV command successful

================
DEBUG: Sent
TYPE I
================
DEBUG: Response:
200 Type set to BINARY

================
DEBUG: Sent
MEDIA SDRAM
================
DEBUG: Response:
200 Media set to MEDIA_SDRAM

================
DEBUG: Uploading file '.\3490_06.80.image.in-memory' to '0x8e895f00 0x90000000' ...
DEBUG: Sent
P@SW
================
DEBUG: Response:
227 Entering Passive Mode (192,168,178,1,12,14)

================
DEBUG: Sent
SETENV memsize 0x10000000
================
DEBUG: Response:
200 SETENV command successful

================
DEBUG: Sent
UNSETENV kernel_args_tmp
================
DEBUG: Response:
501 environment variable not set

================
Exception calling "Invoke" with "0" argument(s): "Error uploading image file."
At D:\Temp\EVA-FTP-Client.ps1:602 char:17
+                 $ScriptBlock.Invoke()
+                 ~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [], MethodInvocationException
    + FullyQualifiedErrorId : RuntimeException

Und hier mit der absoluten Pfadangabe der Image-Datei:
Code:
PS D:\Temp> .\EVA-FTP-Client.ps1 -ScriptBlock { BootDeviceFromImage -filename D:\Temp\3490_06.80.image.in-memory -debug
}
DEBUG: Sent
GETENV memsize
================
DEBUG: Response:
memsize               0x10000000

200 GETENV command successful

================
DEBUG: Memory size found    : 0x10000000
DEBUG: Image size found     : 0x0176a100
DEBUG: Set memory size to   : 0x0e895f00
DEBUG: Set MTD ram device to: 0x8e895f00,0x90000000
DEBUG: Sent
SETENV memsize 0x0e895f00
================
DEBUG: Response:
200 SETENV command successful

================
DEBUG: Sent
SETENV kernel_args_tmp mtdram1=0x8e895f00,0x90000000
================
DEBUG: Response:
200 SETENV command successful

================
DEBUG: Sent
TYPE I
================
DEBUG: Response:
200 Type set to BINARY

================
DEBUG: Sent
MEDIA SDRAM
================
DEBUG: Response:
200 Media set to MEDIA_SDRAM

================
DEBUG: Uploading file 'D:\Temp\3490_06.80.image.in-memory' to '0x8e895f00 0x90000000' ...
DEBUG: Sent
P@SW
================
DEBUG: Response:
227 Entering Passive Mode (192,168,178,1,12,6)

================
DEBUG: Sent
STOR 0x8e895f00 0x90000000
================
DEBUG: Response:
150 Opening BINARY data connection

================
DEBUG: Response:
226 Transfer complete

================
True
 
Zuletzt bearbeitet:
Mir ist noch aufgefallen, dass das make bei einer 7390 keine .image.in-memory erstellt. Wir dann einfach die .image beim Upload via EVA-FTP-Client.ps1 benutzt?
 
Die 7390 ist doch eine klassische NOR-Flash Box (ohne DualBoot) ein ".image.in-memory" wird dort doch gar nicht benötigt, der NOR-Flash kann vom Bootloader aus direkt beschrieben werden...
 
Dann brauche ich mittels EVA-FTP-Client nur die .image hochladen? Richtig?
 
Ja, wenn Du dabei die korrekte Funktion "UploadFlashFile" anstelle von "BootDeviceFromImage" benutzt. Ziel des Uploads ist (aus der Erinnerung, vorher noch einmal selbst nachlesen) "mtd1" bei der 7390 - das enthält das hintereinanderkopierte Kernel- und Dateisystem-Image, was bei den NOR-Modellen alles in der Datei "kernel.image" zu finden ist (die "filesystem.image" sollte eine Länge von 0 Byte haben).

Ob Freetz eine Image-Datei mit dem NMI-Vector erstellt bzw. ob der bei der 7390 wirklich gebraucht wird, weiß ich auch nicht mehr aus dem Kopf. Bis auf ein paar Probleme beim automatischen Restart im Fehlerfall (ansonsten dürfte so ein NMI (non-maskable interrupt) gar nicht auftreten) wird das Fehlen des NMI-Vectors aber (vermutlich) auch keine sichtbaren Konsequenzen haben. Beim "dump" des Inhalts der Partition aus dem lfd. System heraus würden diese (normalerweise) 256 Byte ohnehin übersprungen - wenn man sich den Treiber für den Flash-Zugriff ansieht.

Ob die nun in einem (AVM-)Recovery-Image bei der 7390 enthalten wären oder nicht, müßte man ggf. erst noch einmal mit einem Packet-Dump verifizieren - keine Ahnung, wie der Bootloader beim Schreibbefehl für die Partition das handhabt.
 
Ob Freetz eine Image-Datei mit dem NMI-Vector erstellt bzw. ob der bei der 7390 wirklich gebraucht wird, weiß ich auch nicht mehr aus dem Kopf.
Freetz-modifizierte Images (bzw. ganz korrekt gesprochen fwmod-repackte Images) enthalten keinen NMI-Vector. Es wäre allerdings nicht so schwierig diese Funktionalität einzubauen. Der Code zum Dumpen ist bereits vorhanden. Man müsste lediglich die Länge gemäß dem erstellten kernel.image (ohne TI-checksum) korrekt setzen.
 
Hallo!
Ich versuche gerade meinen Fritzbox 7272 zu flashen. Ich nutzen Linux Mint und komme bis zum Bootloader der Box. Wenn ich dann den Aufruf eingebe:
Code:
busybox sh eva_to_memory /.../xxx-image.in-memory
erhalte ich folgende Fehlermeldung:

Code:
Found AVM bootloader: AVM EVA Version 1.1823 0x0 0x640D
BusyBox v1.22.1 (Ubuntu 1:1.22.0-15ubuntu1) multi-call binary.

Usage: nc [-iN] [-wN] [-l] [-p PORT] [-f FILE|IPADDR PORT] [-e PROG]

Open a pipe to IP:PORT or FILE

    -l    Listen mode, for inbound connects
        (use -ll with -e for persistent server)
    -p PORT    Local port
    -w SEC    Connect timeout
    -i SEC    Delay interval for lines sent
    -f FILE    Use file (ala /dev/ttyS0) instead of network
    -e PROG    Run PROG after connect

Ich haben mal mit nc gespielt und unter anderem auch die "traditional version" verwendet. Ich bekomme aber immer den gleichen Fehler.
Jemand eine Idee was das Problem sein könnte?

Gruß

Loron
 
Zuletzt bearbeitet:
Das verwendete "nc"-Kommando muß die Optionen "-w" und "-d" (nicht von STDIN lesen, nur die Netzwerk-Daten nach STDOUT schreiben) unterstützen (für die Verarbeitung der Datenverbindung, die Control-Verbindung kommt ohne diese Optionen aus) ... das macht zumindest die "NetBSD"-Variante: https://linux.die.net/man/1/nc - aber die BusyBox-Version nicht (und wohl auch nur wenige "traditional netcat"-Versionen).

Das könnte man vermutlich noch anders gestalten ... indem man bei jedem "nc"-Aufruf einen FIFO als STDIN verwendet und in diesen halt dann nichts schreibt. Ansonsten versucht das "nc" von STDIN zu lesen, kriegt dort ein "EOF" und beendet sich gleich wieder, wenn es nicht von einem Terminal aufgerufen wurde, wo STDIN dann von der Tastatur lesen würde (deshalb klappt so ein Aufruf von der Kommandozeile auch ohne diese "-d"-Option).
 
Hallo!
Ursprünglich war die openbsd-Variante eingestellt. Damit hat es leider auch nicht funktioniert. Ich gucke noch mal wegen der Shell.. ich muss immer busybox voranstellen.. obwohl ich eigentlich umgestellt habe auf bash (von dash).
 
Improvement

Das Problem mit dem relativen Pfad und dem absoluten Pfad könnte umgangen werden, wenn in der EVA-FTP-Client.ps1 in folgenden Abschnitten und Zeilen die Variable $filename in den absoluten Pfad mittels
Code:
$filename = Resolve-Path $filename
bearbeitet wird.

So wird unabhängig der Pfadangabe die Variable in den absoluten Pfad konvertiert...

Mögliche Veränderungen:
function UploadFlashFile, entweder in der Zeile 212 oder 227;

function BootDeviceFromImageFile, Zeile 242.

Ich habs für mich mit einem Skript "außenrum" gelöst, welches noch andere Überprüfugen durchführt, Variablen "umwandelt" und die Skripte von PeterPawn für mich richtig aufruft. Quasi ein HowTo als Skript ;)
 
@WileC:
DAS wäre nun tatsächlich eine Änderung, die ich als sinnvoll erachte, wenn man damit eine genauere Fehlermeldung und umfangreichere Prüfung auch gleich noch verbindet.

Dazu gehört dann zunächst die Prüfung, daß das Ergebnis von Resolve-Path tatsächlich ein lokaler Dateiname ist (UNC-Pfade würde ich persönlich per Definition an dieser Stelle verbieten, weil ich Netzwerk-Probleme bei vielen Benutzern erwarten würde, die dann bloß wieder zusätzliche Fragen provozieren) und daß es auch nur eine dedizierte Datei ist - Resolve-Path löst ja auch Wildcards auf und die Rückgabe könnte auch ein String-Array sein.

Dann kann/sollte man auch gleich noch "ObjectNotFound" beim Resolve-Path abfangen, weil sich daraus dann wirklich die passende Fehlernachricht (Datei existiert nicht oder ist nicht lesbar) ableiten und anzeigen läßt (BootDeviceFromImage verwendet bisher "Test-Path" zur Prüfung) und schlußendlich kann man dann auch gleich noch prüfen, daß man (also der Benutzer) tatsächlich die Rechte hat, diese Datei zu öffnen und zu lesen bzw. daß diese Datei nicht leer ist (oder daß das zumindest absichtlich so ist).

Damit "umgeht" man dann auch noch ein paar unnötige Aktionen ... beim Senden des STOR-Kommandos löscht die Box ja zunächst die zu beschreibende Flash-Partition (jedenfalls darf man annehmen, daß es das ist, was die relativ lange Pause zwischen dem Senden des Kommandos und dem Öffnen der Datenverbindung seitens der Box verursacht) und wenn dann die Datei wegen eines bisher "ungetesteten" Problems gar nicht gesendet werden kann, geht (a) der bisherige Inhalt der Partition unnötigerweise verloren und (b) kriegt der Flash (vermutlich, genau weiß ich das natürlich auch nicht, aber ich glaube nicht, daß da vorher geprüft wird bei NOR oder SPI) beim nächsten Versuch dann noch einen weiteren Löschzyklus verordnet, der seine Lebensdauer (ebenfalls unnötig) verringert.


-Wobei ich ohnehin mal etwas genauer getestet habe und (für mich) zu der Feststellung gekommen bin, daß die Implementierung des FTP-Servers in verschiedenen Modellen und Versionen des Bootloaders durchaus unterschiedlich ist. Die besten (reproduzierbaren) Ergebnisse habe ich erhalten, wenn ich das komplette FTP-Protokoll für jede Sitzung durchlaufen lasse. Alles andere liefert früher oder später einen Fehler ... bei der 7580 (bootloaderVersion 1.3229 - die Variable "urlader-version" ist gar nicht gesetzt, wie das bei anderen Modellen m.W. der Fall ist) kann ich z.B. mit einem zusätzlichen "QUIT" nach der "211 Goodbye"-Meldung problemlos dafür sorgen, daß die Box auf den nächsten Versuch einer FTP-Verbindung gar nicht mehr reagiert (und der Stecker gezogen werden muß). Da kommt wohl die "state machine" des Servers etwas durcheinander und das wird wohl nicht ordentlich zurückgesetzt nach einem FIN ... und mehrere parallele Verbindungen funktionieren ja ohnehin nicht (zumindest nicht bei den Modellen, auf die ich Zugriff habe).

Das heißt dann, daß es auch für das "Festhalten" der Box im Bootloader in den beiden Discovery-Skripten die vermutlich beste Lösung ist, wenn man da nicht nur eine Verbindung aufbauen läßt und diese dann einfach wieder schließt oder mit "QUIT" beendet (worauf der Server ja dann teilweise auch noch mit "530 not logged in" anstatt mit "211 Goodbye" reagiert), sondern wenn man sich tatsächlich komplett einloggt (also USER und PASS sendet) und sich erst dann mit "QUIT" wieder verabschiedet. Dann ist es mir zumindest bei allen hier vorhandenen Modellen (7490, 7412, 6490, 7580) gelungen, immer wieder aufs Neue eine Verbindung mit dem Bootloader per FTP herzustellen und so in mehreren FTP-Sitzungen (ohne zwischenzeitliche Neustarts) mehrere Aktionen nacheinander auszuführen.

Nun fehlt aber in den beiden Discovery-Skripten der ganze Teil für den FTP-Client (das ist eben etwas mehr als das "blinde Senden" von "QUIT", was der Client da leisten muß) ... und ehe ich da bei der PowerShell-Variante (bei der (Linux-)Shell-Version bin ich noch unsicher) jetzt gegenseitige Aufrufe der beiden ps1-Skripte implementiere, gehe ich wohl den anderen Weg und fasse die beiden zu einem einzelnen zusammen ... dann wird eben "discovery" ein (vielleicht auch nur optionaler) zusätzlicher Schritt vor dem Verbindungsaufbau zum FTP-Server. Obwohl bei der PowerShell-Variante natürlich auch ein FTP-Client mit der passenden .NET-Klasse die Anmeldung und Auswertung der Antworten übernehmen könnte ... das wird noch ein gesonderter, erster Schritt der Änderung an den PowerShell-Versionen sein, damit da ein besseres Ergebnis beim "Festhalten" erzielt wird, bevor ich die Skripte zusammenfasse.

Zumindest die hier verfügbaren Boxen (Liste s.o.) reagieren auch nach den fünf Sekunden unmittelbar nach dem Start (wenn sie erst einmal "festgehalten" wurden) noch auf die UDP-Broadcasts und (zumindest solange sich der FTP-Server in einem "neutralen Zustand" befindet) sogar auf nachträgliche Änderungen der IPv4-Adresse über solche Broadcasts. Damit schadet es vermutlich auch gar nicht, wenn man tatsächlich vor jedem Verbindungsaufbau die (startende oder bereits wartende) Box per UDP-Broadcast suchen läßt und ihr dabei entweder eine "Wunschadresse" zuweist oder sogar nur die aktuell verwendete auf diesem Weg ermittelt und gar nicht mehr als Parameter (egal ob mit oder ohne Standardwert) erwartet. Erst mit einem "REBOOT" oder durch das erfolgreiche Laden eines "in-memory"-Images (und dessen Start) verläßt die Box den "Wartezustand" dann wieder.

Für die PowerShell-Variante werde ich das wohl demnächst umsetzen ... vielleicht wird ja tatsächlich aus einer "Konzeptstudie" noch eine "Lösung", wenn ich das (mehr oder weniger gezwungenermaßen) zusammenführe. Bei der Linux-Variante zögere ich noch etwas, weil es für Discovery eben "socat" bräuchte, während die FTP-Client-Funktionen auch mit "netcat" (sogar ohne spezielle Optionen, wenn man es anders macht als jetzt) auskommen würden und das ist auch gerne mal in einer BusyBox dabei ("socat" ist da schon wesentlich exotischer).
 
Hallo!
Ich bin leider immer noch nicht viel weiter. Mittlerweile wird eva_to_memory ohne Fehler aufgerufen, aber es kommt danach keine weitere Ausgabe. Breche ich mit STRG+C ab, erhalte ich die Meldung:
Code:
 Found AVM bootloader: AVM EVA Version 1.1823 0x0 0x640D
invalid local port -w

Was kann ich noch tun? Was geht schief?

Gruß
 
Wie wäre es denn mal mit dem "usage screen" der eingesetzten "nc"-Variante?

Wenn da "-w" nicht verstanden wird, kann ja irgendetwas immer noch nicht stimmen - bei meinen Nachfragen bei Kassandra, Nostradamus und Rasputin haben die aber abgewunken. Auch ihre seherischen Fähigkeiten reichen offenbar nicht aus, um das Problem ohne weitere Angaben einzugrenzen und dann sollte man als "Normalsterblicher" vermutlich den Versuch besser gleich abbrechen, wenn diese "Koniferen" das schon nicht schaffen.

Das (mehr oder weniger blinde) Vertrauen von manchem ehrt den einen oder anderen ja sicherlich auch ... aber wer immer nur raten muß oder soll, der wird sich früher oder später zwangsweise auch fürchterlich blamieren. Rein nach der Wahrscheinlichkeitsrechnung wird er (oder sie) bei hinreichend vielen, plausiblen Möglichkeiten nicht immer richtig liegen und da "versaut" solche Raterei dann die (persönliche) Erfolgsquote. Da ist es ja nur natürlich, wenn man über solche Probleme einfach hinwegliest.
 
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.