Fb 7360 tr069

lfb63

Neuer User
Mitglied seit
27 Apr 2011
Beiträge
11
Punkte für Reaktionen
0
Punkte
1
Hallo!

Ich lese schon eine Weile mit, habe auch reichlich nützliche Information gefunden und gelesen aber bin der Lösung meines Problemes nicht wirklich näher gekommen.

Die Situation:
- Gebraucht gekaufte 7360 V1 (EWE) funktioniert ohne Probleme, soll durch eine 7360 V2 ersetzt werden.

- 7360 V2 (2000 2522, OEM=avm) wieder gebraucht erstanden
- Die neue Box wirkt OK, war zurückgesetzt, alle Felder leer, startet mit Einrichtungsassistent,
- Neue Box nicht selbst zurückgesetzt (OK, hätt ich sicher nochmal machen sollen.)

- Einstellungen der 7360 V1 gesichert und ohne Probleme von der 7360 V2 angenommen (OK, war vielleicht ein Fehler die Zugangsdaten zurück zu lesen?)

Die neue 7360 funktioniert einwandfrei, hat aber regelmässig den Eintrag:
"Automatische Einrichtung und Updates für dieses Gerät durch den Dienstanbieter nicht möglich: Verbindung zum Autokonfigurationsserver fehlgeschlagen. [12 Meldungen seit .....] "
Die tr069-cfg enthält nun Zugangsdaten für einen Server (acs.inexio.net), der allerdings anscheinend glücklicherweise nicht erreichbar ist. Diese Zugangsdaten waren in der importierten Daten nicht enthalten.

Die Fragen:
- Ist das eine "verdeckt gebrandete" Box? Oder
- Ist das ein Fehler, der durch das Einlesen der alten Konfiguration oder Zugangsdaten aufgetreten ist? Und
- Wie werd ich das wieder los?

Wäre die Box in meiner Nähe, würde ich sie nochmal selbst zurücksetzen, die Zugangsdaten manuell eingeben und schauen, was dann in der tr069.cfg steht. Leider steht die Box jetzt 1500km entfernt und der dortige Nutzer ist über 80 und nicht von ausufernder Experimentierlust geplagt. Da ich nur über VPN Zugang zur Box habe, sind meine Möglichkeiten, Fehler zu korrigieren, auch eingeschränkt.

Am einfachsten und recht sicher wäre wohl das direkte Editieren der tr069.cfg mit einem shell Zugang, der aber mit den neueren Firmwareversionen anscheinend nicht mehr so einfach herzustellen ist. Würde auch nicht funktionieren, wenn die Box ein verdecktes(?) Branding hätte.
Nächste Variante wäre das Editieren der Sicherung, Checksum neu berechne, Zurückspielen der korrigierten Sicherung. Sollte dabei allerdings was schief gehen, steht alles einschliesslich Telefon. Und würde auch nicht funktionieren, wenn da ein verdecktes Branding wäre.


Wenn also jemand einen Tip hat für eine (fast) gefahrlose Lösung oder wo ich mich weiter schlau machen könnte- ich wäre sehr dankbar!!


tr069.cfg der alten 7360:
tr069cfg {
enabled = no;
litemode = no;
tr181_support = no;
dhcp43_support = yes;
igd {
DeviceInfo {
FirstUseDate = "1970-01-01 01:00:00";
}
managementserver {
url = "";
username = "";
password = "";
...................
}
}
FirmwareDownload {
enabled = yes;
enabled_converted = no;
............
}
RebootRequest = no;
guimode = guimode_visible;
}


tr069.cfg der neuen 7360 V2
tr069cfg {
enabled = yes;
litemode = no;
tr181_support = no;
dhcp43_support = yes;
igd {
DeviceInfo {
FirstUseDate = "2017-04-07 13:26:26";
}
managementserver {
url = "https://acs.inexio.net";
username = "$$$$QDCBCVPXVAJ.....";
password = "$$$$RMYOXGNPMD.....";
............
}
}
FirmwareDownload {
enabled = yes;
enabled_converted = yes;
............
}
RebootRequest = no;
RebootRequest_CommandKey = "";
ACS_SSL {
verify_server = no;
}
Download_SSL {
verify_server = no;
}
guimode = guimode_hidden;
lab {
Enable = yes;
URLAlreadyContacted = no;
PeriodicInformInterval = 0;
Features = 65535;
}
}

- - - Aktualisiert - - -

OK, nochmal weitergesucht und anscheinend ist das eine Box mit "providerspezifischer Konfiguration". In den per Supportseite der Fritzbox ausgelesenen Daten findet sich

"provider inexio7360"


Das tr069.log liest sich:
2017-04-16 20:48:26.400 - ConnectNow() connector() <acs.inexio.net:443>
2017-04-16 20:48:26.400 - tr069 via internet connection has IPv4: dnsctx=tr069|tr069dnsprefer_ipv4
2017-04-16 20:50:33.760 - CSessionManager::disconnected() csock_reason=1, connect_error=1


Allerdings gibt es zwischendurch wohl empfangene(?) requests:
2017-04-15 13:18:36.812 - pcp_item_complete(): error
2017-04-15 13:18:41.245 - pcp_item_complete(): ok
2017-04-15 13:18:41.245 - pcp_item_complete(): ACS incoming (79.233.76.114:.....) opened.

Wenn ich das richtig lese, scheint das ein aber telekom- Server zu sein?

- - - Aktualisiert - - -

Wenn diese Anleitung noch mit der 6.83 Firmware funktioniert, wäre das Vorgehen zum Entfernen der providerspezifischen Konfiguration" (relativ) klar? (Vielen Dank an PeterPawn)

Bleibt nur noch die Frage, wie ich das via VPN Verbindung über die Fritzbox ausführe und wie ich danach die tr069 Einstellunge zurücksetzen kann, ohne die ganze Box zurückzusetzen?
 
Zuletzt bearbeitet:
Das sind nun mal alles Fragen, die man bereits vor der Weitergabe so einer Box klären sollte, wenn man im Nachgang nur noch per VPN auf diese Box kommt.

Wirklich (fast) alles, was man hier machen könnte (von Recovery bis Shell-Zugang zum Löschen von Node 29), damit diese Konfiguration nicht erneut auftaucht, ist inzwischen nur noch lokal zu lösen oder mit entsprechendem Know-How und Equipment (z.B. durch das Eintragen eines eigenen Servers als ACS und RCE über diesen Server) vielleicht gerade noch so aus der Ferne.

