FB 7270 Probleme bei Wiederherstellen einer Sicherung / Factory Default ohne Meldung

[eva.luation]

Hi,

bin am Verzweifeln. Hatte ein Problem mit meiner DSL-Leitung und musste zu Testzwecken einige Einstellungen meiner FB ändern. Brav zuvor eine Sicherung (inkl. Passwort) gemacht, um diese danach wieder zurückzuspielen.

Dummerweise nimmt die FB ihre eigene Sicherung nicht mehr an.
Auch Sicherungen, die einige Wochen zuvor angefertigt wurden, werden nicht zurückgesichert.

Ich bekomme dabei keinerlei Fehlermeldung. In der Weboberfläche wähle ich "Wiederherstellen", gebe das Passwort ein, selektiere den Pfad zum Sicherungsfile und drücke auf "Wiederherstellen".
Die FB teilt mir mit, dass ein Reboot durchgeführt wird.

Dummerweise ist die FB danach im Factory Default. Ich kann sie per 192.168.178.1 erreichen, aber alle Einstellungen sind weg.

Wenn ich mein Sicherungsfile statt über "Wiederherstellen" über die Funktion "Import" (eigentlich ja nur für fremde Fritzboxen gedacht) importiere, funktioniert es.
Dann sind aber nur die allerwichtigsten Einstellungen zurückgespielt. All meine Einstellungen zu Kindersicherungen, Blacklists usw... bleiben verloren.

Ist ein solches Phänomen bekannt? Wie kann ich meine restlichen Sicherungen wiederherstellen oder zumindest aus dem Backup herauslesen und wieder abtippen? Ich erinnere mich bei weitem nicht mehr an alle Einstellungen, die ich in den letzten Jahren vorgenommen habe...

Was ich noch versucht habe:
- TELNET-Sitzung während der Rücksicherung aktiviert, um eine Fehlermeldung/Hinweis auf die Ursache zu erhaschen - nichts gefunden
- Tool im Netz gesucht, mit dem ich die Sicherung zerlegen kann - gefunden
-- das export-File liegt nun in seine Bestandteile zerlegt auf meiner Platte, ist aber recht kryptisch
-- eine Funktion zum "Wiederzusammensetzen" habe ich nicht gefunden
-- wie ich die einzelnen Files sinnvoll und ungefährlich wieder auf die Box bringe, weiß ich nicht
- eine neue Sicherung angefertigt und testweise wieder zurückgespielt: funktioniert
-- das export-file ist dann nur ca. 100-200kb groß, meine vorigen Sicherungen haben über 600kb
- in einem Forum den Hinweis gefunden, dass man Sicherungsdateien nicht umbenennen darf - daraufhin den Namen wiederhergestellt und diverse Schreibweisen probiert => ohne Erfolg
- explizit Factory Default ausgewählt und danach rückgesichert => kein Erfolg

Mir gehen langsam die Ideen aus...

Freue mich über jeden Tipp!

Grüße
Eva

 

[PeterPawn]

Aus dem Gedächtnis, also ohne Gewähr auf exakte Wiedergabe:

- Telnet-Session starten
- originales Exportfile unter dem Namen /var/tmp/configimport.tmp auf die Box bringen
- Testen des Import-Files mit "tr069fwupdate check_configimport [password]", wobei [password] nur dann notwendig ist, wenn die Export-Datei mit einem solchen erzeugt wurde
- ein erfolgreiches "check_configimport" sollte einen Returncode von 0 liefern, ansonsten stimmt ggf. das Kennwort nicht (einfach mal mit neu exportierten Dateien testen, ob und wie das funktioniert)
- dann kann man nur noch "tr069fwupdate configimport" aufrufen und darauf hoffen, daß da die Gültigkeitsprüfungen weniger streng ausfallen

Wenn das auch nicht von Erfolg gekrönt ist, muß man weiter tricksen und sich der Ursache des (zu vermutenden) nachträglichen Ladens der Werkseinstellungen schrittweise nähern.

Das Problem beim Import der Einstellungen sind die verschlüsselt gespeicherten Credentials (das sind die Werte mit den vier Dollarzeichen am Beginn), die kriegt man nicht ohne weiteres wieder in der richtigen Form in die Box. Andere Sachen wie KiSi und/oder Blacklists sind m.W. nicht so kodiert, so daß da eine "manuelle Übernahme" erfolgreich sein könnte.

