Fritz!box 7490 und FRITZ!Fon C4: Telefonbucheinträge bei Kennwortverlust retten

[PeterPawn]

Wie Du willst ... der Dateiname wird ja beim Aufruf von "BootDeviceFromImage" in der "EVA-FTP-Client.ps1" angegeben und da gibt es keine "Standarderweiterung" für Dateinamen.

 

[horni01]

Hallo,

ich bin leider nicht an den Fehlertext aus der Powershell rangekommen. Er hat angefangen das Image zu schreiben und dann mit einem runtime error war das glaub ich abgebrochen. Ich hab keine Ahnung welchen Fehler ich da gemacht haben könnte. Entschuldige bitte meine ungenaue Fehlerangabe.

 

[PeterPawn]

Wenn Du den Aufruf mit den Optionen "-Verbose" und "-Debug" versiehst, kann man anhand der Ausgaben wenigstens abschätzen, wo das Problem liegen könnte. Ansonsten startet man über das Windows-Start-Menü eine "PowerShell"-Instanz (notfalls als Administrator) und dann gibt es eigentlich kein Problem, in dieser Konsole (das ist dann alles textbasiert) auch so weit zurückzublättern, daß man den kompletten Aufruf mit allen Ausgaben und ggf. auch einer Fehlernachricht sehen und hier - in "CODE"-Tags eingeschlossen - veröffentlichen kann.

Es ist auch kein Problem, das nach einem Neustart der FRITZ!Box immer und immer wieder zu versuchen (allerdings muß so ein Neustart zwischendrin sein, weil mehrfache Aufrufe den Speicher immer weiter reduzieren), bis man entweder aufgeben will oder ein sinnvolles Ergebnis in Form eines (reproduzierbaren) Fehlers erhält.

Ohne diese Informationen kann ich natürlich auch nicht helfen ... was weiß ich denn, wo das Problem am Ende liegt. Das könnte schon darauf zurückzuführen sein, daß eine PowerShell im "Nicht-Administrator"-Modus vielleicht gar nicht auf die Idee mit der Nachfrage kommt, ob der Zugriff in der Firewall freigeschaltet werden soll oder nicht - wobei das eigentlich mehr das "EVA-Discover.ps1" betreffen würde (das braucht den eingehenden Zugriff für die UDP-Antwort, weil es selbst als Broadcast sendet und es daher keine passende ausgehende Verbindung gibt, in der so eine Antwort durchgelassen würde) und beim Aufruf von "EVA-FTP-Client.ps1" kein Thema sein sollte. Wenn der wirklich das Image hochgeladen hat oder zumindest damit begonnen haben sollte, dann wäre ja "EVA-FTP-Client.ps1" von dem Fehler betroffen.

 

[horni01]

okay hier die Ausgabe:
PS D:\> .\yourfritz\EVA-Discover.ps1 -maxWait 120 -Debug -Verbose
>>
AUSFÜHRLICH: Sending discovery packet (1) ...
AUSFÜHRLICH: Sending discovery packet (2) ...
AUSFÜHRLICH: Sending discovery packet (3) ...
AUSFÜHRLICH: Sending discovery packet (4) ...
AUSFÜHRLICH: Sending discovery packet (5) ...
AUSFÜHRLICH: Sending discovery packet (6) ...
DEBUG: Received UDP packet from 192.168.178.1:5035 ...
AUSFÜHRLICH: Trying to connect to the FTP port to hold up the device in bootloader ...
DEBUG: Error during FTP connection attempt ...
EVA_IP=192.168.178.1
True
PS D:\> .\yourfritz\EVA-FTP-Client.ps1 -Verbose -Debug -ScriptBlock { BootDeviceFromImage .\yourfritz\skip_auth.image.74
90 }
>>
DEBUG: Response:
220 ADAM2 FTP Server ready

================
DEBUG: Sent
USER adam2
================
DEBUG: Response:
331 Password required for adam2

================
DEBUG: Sent
PASS adam2
================
DEBUG: Response:
230 User adam2 successfully logged in

================
DEBUG: Sent
SYST
================
DEBUG: Response:
215 AVM EVA Version 1.1964 0x0 0x740D

================
DEBUG: Sent
GETENV memsize
================
DEBUG: Response:
memsize 0x10000000

200 GETENV command successful

================
DEBUG: Memory size found : 08000000
DEBUG: Image size found : 0x00463d00
DEBUG: Set memory size to : 0x07b9c300
DEBUG: Set MTD ram device to: 0x87b9c300,0x88000000
DEBUG: Sent
SETENV memsize 0x07b9c300
================
DEBUG: Response:
200 SETENV command successful