Ohne Shell-Zugang wird nicht einmal das Löschen der "tr069.cfg" funktionieren - der Weg über die Export-Datei wurde ja auch schon als "riskant" eingeschätzt und da stellt sich dann wirklich die Frage, was man da noch machen will. Mir fiele tatsächlich nur noch das Ausnutzen von bekannten Sicherheitslücken ein, um auf der Box einen Shell-Zugang zu erhalten und dann mit diesem sowohl die "provideradditive.tar" (meinetwegen auch noch den "provider"-Eintrag im Environment, wobei der keinen Menschen interessiert, solange kein Recovery gemacht werden muß) als auch die "tr069.cfg" zu löschen.

Wenn da PCP verwendet wird, ist es wohl auch keine ältere Firmware und damit fiele mir nur der Weg über die Skript-Datei im NAS und das Export-Kennwort (oder das manuelle Firmware-Update per TR-064) ein, um da eigene Kommandos auszuführen ... wobei die Skript-Datei dann auch anstelle der Vorbereitung für einen Shell-Zugang (was ohnehin schwierig ist, denn beide Wege enden in einem Neustart) gleich die Nodes 29 und 119 (letzterer ist die "tr069.cfg") direkt löschen kann (und anschließend sich selbst, damit das eine einmalige Aktion bleibt) ... dann sollte nach dem nächsten Neustart der ACS-Server auch raus sein und er kann auch über die "provideradditive.tar" nicht erneut gesetzt werden.

Wobei ich zumindest vorher noch klären würde, was ansonsten noch in der "provideradditive.tar" von inexio geändert wird (sprich: diese Datei erst einmal sichern, bevor man sie überschreibt) ... ggf. ist es sogar schlauer, nach dem Entfernen der Provider-Konfiguration aus dem TFFS noch einmal die ältere Konfiguration zu importieren - natürlich ist auch das mit einem Risiko verbunden, wenn man es per Fernwartung macht (daher die Eingangsthese).

Bis zu dem Punkt, wo es um das Wiederherstellen der gesicherten Einstellungen geht, ist das (bei richtiger Handhabung) alles absolut gefahrlos ... aber man sollte halbwegs sattelfest auf der Kommandozeile sein und sich auch mal "etwas trauen". Das heißt beileibe nicht "unüberlegt und vorschnell handeln" ... aber wenn man weiß, was man da tut, geht das Risiko gegen Null, weil zu keinem Zeitpunkt ein Zustand der Box erreicht werden dürfte, wo nicht ein einfacher Restart wieder zu einem betriebsfähigen Router führt (erst recht dann, wenn man Skripte auf einem USB-Stick ablegt, den man einfach abziehen (lassen) kann). Daß man dabei dann einen unabhängigen Kommunikationskanal zum Aufstellort des Gerätes braucht (z.B. eine Mobilfunk-Verbindung zu einer Person vor Ort), versteht sich aber von selbst - auch eine fernsteuerbare Steckdose für die Stromversorgung der Box kann keine Kabel oder USB-Geräte umstecken.
 
Vielen Dank für die Antwort!

In der Tat, wüsste man alles vorab, wär es auch kein Problem, das vorab zu lösen... Wollte man sich auf alles 100%ig vorbereiten, wären die Tage und das Leben aber eindeutig zu kurz. In meiner Erinnerung hatten gebrandete Fritzboxen noch eine andere Farbe, Providerversionen gab es nicht und verschiedene Hardwareversionen waren leichter zu unterscheiden. Der Vorgänger der 7360 war aber auch eine 7170, also schon was her.

Die angesprochene Methode mit Skript- Datei im NAS konnte ich nur in Versionen finden, die ab Fw. 6.81 nicht mehr funktionieren sollen? (Die aktuelle Firmware- Version der Box ist 6.83)
 
Ja, bei der 06.83 (stand halt nicht da, zumindest bisher nicht) sind dann alle derzeit "veröffentlichten" Lücken geschlossen (zumindest die, die ich meinerseits kenne und gemeldet habe - sogar das "DoManualUpdate" bzw. TR-069 wäre bei der 06.83 dann dicht) - das war ja auch das erklärte Ziel. Damit ist das dann aber auch eine sichere Firmware ... man kann eben nicht alles haben. Da bräuchte es dann tatsächlich Unterstützung vor Ort, die zumindest in der Lage ist, über den Bootloader eine andere Firmware zu installieren.

Wobei ich noch nicht so richtig verstanden habe, wieso man das Vorhandensein einer "provideradditive.tar" vorher nicht feststellen konnte und damit vorab auch nichts machen konnte ... außer die Aussage war eigentlich: "Ich kannte das nicht und habe das vorher auch nicht erkundet, daher einfach so gemacht, wie es früher mal ging." - dagegen kann man dann (als Außenstehender) tatsächlich nichts machen und ich will es dann (nicht als Vorbild, sondern als abschreckendes Beispiel, wobei das nicht persönlich gemeint ist) noch einmal deutlich hervorheben, daß bei neueren FRITZ!Boxen so manches "alte Rezept" nicht mehr funktioniert - die einen sagen dann "leider" und die anderen "glücklicherweise".

Ansonsten ist ja der Eintrag für den inexio-ACS sicherlich auch schon direkt nach der Wiederherstellung der Konfiguration verwendet worden (beim Start wird die Datei entpackt und angewendet, wenn vorhandene Einträge nicht passen - so jedenfalls nach meinen Tests) - das sollte also schon da in den Support-Daten sichtbar gewesen sein.
 
Die neue 7360 funktioniert einwandfrei, hat aber regelmässig den Eintrag:
"Automatische Einrichtung und Updates für dieses Gerät durch den Dienstanbieter nicht möglich: Verbindung zum Autokonfigurationsserver fehlgeschlagen. [12 Meldungen seit .....] "
Andererseits ist das ja auch nicht so schlimm. Dann kommt eben diese Meldung alle 12 Stunden einmal. Vielleicht sind ja auch die Anbieter-Dienste in der Benutzeroberfläche sichtbar. Dann kann man sie da einfach ausschalten.
 
Danke für die Antworten!