Dazu müßte man dann aber konkret mal eine solche Datei sehen ... die binären Dateien (nennen wir mal spaßeshalber alle in hexadezimaler Darstellung exportierten Daten so) kann man ohnehin 1:1 bei einer 7270 einspielen, da sind keine verschlüsselten Daten drin. Den Rest könnte man schrittweise als Config-Diff mit allcfgconv einspielen, wenn man die Credentials löscht. Bleibt die Frage, welche Daten bei einem cfgtakeover nicht übernommen wurden - was da machbar ist, hängt aber u.a. auch von der Firmware-Version der 7270 ab und neben dieser fehlenden Angabe ist auch die Frage, über welche Hardware-Version der 7270 wir hier eigentlich reden, nicht vollkommen belanglos.

 

[eva.luation]

zuerst einmal die vergessenen Angaben zum Gerät:
Firmwareversion: 54.05.54 (Ein Firmwareupdate wollte ich vorerst nicht durchführen, um die Situation nicht weiter zu verkomplizieren)
Hardwareversion: 7270 v2

Den Importcheck habe ich wie folgt durchgeführt. Schreibe es mal ein wenig ausführlicher, vielleicht hilft es ja dem einen oder anderen...

Telefoncode #96*7* (zur Aktivierung der Telnetschnittstelle)
USB-Stick in FB
über Weboberfläche Zugriff auf USB-Stick (Heimnetz/Speicher-NAS/USB)
Upload zweier Sicherungsdateien auf den Stick (eine neu erzeugte, funktionierende Sicherung sowie die fragliche, wichtige Sicherung)

telnet 192.168.0.x
#cd /var/tmp
#cp /var/media/ftp/USB-DISK-01/FRITZ.Box\ Fon\ WLAN\ 7270\ v2\ \(UI\)\ 54.05.54_24.07.15_2039.export /var/tmp/configimport.tmp
#tr069fwupdate check_configimport ******* (* = mein Passwort)
#echo $?
0

Beide Sicherungen bestehen die Prüfung mit Fehlercode 0. Als gegencheck habe ich auch mal das Passwort weggelassen oder eine offensichtlich falsche Datei geprüft und entsprechend einen Fehlercode <>0 bekommen.

Nun habe ich den Import über TELNET gestartet:
# tr069fwupdate configimport *********
[/usr/bin/setcountry] Parameter 049
Settings for Country '049' found
changing Country '049' to Country '049'
[/usr/bin/setlanguage] Parameter de
changing Language 'de' to Language 'de'
+++ do 'clear country'... +++
+++ do 'clear language'... +++
telefon: SIGTERM received!
telefon: SIGTERM received!
killall: dect_manager: no process killed
telefon: SIGCHLD PID 4291 received!
pbd[1716]: received signal Terminated
Aug 8 10:57:32 pbd[1716]: terminating.
pbd[1720]: received signal Terminated
pbd[1721]: received signal Terminated
+++ do 'werkseinstellung'... +++
+++ do 'cleanup'... +++
+++ ...done +++
#echo $?
210

Es erfolgt kein automatischer Reboot und noch bin ich mit dem Internet über WLAN verbunden.

Die Einstellungen in der Weboberfläche zu Blacklist usw. fehlen aber - also kein Erfolg.

Jetzt der Gegencheck mit dem funktionierenden Sicherungsfile.

# cp /var/media/ftp/USB-DISK-01/FRITZ.Box\ Fon\ WLAN\ 7270\ v2\ \(UI\)\ 54.05.54_07.08.15_2314.export /var/tmp/configimport.tmp
# tr069fwupdate configimport ******
[/usr/bin/setcountry] Parameter 049
Settings for Country '049' found
changing Country '049' to Country '049'
[/usr/bin/setlanguage] Parameter de
changing Language 'de' to Language 'de'
# killall: printserv: no process killed
storage:unmounting /var/media/ftp/USB-DISK-01
rmmod: can't unload 'vfat': unknown symbol in module, or unknown parameter
rmmod: can't unload 'fat': unknown symbol in module, or unknown parameter
rmmod: can't unload 'nls_cp437': unknown symbol in module, or unknown parameter
rmmod: can't unload 'nls_iso8859_1': unknown symbol in module, or unknown parameter
rmmod: can't unload 'sd_mod': unknown symbol in module, or unknown parameter
rmmod: can't unload 'ext2': unknown symbol in module, or unknown parameter
rmmod: can't unload 'usb_storage': unknown symbol in module, or unknown parameter
rmmod: can't unload 'scsi_mod': unknown symbol in module, or unknown parameter
deactivating MUSB root hub
ls: /var/USB-proc-bus-usb-*: No such file or directory