================
DEBUG: Sent
SETENV kernel_args_tmp mtdram1=0x87b9c300,0x88000000
================
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 '.\yourfritz\skip_auth.image.7490' to '0x87b9c300 0x88000000' ...
DEBUG: Sent
P@SW
================
DEBUG: Response:
227 Entering Passive Mode (192,168,178,1,12,12)

================
DEBUG: Sent
SETENV memsize 134217728
================
DEBUG: Response:
200 SETENV command successful

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

================
Ausnahme beim Aufrufen von "Invoke" mit 0 Argument(en): "Error uploading image file."
In D:\yourfritz\EVA-FTP-Client.ps1:610 Zeichen:17
+ $ScriptBlock.Invoke()
+ ~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: ) [], MethodInvocationException
+ FullyQualifiedErrorId : RuntimeException

PS D:\>

 

[PeterPawn]

Offenbar findet er die Datei für den Upload nicht ... probiere mal bitte, den Pfad dorthin absolut (also beginnend mit dem Laufwerksbuchstaben und dem kompletten Pfad) anzugeben.

Ich dachte zwar, ich hätte das bereits abgeändert, daß da auch ein relativer Name funktioniert (als ich mal darauf angesprochen wurde), aber ich habe keine Ahnung, wo diese Änderung geblieben sein könnte.

Bis dahin also bitte den Pfad zum Image absolut angeben (ich denke mal, daß es dann funktioniert - wenn nicht, ist natürlich weitere Suche angesagt) - zumindest mal als Test, ob es wirklich daran liegt. Die Fehlerbehandlung ist dort etwas rudimentär und jedes Problem führt zum Abbruch, aber es ist entweder der fehlschlagende Verbindungsaufbau für die Datenverbindung oder die Datei kann nicht geöffnet werden.

- - - Aktualisiert - - -

Ich habe mal eine geänderte Version von "EVA-FTP-Client.ps1" eingecheckt, die auch mit relativen Pfaden zurechtkommen sollte - den Anhang weiter vorn im hiesigen Thread habe ich auch ausgetauscht (also ggf. neu speichern).

Es sieht zwar auf den ersten Blick widersinnig aus, wenn die Datei wegen der Pfadangabe beim Upload nicht gefunden wird, nachdem zuvor schon die Größe korrekt ermittelt wurde (und dabei auch schon feststand, daß es die Datei wirklich gibt), aber das aktuelle Verzeichnis der PowerShell als Basis für relative Pfadangaben muß nicht mit dem intern von den .NET-Funktionen verwendeten übereinstimmen und die Zugriffe bei der Datenübertragung erfolgen mit den .NET-Funktionen.

Bei der Gelegenheit habe ich dann gleich noch die Fehlerbehandlung etwas überarbeitet und das Skript loggt sich jetzt hoffentlich auch bei Fehlern nach erfolgreichem Login korrekt aus ... damit muß man die FRITZ!Box nicht nach jedem kleinen Problem neu starten, weil der FTP-Server irgendwie durcheinandergeraten ist.

 

[Pokemon20021]

okay hier die Ausgabe:

PS D:\> .\yourfritz\EVA-Discover.ps1 -maxWait 120 -Debug -Verbose
>>
AUSFÜHRLICH: Sending discovery packet (1) ...
AUSFÜHRLICH: Sending discovery packet (2) ...
AUSFÜHRLICH: Sending discovery packet (3) ...
AUSFÜHRLICH: Sending discovery packet (4) ...
AUSFÜHRLICH: Sending discovery packet (5) ...
AUSFÜHRLICH: Sending discovery packet (6) ...
DEBUG: Received UDP packet from 192.168.178.1:5035 ...
AUSFÜHRLICH: Trying to connect to the FTP port to hold up the device in bootloader ...
[COLOR=#ff0000]DEBUG: Error during FTP connection attempt ...[/COLOR]
EVA_IP=192.168.178.1
True
PS D:\>

@PeterPawn: wie ist die Meldung "Error during FTP connection attempt ..." bei Skriptausführung EVA-Discover.ps1 zu interpretieren ?
any hint welcome.

 

[horni01]

Hallo,

@PeterPawn: Perfekt! Vielen herzlichen Dank an dich, jetzt lief eva-ftp bis zum Ende durch.
War zwar ein Weg mit Barrieren, der trotzdem zum Ziel geführt hat.
Danke für deine Gedult mit mir und die tatkräftige Unterstützung. ;-)