Ja, bei der 06.83 (stand halt nicht da, zumindest bisher nicht) sind dann alle derzeit "veröffentlichten" Lücken geschlossen.....
Sorry, die zweite Ergänzung zum Eröffnungsbeitrag habe ich zeitgleich mit Deiner Antwort geschrieben.

Wobei ich noch nicht so richtig verstanden habe, wieso man das Vorhandensein einer "provideradditive.tar" vorher nicht feststellen konnte und damit vorab auch nichts machen konnte ... außer die Aussage war eigentlich: "Ich kannte das nicht und habe das vorher auch nicht erkundet, daher einfach so gemacht, wie es früher mal ging." ......
Die triviale Antwort hier ist: Es ist sehr leicht zu suchen, wenn man weiss, was man sucht, immer noch leicht, wenn man weiss, dass es was zu suchen/finden gibt und nicht mehr ganz so einfach, wenn man eben nicht weiss, ob es was zu suchen gibt/ ob man überhaupt was finden kann.

Ohne die ganze Fritzbox verstanden und durchsucht zu haben, hätte ich vielleicht noch die 'provideradditive.tar' finden können, aber wer hätte mir gesagt, dass das die einzige versteckte Option ist, irgendwelche Daten nachträglich in die Konfiguration zu laden? Vielleicht hat AVM schon 3 weitere Wege vorbereitet? Die relativ sorgfältige Suche nach allen Versionen (Produktnummern) der FB 7360 hat jedenfalls nicht zum Verdacht geführt, dass es noch so etwas wie Providerversionen gibt.

Andersherum gesehen- mehr aus der Sicht des 'einfachen Endverbrauchers':
Ich habe eine FB 7360 mit einer Editions FW, die sich in Produktnummer, Hardware und Software sichtbar unterscheidet, aber ohne weitere Probleme ausserhalb des Netzes ihres ursprünglichen Providers funktioniert.

Ich habe eine FB 7360 V2,
- die sich durch keinerlei sichtbare Details (Produktnummer, Software, Hardware) von der "reinen" AVM- Version unterscheidet,
- die offizielle AVM Firmware klaglos akzeptiert,
- eine breite Auswahl von Providern in den ZUgangsdaten zulässt
- die Konfigurationsdaten der ersten FB 7360 komplett einliest und
- dabei keine Fehlermeldung ausgibt, dass sie Daten verändert oder nicht übernommen hat (tr069.cfg)

Warum sollte ich vermuten, dass diese Box also mehr Zicken machen wird als die 7360 V1 mit gebrandeter Firmware?

Ansonsten ist ja der Eintrag für den inexio-ACS sicherlich auch schon direkt nach der Wiederherstellung der Konfiguration verwendet worden (beim Start wird die Datei entpackt und angewendet, wenn vorhandene Einträge nicht passen - so jedenfalls nach meinen Tests) - das sollte also schon da in den Support-Daten sichtbar gewesen sein.
Da ist er mit hoher Sicherheit! Aber- wie der Name schon sagt- die Support Daten schau ich mir als jemand, der nicht freiwillig täglich bis zum Ellenbogen im Getriebe einer Fritzbox steckt, erst an, wenn ich 'support' brauche, also ein Problem habe.

Andererseits ist das ja auch nicht so schlimm. Dann kommt eben diese Meldung alle 12 Stunden einmal. Vielleicht sind ja auch die Anbieter-Dienste in der Benutzeroberfläche sichtbar. Dann kann man sie da einfach ausschalten.
Danke auch hier! Und ja, das ist auch meine Einstellung. Die einzige Gefahr dabei ist wohl, dass plötzlich doch ein Server gefunden wird, der irgendetwas Merkwürdiges konfiguriert....

In der GUI ist nichts zu sehen, wenn man den Anbieter von t-online zu inexio wechselt, bekommen man (voreingestellte) Nutzername und Passwort gezeigt. Man könnte mal versuchen, diese Einträge zu löschen, dazu müsste man aber den falschen Provider 'übernehmen' aber da ich wie gesagt die Box via VPN bediene, wär das vermutlich relativ ungünstig. Wenn ich "guimode = guimode_hidden" in der tr069.cfg richtig deute, soll da auch nichts viel mehr tr069 betreffend zu sehen sein.

Ich werde jetzt schlicht die eine Box laufen lassen, eine zweite 7360 V2 besorgen und diese dann (an den Ethernet Anschluss des Notebook gekoppelt) erforschen. Ich hoffe mal, dass diese Anleitung auch mit Fw. 6.83 noch funktioniert!
Netzstecker ziehen bekäme meine Mutter auch mit 81 noch hin, dann wäre das sogar aus der Ferne machbar.
 
Zuletzt bearbeitet:
Ob die Anleitung noch 1:1 stimmt (ist halt auch > 1 Jahr alt und die Erkenntnisse werden erst besser und dann wieder ganz schnell falsch, wenn AVM weitere Änderungen vornimmt), weiß ich nicht ... kommt sicherlich auch darauf an, was man nun konkret machen will und um welche Firmware-Version und welches FRITZ!Box-Modell mit welchen "Geburtsdaten" es sich am Ende handelt.

Wenn ich das richtig überflogen habe, geht es im verlinkten Beitrag aber gar nicht um irgendwelche FRITZ!OS-Versionen, sondern um den Bootloader und das Entfernen von Node 29 (provideradditive.tar) - da sollte sich nichts geändert haben; nur der Shell-Zugang ist halt noch "schwerer" zu erreichen.
 
Ja, Hauptziel ist nur, eine "unverbastelte" FB zu bekommen. Da der bootloader recht alt ist, beim normalen Firmware- update eher nicht angefasst wird (recovery soll ja nach missglücktem Update- Versuch möglich bleiben) und dafür wohl auch das Auslesen und das Setzen der Variablen möglich sein sollte, rechne ich mal optimistisch damit, dass das noch geht.

Gerne hätte ich noch die provideradditive.tar gesichert und angeschaut, was inexio eigentlich so geändert hat. Da aber das eigentliche System nicht gebootet ist und damit auch keine Filesysteme gemountet sind, wird die Datei wohl nicht direkt zugänglich sein. Da muss der Check der Urlader/ bootloader Variablen reichen, nach Zurücksetzen der provider- Variable sollte das recovery mit einer original AVM Datei ja alle provider/ inexio- Spuren löschen, wenn ich das richtig verstanden habe.