...und es folgt ein automatischer Reboot.
Der zweite Import erfolgt noch in der gleichen Telnet-Sitzung.

Also nochmal mit frischer TELNET-Sitzung nach einem Werksreset (und mit ReturnCode):
# cd /var/tmp
# cp /var/media/ftp/USB-DISK-01/FRITZ.Box\ Fon\ WLAN\ 7270\ v2\ \(UI\)\ 54.05.54_24.07.15_2039.export /var/tmp/configimport.tmp
# tr069fwupdate check_configimport *****
# echo $?
0
# tr069fwupdate configimport *****
[/usr/bin/setcountry] Parameter 049
Settings for Country '049' found
changing Country '049' to Country '049'
[/usr/bin/setlanguage] Parameter de
changing Language 'de' to Language 'de'
+++ do 'clear country'... +++
+++ do 'clear language'... +++
telefon: SIGTERM received!
telefon: SIGTERM received!
killall: dect_manager: no process killed
telefon: SIGCHLD PID 3058 received!
pbd[1872]: received signal Terminated
pbd[1876]: received signal Terminated
pbd[1877]: received signal Terminated
Jan 1 01:05:36 pbd[1872]: terminating.
+++ do 'werkseinstellung'... +++
+++ do 'cleanup'... +++
+++ ...done +++
# echo $?
210

(ich hatte sogar einmal leicht abweichende Ausgaben - die 4 Zeilen vor dem "+++ do 'clear country'" wurden nicht ausgegeben)
Irgendwas nach der Sprache scheint ihn zu verwirren und er führt Plan B (Werkseinstellung) durch.

Jetzt habe ich wieder das funktionierende File mit den DSL-Daten eingespielt, um berichten zu können...

 

[PeterPawn]

Ok, dann eben Plan B ... die Export-Datei kannst Du z.B. mit meinem "decompose" (u.a. im verlinkten Archiv zu diesem Thread zu finden) in ihre Bestandteile zerlegen und dann auch in den hexadezimal in der Export-Datei enthaltenen Dateien nach den vermißten Einstellungen der Blacklist suchen (die hex2bin-Wandlung übernimmt ja "decompose" für Dich).

Die "nicht-Text"-Dateien enthalten m.W. keine verschlüsselten Bestandteile (mit Ausnahme der UMTS-PIN) und müßten sich 1:1 kopieren lassen, die anderen kannst Du über den Import als "diff" einspielen (einfach mal allcfgconv testen, wie das genau aussehen sollte, am besten an der usb.cfg "trainieren").

Trotzdem darfst Du natürlich nicht versäumen, die Box zwischendrin jeweils neu zu starten (allerdings besser nicht mit unterschiedlichen Ständen voneinander abhängiger Dateien wie z.B. der voip.cfg und der fx_conf) ... besonders der ctlmgr hält eine interne Kopie einiger Dateien (u.a. der ar7.cfg), was man leicht prüfen kann, indem man einfach einen leeren Inhalt in die ar7.cfg schreibt und anschließend mit "ctlmgr_ctl" irgendeine Einstellung ändert. Nach einer "grace period" ohne weitere Änderungen schreibt dann der ctlmgr seine interne Kopie mit der geänderten Einstellung wieder in das char-Device im TFFS zurück (bzw. der verwendet sogar den Pfad /var/flash/ar7.cfg und läßt sich mit einem "regular file" anstelle des char-Devices übertölpeln).

Andere Komponenten greifen zwar auch direkt auf die Einstellungsdaten in /var/flash zu, aber meines Wissens (kann sich aber bei der alten Version als ungenau herausstellen) ist der ctlmgr die einzige (Daemon-)Komponente, die da Schreibarbeiten ausführt.

Änderst Du jetzt eine der vom ctlmgr gepufferten Dateien und aus irgendwelchen Gründen schreibt der vor dem Neustart noch einmal seine interne Kopie, ist es natürlich mit Deiner Änderung Essig ... daher solltest Du Dir überlegen, vorher schon den ctlmgr zu beenden. Aber dann geht eben auch kein GUI mehr und wenn Du zu lange brauchst, schießen Dir andere Komponenten, denen das Fehlen des ctlmgr sauer aufstößt, die Box per Watchdog ab. Ich würde also die ganzen Änderungen an den Einstellungsdateien in ein Batch-Skript verpacken und das nach dem Beenden des ctlmgr abarbeiten sowie anschließend neu starten.