Außerdem
denke ich, daß es auch als gutes Beispiel dienen kann, wenn sich hier jemand mit SR und BZ im Forum bewegt und damit zeigt, daß es hier keine unüberwindbaren
Hürden gibt. Es gibt schließlich genug Teilnehmer hier, die sich gerne auf "ich finde nichts" oder "ich kann das nicht lesen" herausreden, obwohl sie selbst
nicht mit einer Braille-Zeile arbeiten müssen und das Handicap wohl an anderer Stelle liegt.

Das glaube ich auch! Hier noch mal die Ausgabe des Skripts:

PS D:\> .\yourfritz\EVA-Discover.ps1 -maxWait 120 -Debug -Verbose
>>
AUSFÜHRLICH: Sending discovery packet (1) ...
AUSFÜHRLICH: Sending discovery packet (2) ...
AUSFÜHRLICH: Sending discovery packet (3) ...
AUSFÜHRLICH: Sending discovery packet (4) ...
AUSFÜHRLICH: Sending discovery packet (5) ...
AUSFÜHRLICH: Sending discovery packet (6) ...
DEBUG: Received UDP packet from 192.168.178.1:5035 ...
AUSFÜHRLICH: Trying to connect to the FTP port to hold up the device in bootloader ...
DEBUG: Error during FTP connection attempt ...
EVA_IP=192.168.178.1
True
PS D:\> .\yourfritz\EVA-FTP-Client.ps1 -Verbose -Debug -ScriptBlock { BootDeviceFromImage .\yourfritz\skip_auth.image.74
90 }
>>
DEBUG: Response:
220 ADAM2 FTP Server ready

================
DEBUG: Sent
USER adam2
================
DEBUG: Response:
331 Password required for adam2

================
DEBUG: Sent
PASS adam2
================
DEBUG: Response:
230 User adam2 successfully logged in

================
DEBUG: Sent
SYST
================
DEBUG: Response:
215 AVM EVA Version 1.1964 0x0 0x740D

================
DEBUG: Sent
GETENV memsize
================
DEBUG: Response:
memsize 0x10000000

200 GETENV command successful

================
DEBUG: Memory size found : 08000000
DEBUG: Image size found : 0x00463d00
DEBUG: Set memory size to : 0x07b9c300
DEBUG: Set MTD ram device to: 0x87b9c300,0x88000000
DEBUG: Sent
SETENV memsize 0x07b9c300
================
DEBUG: Response:
200 SETENV command successful

================
DEBUG: Sent
SETENV kernel_args_tmp mtdram1=0x87b9c300,0x88000000
================
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 '.\yourfritz\skip_auth.image.7490' to '0x87b9c300 0x88000000' ...
DEBUG: Sent
P@SW
================
DEBUG: Response:
227 Entering Passive Mode (192,168,178,1,12,13)

================
DEBUG: Sent
STOR 0x87b9c300 0x88000000
================
DEBUG: Response:
150 Opening BINARY data connection

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

================
True
PS D:\>

Viele Grüße

 

[PeterPawn]

wie ist die Meldung "Error during FTP connection attempt ..." bei Skriptausführung EVA-Discover.ps1 zu interpretieren ?

Ich weiß es auch nicht ... um das zu ermitteln, müßte man nach Zeile 129 in "EVA-Discover.ps1" mal noch so etwas wie "Write-Verbose $_.Exception" einfügen, damit der Text der Exception noch einmal angezeigt wird.

Ich prüfe dort ja nur, ob der aufgetretene Fehler den Text "(502) Command not implemented." enthält, was nicht sehr flexibel ist - schon die kleinste Abweichung im Text (z.B. durch eine andere .NET-Version und hier geht es wohl um W10 x64, ggf. auch mit dem letzten Update) führt zu dieser Nachricht.

Ja, es könnte sogar sein, daß der Text nach dem "(502)" gar nicht von der Box stammt (obwohl die m.W. denselben Text auch ausgibt bei unbekannten Kommandos) und es sich hier um die "Übersetzung" des FTP-Fehlercodes "502" durch die .NET-Runtime handelt.

Dann steht da bei @horni01 vermutlich so etwas wie "Kommando nicht implementiert", denn auch "VERBOSE" wurde ja den Beiträgen zufolge "übersetzt" nach "AUSFÜHRLICH".

In Englisch lautet die Fehlermeldung:

Exception calling "GetResponse" with "0" argument(s): "The remote server returned an error: (502) Command not implemented."