(Wobei mich erstaunt, dass sich die recovery Dateien als zip- Archiv öffnen lassen und nicht irgendwelche images enthalten sondern das Dateisystem ausgebreitet vor einem liegt? Dann muesste das ja auch via tinyftp/ urlader- Umgebung zugänglich sein? Wäre spannend, die alte Firmware runterzuziehen- ist aber halt auch eine Frage von Aufwand und Zeit, sich einzulesen.)

Herzlichen Dank soweit! Werde berichten, wie es ging- das dauert aber ein bischen!
 
In Firmware >= 06.50 kann man (m.W. in allen Versionen) über die "erweiterten Support-Daten" auch ein Image der Flash-Partitionen mit den Einstellungen in die Support-Daten einbeziehen lassen. Das kann man dann wieder extrahieren und auseinandernehmen (dafür gibt es fertige Skript-Dateien) und damit hat man dann auch den Inhalt so einer "provideradditive.tar" zur Ansicht.

Das Auslesen der Firmware aus den Flash-Partitionen ist hingegen (regulär) nicht möglich ... aber da ist auch nichts wirklich Spannendes dabei, denn die kriegt man auch auf anderen Wegen - außer bei den Provider-Versionen für die DOCSIS-Modelle.
 
Ja, die erweiterten Support- Daten habe ich ausgelesen, da ist auch ein codierter Block dabei, ca.30 kB gross.

Die beiden Skripte müssten "tffs_from_supportdata" und "dissect_tffs_dump" sein, wenn ich das richtig sehe.