Du könntest allerdings auch einen Aufruf von tr0ß69fwupdate configimport mit "virtueller Umgebung" machen, indem Du das einfach in einem chroot-Jail ausführen läßt. In dem resultierenden /var/flash-Verzeichnis im Jail sollten sich dann die Dateien befinden, die original in der Export-Datei enthalten waren (das "setfactorydefaults", was ja für die Zeilen ab

+++ do 'clear country'... +++
+++ do 'clear language'... +++

verantwortlich ist, sollte natürlich nicht verfügbar sein im Jail).

Das wäre auch eine weitere Möglichkeit, die allerdings die Ursache des Import-Problems nicht beseitigen dürfte ... Du könntest ja auch beim "configimport" das Skript /bin/setfactorydefaults durch einen Dummy ersetzen und einfach mal schauen, was die Box mit den importierten (falschen) Daten anfangen kann und ob Du event. durch einen neuen Export eine gültige Datei für einen späteren Import erhalten kannst.

Ansonsten kann man auch den Import in einzelnen Files ausführen, bis man die "schuldige Datei" in der Export-Datei identifiziert hat und diese beim Import dann einfach weglassen könnte.

Das ist aber alles eher nicht trivial und mit steigendem Aufwand ist eine Neukonfiguration (dabei kann man ja alte Settings auch gleich mal neu hinterfragen) wohl doch die bessere Lösung.

 

[eva.luation]

(da kam Dein Post rein, als ich an meinem schon am Tippen war)

allcfgconf schaue ich mir mal genauer an. Kling, als könnte ich die extrahierten Teilkonfigdateien mit denen in der Box "mergen". Das wäre natürlich super.

Ehrlich gesagt habe ich vom Rest nicht allzu viel verstanden.
Es gibt wohl einen Manager, der einiges cached und mit einen Strich durch die Rechnung machen kann.
Spätestens bei der virtuellen Umgebung bin ich ausgestiegen...

----

ok.
Arbeite gerade an Plan B.

Habe das Tool "ruKernelTool" entdeckt und schaue mir gerade die aus meinem Export extrahierten Konfigdateien an.
Über das Tool lassen sich auch Konfigdateien live von der Box (über TELNET) extrahieren, können editiert und wieder zurückgespielt werden.

Also dachte ich mir, ich kopiere den Inhalt der Dateien aus meinem defekten Export einfach in den Editor von ruKernelTool.

Wäre ja auch zu einfach gewesen. Beim Rückschreiben teilt mir ruKernelTool mit, dass das Schreiben nicht erfolgreich gewesen sei.

Wenn ich keinen Weg finde, die problematische Sicherung wiederherzustellen, bleibt mir möglicherweise nichts anderes übrig, als die Konfigs Zeile für Zeile durchzugehen...

 

[PeterPawn]

Über das Tool lassen sich auch Konfigdateien live von der Box (über TELNET) extrahieren, können editiert und wieder zurückgespielt werden.
Also dachte ich mir, ich kopiere den Inhalt der Dateien aus meinem defekten Export einfach in den Editor von ruKernelTool.

Dabei darfst Du aber keine verschlüsselten Einstellungen in den Editor kopieren.

Dieser Editor funktioniert nur solange, wie er über das alte allcfgconv und die dort noch vorhandene Option "-c" die Daten im Klartext auslesen kann. Dann kannst Du nicht bei Speichern irgendwelche verschlüsselten Daten (das ist jeder Ausdruck, der auf regexp: \"\$\{4\}[A-Z1-6]*\" paßt) zurückschreiben. Ob Du das überhaupt gemacht hast, weiß ich zwar auch nicht (das steht da irgendwie nicht), aber es funktioniert so eben prinzipiell nicht. Die Box verschlüsselt die Daten in einer Datei im Klartext von alleine, wenn es eine weitere Änderung an solch einer Datei ausführen muß. Dabei ist aber wieder der Cache des ctlmgr zu berücksichtigen, ich weiß nicht, wie das ruKernelTool da arbeitet. Wenn das nur blind die Datei schreibt und der ctlmgr läuft weiter, wäre das (s. vorheriger Beitrag) ohnehin nutzlos.

Das ruKernelTool arbeitet ja nur mit einer Telnet-"Fernbedienung", Du kannst also problemlos im Log nachschauen, was "Schreiben nicht erfolgreich" eigentlich wirklich heißen soll.