Die Tatsache, daß die Box im Anschluß trotzdem erreichbar war (das sah man an den Nachrichten aus dem "EVA-FTP-Client.ps1" danach), ließ mich diesen Fehler ignorieren - wenn ich weiß, was die wirkliche Ursache ist (sprich, wenn mir jemand die Details der Exception in einem deutschen W10 x64 mitteilt - ich tendiere immer mehr in die Richtung der Übersetzung als Ursache), passe ich das gerne an. Stimmt meine Vermutung, wäre der Test von "$_.FullyQualifiedErrorId" auf "WebException" und das Beschränken des Textvergleichs bei der Exception-Message auf "(502)" vielleicht schon eine Lösung - nur das "(502)" war mir hier etwas zu wenig aus dem Bauch heraus.

- - - Aktualisiert - - -

@horni01:
Viel wichtiger als das Debug-Protokoll (auch dafür allerdings Dank, denn dann kann der Nächste das mit seiner Ausgabe vergleichen) ist es ja nun, ob Du damit beim nächsten Start dann dazu aufgefordert wurdest, ein neues Kennwort für die Box zu setzen und Du damit wieder den Zugriff auf die FRITZ!Box hattest ... das war schließlich das Ziel des Ganzen.

Dabei kann man sich dann aussuchen, ob man die Checkbox bei "FRITZ!Box-Kennwort jetzt setzen (empfohlen)" aktiviert läßt und erst einmal eines eingibt oder ob man die (ausnahmsweise) deaktiviert, weil man ohnehin als Erstes in die Benutzerverwaltung wandern und dort das Kennwort eines vorhandenen Accounts neu setzen will, bevor man wieder auf "Benutzername/Kennwort" bei der Anmeldung umstellt.

Wenn man die Checkbox deaktiviert, bleibt der eingestellte Anmeldemodus bei der dritten Möglichkeit stehen, legt man in dieser GUI-Maske ein Kennwort fest, wird die zweite Möglichkeit aktiviert. Die sicherste ist aber selbstverständlich die erste Auswahl und dauerhaft sollte man die FRITZ!Box nur in diesem Modus betreiben.

Zwar hat der Benutzer @CompatMode normalerweise keinen Zugriff aus dem Internet, aber auch mehrere Konten im LAN (selbst wenn AVM die immer noch zwangsweise bereits in der Anmeldemaske aus dem LAN "veröffentlicht") vervielfachen (zumindest in der Theorie, wo man aus dem Benutzernamen nicht automatisch auf die Rechte schließen kann) schon die Möglichkeiten, die ein Angreifer austesten müßte und nicht zuletzt ist es auch für die "Überwachung" sinnvoller, wenn neben einer Anmeldung im Ereignisprotokoll auch noch steht, welcher Benutzer es eigentlich war und das fehlt dann bei "Anmeldung nur mit Kennwort".

Sollte es also geklappt haben, wäre die "Erfolgsmeldung" mit expliziter Feststellung, daß damit der Zugriff trotz verlorenem Kennwort wieder möglich war, noch das Tüpfelchen auf dem "i", damit der nächste Leser dann sicher weiß, daß sich die investierte Anstrengung lohnen kann ... und wenn man erst einmal meinen Fehler mit dem absoluten vs. relativen Dateinamen ausblendet, dann hält sich der Aufwand ja auch in sehr überschaubaren Grenzen - erst recht dann, wenn man ihn mit der Alternative des Zurücksetzens auf die Werkseinstellungen und den daraus folgenden Konsequenzen vergleicht.

 

[horni01]

Hallo,

@horni01:
Viel wichtiger als das Debug-Protokoll (auch dafür allerdings Dank, denn dann kann der Nächste das mit seiner Ausgabe vergleichen) ist es ja nun, ob Du
damit beim nächsten Start dann dazu aufgefordert wurdest, ein neues Kennwort für die Box zu setzen und Du damit wieder den Zugriff auf die FRITZ!Box hattest
... das war schließlich das Ziel des Ganzen.

Das kann ich hiermit bestätigen und habe Kennwort setzen und Anmeldung umstellen dann über die Benutzerverwaltung erledigt.
Gleich noch bei der Gelegenheit die Konfiguration gesichert.

Die sicherste ist aber selbstverständlich die erste Auswahl und dauerhaft sollte man die FRITZ!Box nur in diesem
Modus betreiben.

Genauso sehe ich das auch. Die Botschaft ist bei meinem Bekannten auch angekommen und das wird ihm eine Lehre gewesen sein.

Vielen Dank.