Allerdings läuft bereits "tffs_from_supportdata" nicht durch:
tar: Unexpected EOF in archive
tar: Error is not recoverable: exiting now
./tffs: 21: [: var/tmp/tffs-dump/: unexpected operator
./tffs: 24: ./tffs: Bad substitution

Ich habe es auf einem Linux Mint Cinnamon versucht, "tmp=$(mktemp)" gibt hier /tmp/tmp.J7WE6mE7DJ/ so dass auch $tarfile "/tmp/tmp.J7WE6mE7DJ/tffs-dump.tar" wird- wenn ich das richtig sehe, sucht das Skript nicht direkt in diesem Verzeichnis. Aber da ich mit die Zeile 13 ("[ $?-ne 0 ] && tmp=/var/tmp/tmp.$(date +%s).$$") nun so gar nichts anfangen kann und die auch wenig griffig zum Suchen ist, komme ich schon da nicht weiter. Reguläre Ausdrücke waren aber auch noch nie so richtig meine Freunde :-(

Ich glaube, das muss erstmal warten...

Besten Dank für die Hilfe!
 
Wie sieht es mit Requirement BASH vs. DASH aus ? sind diese OK ? Prüfbefehl "ls -la /bin/sh", hier sollte /bin/bash angezeigt werden.
 
Aufruf als: tffs_from_supportdata <support_datei> <ausgabe_ort> <1 | 2>

Der Dump enthält zwei Partitionen (das TFFS ja auch) und der dritte Parameter gibt an, welche der beiden Dateien man gerne hätte. Der Name der Ausgabedatei am angegebenen Ort ist der - etwas aufbereitete - Name aus dem TAR-Archiv in den Support-Daten.

Die Support-Datei wird von der angegebenen Stelle (1. Parameter) gelesen und nur der Teil zwischen den Begrenzern extrahiert, anschließend durch "base64" für die Decodierung gejagt. Erst das Ergebnis dessen landen dann als "tffs-dump.tar" in dem angelegten temporären Verzeichnis, damit das "tar"-Kommando dort das Verzeichnis (des Archivs) dann auslesen kann. Das Skript schreibt also selbst diese Datei und sucht sie nicht irgendwo ... daher vermute ich einfach mal, daß der Aufruf nicht stimmte (das ist auch nur die "Prinzipskizze" und kein umfassendes Skript, denn es testet nicht einmal richtig, ob alle Parameter beim Aufruf angegeben wurden).
 
Wie sieht es mit Requirement BASH vs. DASH aus ? sind diese OK ? Prüfbefehl "ls -la /bin/sh", hier sollte /bin/bash angezeigt werden.
Danke! /bin/sh geht auf /bin/dash, ich habe die erste Zeile im script auf #! /bin/bash geändert, das macht aber keinen Unterschied.

Aufruf als: tffs_from_supportdata <support_datei> <ausgabe_ort> <1 | 2>

Der Dump enthält zwei Partitionen (das TFFS ja auch) und der dritte Parameter gibt an, welche der beiden Dateien man gerne hätte. Der Name der Ausgabedatei am angegebenen Ort ist der - etwas aufbereitete - Name aus dem TAR-Archiv in den Support-Daten.

Die Support-Datei wird von der angegebenen Stelle (1. Parameter) gelesen und nur der Teil zwischen den Begrenzern extrahiert, anschließend durch "base64" für die Decodierung gejagt. Erst das Ergebnis dessen landen dann als "tffs-dump.tar" in dem angelegten temporären Verzeichnis, damit das "tar"-Kommando dort das Verzeichnis (des Archivs) dann auslesen kann. Das Skript schreibt also selbst diese Datei und sucht sie nicht irgendwo ... daher vermute ich einfach mal, daß der Aufruf nicht stimmte (das ist auch nur die "Prinzipskizze" und kein umfassendes Skript, denn es testet nicht einmal richtig, ob alle Parameter beim Aufruf angegeben wurden).

Danke für die Erklärung! Manchmal hilft es ja wirklich die Syntax zu kennen. Irgendwie läuft es aber immer noch nicht. Meine Debugging- Fähigkeiten sind begrenzt, aber ich habe trotzdem etwas rumprobiert:

| base64 -d aus Zeile 7 weg, Zeile 14 (trap...) auskommentiert und alles ab Zeile 19 gestrichen liefert die SECTION TFFS_DUMP aus der Support Datei als tarfile- OK. Kommentiere ich die "trap"- Zeile nicht aus, ist das temporäre Verzeichnis schon wieder gelöscht, selbst wenn ich das script nach Erstellen des tarfile abbreche.

#! /bin/bash
FIRST_LINE="##### BEGIN SECTION TFFS_DUMP TFFS Dump"
LAST_LINE="##### END SECTION TFFS_DUMP"
decode_to_tar()
{
local input="$1"
sed -e "1,/^$FIRST_LINE/d" "$input" | sed -e "/^$LAST_LINE/,\$d"
#| base64 -d
}
INPUT="$1"
OUTPUT="$2"
INDEX=$3
tmp=$(mktemp)
[ $? -ne 0 ] && tmp=/var/tmp/tmp.$(date +%s).$$
# trap "rm -r $tmp" EXIT HUP
rm $tmp
mkdir -p $tmp
tarfile=$tmp/tffs-dump.tar
decode_to_tar "$INPUT" >$tarfile

Mit "| base 64 -d" wieder dazugenommen wird die Datei etwas grösser und "wirkt" binär. Allerdings gibt

tar -t -f /tmp/tmp.tUYNvVH0KI/tffs-dump.tar

var/tmp/tffs-dump/
var/tmp/tffs-dump/tffs_(2).dump.gz
tar: Unexpected EOF in archive
tar: Error is not recoverable: exiting now

Ich habe 2 Support- Dateien, die TFFS- Dump- Blöcke sind leicht unterschiedlich, bei beiden ist das Ergebnis des scriptes gleich.

Lasse ich das bis auf die auskommentierte Zeile 14 unveränderte Script laufen, ist die Ausgabe:
tar: Unexpected EOF in archive
tar: Error is not recoverable: exiting now
./extract: 21: [: var/tmp/tffs-dump/: unexpected operator
./extract: 24: ./extract: Bad substitution
 
Zuletzt bearbeitet:
Warum da bei der 7360 zweimal derselbe Fehler in so einem TFFS-Dump auftreten soll, verstehe ich nicht wirklich ... aber mit dem Rest des Skriptes kenne ich mich halbwegs aus.

Die "trap"-Zeile dient ja nun genau zu dem, was sie bei Dir offenbar macht ... auch beim Abbruch oder bei Fehlern sollen temporäre Dateien entsorgt werden; das gehört nun mal zum "guten Ton", wenn man etwas macht, bei dem man temporäre Dateien erzeugt.

Das Dekodieren aus Base64 muß schon noch in jedem Falle sein und anstatt da bei Tests irgendwie an Zeile 14 "zu schrauben", würde ich eher zusätzliche Kommandos empfehlen, welche die temporäre Datei unter einem definierten Namen noch einmal zusätzlich speichern - die kann man dann hinterher einfach wieder löschen (sowohl die Dateien als auch die zusätzlichen Kommandos) und vor allem kann man dann diese "Zwischenergebnisse" untersuchen.

Hier wäre es z.B. hilfreich, für so ein erzeugtes TAR-File (nach dem Dekodieren) mal dessen gesamte Größe zu kennen und die (anzunehmende) Größe der dort enthaltenen Dateien (dafür braucht es noch die "-v"-Option beim "tar -t"-Aufruf). Wenn da auf einmal mitten im TAR-File ein EOF auftritt, dann heißt das in diesem Falle eindeutig, daß das TAR-File zu kurz ist.

Das kann es aber auch wieder nur sein, wenn beim Einpacken oder beim "Extrahieren" aus den Support-Daten etwas schiefgeht ... mir fehlt vollkommen die Phantasie, was das sein sollte, wenn die Support-Datei tatsächlich (unverändert) gespeichert wurde.

Auf jeden Fall hat so ein Archiv dann schon mal eine Dateigröße, die ein Vielfaches von 512 ist - stimmt schon diese Größe (nach der Base64-Dekodierung) nicht, ist da etwas faul mit dem TAR-File - dann muß man vielleicht mal in die Firmware der 7360 schauen, wie dort die Datei "/bin/supportdata.tffs" aussieht - wobei für mich jede Abweichung von anderen Modellen sehr überraschend käme.

Bliebe also noch ein Problem beim Auslesen der Daten aus dem TFFS ... dann sollten die eingepackten Dateien aber eine Länge von 0 (ggf. etwas größer, weil da noch ein "gzip" drübergejagt wird) haben. Ist es das nicht, kann fast nur noch das "gzip" schiefgehen ... aber auch das erfolgt ja nicht für das TAR-File an sich, sondern für jede TFFS-Partition einzeln. Egal wie das "gzip" dann ausgehen mag, sollte trotzdem das Ergebnis im TAR-File lesbar sein ... es gibt einfach (fast) keine plausible Erklärung.

Aber man kann ja auch das Support-File nehmen (natürlich eine Kopie, aber das versteht sich leider nicht bei jedem von selbst) und dort die Zeilen vor dem Base64-Text und danach löschen und diese Datei dann manuell mit "base64 -d" dekodieren lassen.

Ergibt das auch kein gültiges TAR-Archiv, dann stimmen eben die Daten in der Support-Datei nicht und es liegt nicht am (automatischen) Extrahieren, wobei mir da eben auch die Phantasie fehlt, was da schiefgehen sollte, denn es wird ja wohl kaum eine Zeile wie die $LAST_LINE irgendwo mitten im base64-kodierten Inhalt auftauchen (können).

Zumindest der Anfang (die ersten 2 512-Byte-Blöcke) muß ja stimmen, denn im ersten steht das Verzeichnis "var/tmp/tffs-dump" und im zweiten der (vom "tar" ja angezeigte) Header für "var/tmp/tffs-dump/tffs_(2).dump.gz" - wie es danach aussehen mag, kann man nur raten.

Auf alle Fälle sind die runden Klammern in dem Dateinamen für den Partition-Dump auch der Grund, warum da ein paar mehr Zeilen für das Bilden des Namens der Ausgabedatei vorhanden sind, weil die Klammern unter einer "richtigen" Shell nerven bei der Handhabung auf der Kommandozeile. Nur sollte eben nach der Zeile mit "tffs_(2).dump.gz" auch noch eine Zeile mit "tffs_(1).dump.gz" kommen, wenn das Archiv vollständig ist ... wer weiß, wo die hier geblieben sind.
 
Vorschlag: die Skriptbefehle einzeln abzuarbeiten und Zwischenergebnisse zu verifizieren.

Code:
freetz@Pi:~$ cat erweiterte_supportdata.txt |\
  sed -e "1,/^##### BEGIN SECTION TFFS_DUMP TFFS Dump/d"  |\
  sed -e "/^##### END SECTION TFFS_DUMP/,\$d" > tffs-dump.tar.b64

freetz@Pi:~$ file tffs-dump.tar.b64

freetz@Pi:~$ ls -la tffs-dump.tar.b64

freetz@Pi:~$ cat tffs-dump.tar.b64 | base64 -d > tffs-dump.tar

freetz@Pi:~$ file tffs-dump.tar

freetz@Pi:~$ ls -la tffs-dump.tar

freetz@Pi:~$ tar tvpf tffs-dump.tar
 
Guten Morgen und vielen herzlichen Dank für die Antworten. Sorry, für meine Unwissenheit betreffend Skriptprogrammierung, das brauche ich im Werktag einfach zu selten.

@PeterPawn: Vielen Dank für die ausführliche Antwort- ich bekomme da schon ein wenig ein schlechtes Gewissen. Die meisten Sachen findet man ja mit etwas Suchen doch raus, selbst Zeile 13 meine ich so langsam zu "verstehen" (fragt das Ergebnis von mktemp ab und setzt ein anlternatives temp, wenn das nicht geklappt hat).

Der Fehler dürfte aber in den Support Dateien liegen. Ich habe gestern noch ein paar erstellt und sie unterscheiden sich in der Länge und ab und zu ist der Schluss nicht "sauber":

Der Anfang ist immer gleich:
##### BEGIN SECTION TFFS TFFS
TFFS
----
##### BEGIN SECTION TFFS_DUMP TFFS Dump
dmFyL3RtcC90ZmZzLWR1bXAvAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

aber gelegentlich sieht das Ende auch mal so aus:
v3rtGWaQDaUov9sq2Mx9c7SsjGlBAnH7uYqq5zhroRPLqBeyA+Ck+6H8if28QcfcUMfCZzd5nUHx
7WaxbZtEX3ijzzGBQ7WHea24cb6MXmV912457Og8isoQUYC4mXzP0KEbx25OTeNulc1oLPMY2aEa[31455.150000][0][TFFS] writing cleanup buffer to mtd "tffs (2)"
[173030.070000][0][TFFS] writing cleanup buffer to mtd "tffs (1)"
[398635.440000][0][TFFS] writing cleanup buffer to mtd "tffs (2)"
[631819.070000][0][TFFS] writing cleanup buffer to mtd "tffs (1)"
[737035.460000][1][TFFS] writing cleanup buffer to mtd "tffs (2)"
[908946.070000][0][TFFS] writing cleanup buffer to mtd "tffs (1)"
[1132966.130000][0][TFFS] writing cleanup buffer to mtd "tffs (2)"
[1314696.360000][0][TFFS] writing cleanup buffer to mtd "tffs (1)"
##### END SECTION TFFS

ähnlich:
x+7xyhG6aF3F37vdvYdAify/F1vG+5tb0xj4x1fvgZ38O6+h/E8T0N2jXXm4F3wzWffhqSSb8yd4[31455.150000][0][TFFS] writing cleanup buffer to mtd "tffs (2)"
[173030.070000][0][TFFS] writing cleanup buffer to mtd "tffs (1)"
[398635.440000][0][TFFS] writing cleanup buffer to mtd "tffs (2)"
[631819.070000][0][TFFS] writing cleanup buffer to mtd "tffs (1)"
[737035.460000][1][TFFS] writing cleanup buffer to mtd "tffs (2)"
[908946.070000][0][TFFS] writing cleanup buffer to mtd "tffs (1)"
[1132966.130000][0][TFFS] writing cleanup buffer to mtd "tffs (2)"
[1314696.360000][0][TFFS] writing cleanup buffer to mtd "tffs (1)"
##### END SECTION TFFS



Die meisten sind so:
Dy93c681Hgy3tunc9h3OQLDlcNg3eTyo8m7dWyo1d4xgUH4hS02tJ60vKEvb8Y2BD2GToMNBad0k
##### END SECTION TFFS_DUMP
[31455.150000][0][TFFS] writing cleanup buffer to mtd "tffs (2)"
[173030.070000][0][TFFS] writing cleanup buffer to mtd "tffs (1)"
[398635.440000][0][TFFS] writing cleanup buffer to mtd "tffs (2)"
[631819.070000][0][TFFS] writing cleanup buffer to mtd "tffs (1)"
[737035.460000][1][TFFS] writing cleanup buffer to mtd "tffs (2)"
[908946.070000][0][TFFS] writing cleanup buffer to mtd "tffs (1)"
[1132966.130000][0][TFFS] writing cleanup buffer to mtd "tffs (2)"
[1314696.360000][0][TFFS] writing cleanup buffer to mtd "tffs (1)"
##### END SECTION TFFS

Aber auch da sind dann die Dumps unterschiedlich lang 30 - 100 kB (!).

Die support Seite der FB habe ich meist mit VPN aufgerufen und dir Datei direkt auf meinen Rechner übertragen, das sollte ja eigentlich nicht das Problem sein bei der Dateigrösse und Geschwindigkeit. Ich werde es aber nochmal von einem Rechner im lokalen Netz probieren, vielleicht macht das einen Unterschied.


@Pokemon20021: Ja, das hätte ich auch gerne gemacht, das Problem mit den shell Befehlen ist nur, dass da die Syntax immer ganz genau stimmen muss und selbige muss ich immer erst nachschlagen. Die ersten 3 Zeilen auf der Kommandozeile zu schreiben hätte mich vermutlich Stunden gekostet und wenn es nicht funktioniert, ist die Hauptursache immer noch ein Fehler von mir beim Umschreiben des Befehls. Aber vielen Dank für die Beispiele, ich werde sie nacharbeiten :)
 
Die meisten sind so:
Code:
[COLOR=#0000ff]Dy93c681Hgy3tunc9h3OQLDlcNg3eTyo8m7dWyo1d4xgUH4hS02tJ60vKEvb8Y2BD2GToMNBad0k[/COLOR]
##### END SECTION TFFS_DUMP
[COLOR=#ff0000][31455.150000][0][TFFS] writing cleanup buffer to mtd "tffs (2)"
[173030.070000][0][TFFS] writing cleanup buffer to mtd "tffs (1)"
[398635.440000][0][TFFS] writing cleanup buffer to mtd "tffs (2)"
[631819.070000][0][TFFS] writing cleanup buffer to mtd "tffs (1)"
[737035.460000][1][TFFS] writing cleanup buffer to mtd "tffs (2)"
[908946.070000][0][TFFS] writing cleanup buffer to mtd "tffs (1)"
[1132966.130000][0][TFFS] writing cleanup buffer to mtd "tffs (2)"
[1314696.360000][0][TFFS] writing cleanup buffer to mtd "tffs (1)"
[/COLOR]##### END SECTION TFFS

die "rot markierten Zeilen" sind nicht eigentlich mehr Bestandteil des TFFS_DUMPs uns sollten somit nicht in tffs-dump.tar.b64 enthalten sein.
Das Ende einer B64-Datei ist bei mir
"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=="
d.h. da liegt zumindest bei einer Partition m.W. ein Problem beim Lesen vor.

Frage: Was kommt denn bei den Befehlen in #15 heraus ?
Hinweis: der Befehl "tar tvpf tffs-dump.tar" sollte eine konsistente Datei ${mtd_name}.dump.gz liefern.

Code:
freetz@Pi:/tmp$ tar tvpf tffs-dump.tar
drwxr-xr-x root/root         0 2017-03-13 21:03 var/tmp/tffs-dump/
-rw-r--r-- root/root    228563 2017-03-13 21:03 var/tmp/tffs-dump/tffs_(2).dump.gz
-rw-r--r-- root/root    275985 2017-03-13 21:03 var/tmp/tffs-dump/tffs_(1).dump.gz
freetz@Pi:/tmp$

Wenn hier eine Dump-Datei konsistent ist, dann sollte selektives Extrahieren möglich sein.
 
Zuletzt bearbeitet:
Es gibt tatsächlich eine alternative "Darstellung" so eines Dumps in einer Support-Datei, wenn man in die AVM-Skripte schaut. Sofern es eine Datei "/bin/openssl_smime" und eine Datei "/var/flash/test.cert" gibt, wird anstelle der Base64-Kodierung eine asymmetrische Verschlüsselung (das ist nicht ganz exakt, weil die eigentliche Verschlüsselung des Textes wieder symmetrisch ist und nur der dafür verwendete (zufällige) Schlüssel dann asymmetrisch verschlüsselt wird) verwendet, wo man dann den privaten Schlüssel zum verwendeten Zertifikat braucht, um das entschlüsseln zu können.

Das ist hier aber eher nicht das Problem ... nur als "Randbemerkung", daß das nicht zwangsläufig direkt base64-kodiert sein muß - allerdings sollte man es am Beginn bereits erkennen können, da die SMIME-Version einen passenden Header hat. Aber aus dem Ende kann man es nicht zwangsläufig erkennen, denn auch der SMIME-kodierte binäre Inhalt ist natürlich mit Base64 kodiert für den Transport über 7-Bit-Verbindungen.

Da hier aber die Base64-Dekodierung ja zumindest teilweise funktioniert und dabei auch noch sinnvolle Namen erscheinen, ist Verschlüsselung nicht das Problem.

Die zusätzlichen Nachrichten nach dem TFFS-Dump sind vollkommen normal (die werden aus anderen Protokollen "zusammengesucht") ... was da nicht fehlen darf, ist die Ende-Zeile "##### END SECTION TFFS_DUMP", da ansonsten das "sed"-Kommando nicht richtig funktioniert und ich weiß nicht genau, was das "base64"-Kommando macht, wenn es auf Zeichen außerhalb des Vorrats trifft (und ob das jede Implementierung einheitlich handhabt).

Was aber gar nicht erst auftreten dürfte, ist eine Datei, in der zwar diese "Ende-Markierung" für den Dump fehlt, aber gleichzeitig noch die Nachrichten aus der Debug-Ausgabe enthalten sind. Wenn das Skript irgendwo in dem IF-Zweig mit dem Erzeugen des Base64-Textes "sterben" sollte, dann müßte das eigentlich das komplette Skript betreffen (also "/bin/supportdata.tffs") und dann ist die Fortsetzung innerhalb dieses Skriptes mit der Ausgabe der Debug-Nachrichten vollkommen unerklärlich. Ein Fehler, der nur zum "Verlassen" des gerade aktuellen IF-Zweiges führt (Traps sind da auch nicht zu sehen), der ist dann schon reichlich mysteriös - das sieht eher nach einem Problem bei der Datenübertragung zum Browser aus (auf den ersten Blick jedenfalls) oder nach einer der (unerklärlicherweise) immer noch beliebten "Security-Suites", die vielleicht beim Parsen der Textdatei durcheinanderkommt und das nicht 1:1 wieder ausgibt als "sauberen Text", wenn ihr (mehr oder weniger zufällig) etwas an dem Base64-Text nicht passen sollte.
 
......
Das Ende einer B64-Datei ist bei mir
"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=="
d.h. da liegt zumindest bei einer Partition m.W. ein Problem beim Lesen vor.
Danke, dieses Wissen fehlt mir, dann hätte ich gesehen, dass die Datei bei allen (!) früheren Support- Dateien unvollständig ist.

Code:
freetz@Pi:/tmp$ tar tvpf tffs-dump.tar
drwxr-xr-x root/root         0 2017-03-13 21:03 var/tmp/tffs-dump/
-rw-r--r-- root/root    228563 2017-03-13 21:03 var/tmp/tffs-dump/tffs_(2).dump.gz
-rw-r--r-- root/root    275985 2017-03-13 21:03 var/tmp/tffs-dump/tffs_(1).dump.gz
freetz@Pi:/tmp$
.....
Danke :) Jetzt weiss ich wenigstens, was der Inhalt sein sollte!


.........
Die zusätzlichen Nachrichten nach dem TFFS-Dump sind vollkommen normal (die werden aus anderen Protokollen "zusammengesucht") ... was da nicht fehlen darf, ist die Ende-Zeile "##### END SECTION TFFS_DUMP", da ansonsten das "sed"-Kommando nicht richtig funktioniert und ich weiß nicht genau, was das "base64"-Kommando macht, wenn es auf Zeichen außerhalb des Vorrats trifft (und ob das jede Implementierung einheitlich handhabt).
Das war mir schon klar, leider kam die erste Datei mit fehlendem "##### END SECTION TFFS_DUMP" erst nach einem Haufen Versuche... Wie der Block rausgeschnitten wurde, hatte ich ja kontrolliert- und da waren Anfang und Ende mit der Support- Datei identisch (vor dem Decodieren).

Was aber gar nicht erst auftreten dürfte, ist eine Datei, in der zwar diese "Ende-Markierung" für den Dump fehlt, aber gleichzeitig noch die Nachrichten aus der Debug-Ausgabe enthalten sind. Wenn das Skript irgendwo in dem IF-Zweig mit dem Erzeugen des Base64-Textes "sterben" sollte, dann müßte das eigentlich das komplette Skript betreffen (also "/bin/supportdata.tffs") und dann ist die Fortsetzung innerhalb dieses Skriptes mit der Ausgabe der Debug-Nachrichten vollkommen unerklärlich. Ein Fehler, der nur zum "Verlassen" des gerade aktuellen IF-Zweiges führt (Traps sind da auch nicht zu sehen), der ist dann schon reichlich mysteriös - das sieht eher nach einem Problem bei der Datenübertragung zum Browser aus (auf den ersten Blick jedenfalls) oder nach einer der (unerklärlicherweise) immer noch beliebten "Security-Suites", die vielleicht beim Parsen der Textdatei durcheinanderkommt und das nicht 1:1 wieder ausgibt als "sauberen Text", wenn ihr (mehr oder weniger zufällig) etwas an dem Base64-Text nicht passen sollte.
In der Tat, völlig richtig, und eine von einem Rechner im lokalen Netz gezogene Kopie ist fast 50% länger und das script funktioniert wie es soll! Ich bedauere sehr, dass ich das nicht eher versucht habe, aber die Dateien wirkten von Anfang bis Ende eigentlich sauber aufgebaut- bis auf das Ende der B64 Datei- das hätte ich merken können, so ich es denn gewusst hätte!

Ich habe nur eine 'alte' Datei mit der vollständigen verglichen und abgesehen davon, dass der Dump sehr viel kürzer ist, fehlen z.B. die Blöcke "Wan Routing Table:" und "IFX PPA HW Sessions:" Die restlichen Unterschied sind für mich schwerer einzuordnen.

Gestern Abend habe ich noch mit verschiedenen Browsern via VPN Zugang zur FB probiert (Firefox, Opera, Chrome und sogar IE)- keine Unterschiede. Zählt Eset Nod32 Antivirus als "Security Suite"? In den logs ist jedenfalls nichts zu sehen und eingentlich ist das Programm eher zu gesprächig.

(@Shirocco88: bash oder dash macht tatsächlich einen Unterschied aber erst bei den Ausdrücken in den Zeilen 21 bis 26)

Nochmals herzlichen Dank und Sorry, dass ich nicht eher drauf gekommen bin, dass die Dateien verstümmelt sein könnten :-(
 
Zählt Eset Nod32 Antivirus als "Security Suite"? In den logs ist jedenfalls nichts zu sehen und eingentlich ist das Programm eher zu gesprächig.
Kommt ganz drauf an, wo sich das inzwischen (meine letzten Versuche damit stammen aus der Zeit vor 2010) überall einklinkt.

Da das ja "nur" ein Download einer Textdatei für den Browser ist, sollte der eigentlich komplett ignoriert werden ... andererseits sind eben auch JS-Dateien, die ein Browser von irgendwoher nachlädt, am Ende nichts anderes als Textdateien. Wenn da NOD32 dann an das "Interpretieren" so einer Datei gehen sollte (im Zuge einer Heuristik, die auch ohne Signaturen eine Erkennung versucht), dann ist so ein Base64-Abschnitt schnell als solcher identifiziert und weil auch einige Malware Teile ihres Codes gerne auf diesem Weg "versteckt" vor den Augen eines Virenwächters, ist auch das Dekodieren solcher Teile nicht so ganz ungewöhnlich für so eine "Security Suite", wenn sie sich denn in den Browser "einklinken" darf.

Dabei reicht es dann schon, wenn dieses Dekodieren irgendwo schiefgeht (ein "normaler" Virus würde wohl kaum die Größe so eines Base64-Textes erreichen, wie das dieser TFFS-Dump macht - da kann schon mal etwas "überlaufen") und der Virenscanner dann nicht "nebenbei" läuft, sondern als "Filter" arbeitet, die Eingabedatei "vorgesetzt" bekommt und seinerseits den "bekömmlichen Teil" ausspucken soll, der dann weiterverarbeitet wird.

Das ist aber alles reine Spekulation und nur eine Hypothese, wo so ein (ansonsten unerklärlicher) Unterschied nun herkommen mag ... eine VPN-Verbindung sollte da eigentlich nicht das Problem sein, weil alles andere "oberhalb" dieser Verbindung bei einem HTTP-Download wieder über das verwendete Transport-Protokoll TCP abgesichert wäre.

Wenn sich dieser Fehler halbwegs zuverlässig reproduzieren läßt, kann man ja mal den "rohen" Netzwerk-Verkehr auf dem PC mitschneiden und den Download der Support-Datei (Wireshark schafft es auch, diese Datei gezielt aus einem Mitschnitt zu extrahieren und der Mitschnitt erfolgt in der Regel noch vor dem Virenscanner) mit dem am Ende vom Browser gespeicherten Ergebnis vergleichen. Gerade dann, wenn das mit verschiedenen Browsern keinen Unterschied ergibt (und die aber alle auf NOD32 für den Virenscan zurückgreifen), dann sollte das Problem ja an einem Punkt auftreten, wo diese alle eine gemeinsame Komponente verwenden. Wenn tatsächlich die Datei bereits fehlerhaft von der Box über die VPN-Verbindung käme, würde mich das jedenfalls mehr verblüffen als eine Ursache auf dem "empfangenden" Rechner - aber auch das kann natürlich sein, ich halte es nur für unwahrscheinlicher, nicht für unmöglich, daß bei der Erzeugung der Datei bereits etwas schiefgeht.

Sogar der Unterschied, ob es sich nun um ein "entferntes System" oder um einen lokalen Client handelt, von dem eine solche Datei stammt, kann bei solchen Erkennungen dann einen anderen Verlauf bzw. ein anderes Ergebnis hervorrufen ... insofern spricht auch die Tatsache, daß das lokal einwandfrei klappt, noch nicht automatisch dagegen, daß da eine solche Sicherheitssoftware das Problem darstellen könnte.
 
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.