Fritzbox 7390 nach update von 84.06.23 auf 84.06.30 WinError 13

[furacer]

Hallo zusammen,

leider hat sich meine Fritzbox 7390 beim letzten Update aufgehängt, dies erfolgte über die OS Oberfläche.

Nach kurzen Kontakt mit der Hotline habe ich das Recovery Tool (sowohl für die Versio 30 als auch Version 23) gestartet, jedoch ging es nur bis zum Fehler mtd1 WinError 13.

Nach Recherche hier im Forum habe ich das Tool RuKernel ausprobiert, entsprechend auch meine Firewall ausgeschaltet.

Leider bekomme ich auch hier beim Upload ein Fehler, seht ihr noch Chancen die Fritzbox zu retten?

Welche Informationen benötigt ihr?

Vielen Dank schon einmal für eure Hilfe.

Fehlermeldung Upload:

LibNcFTP 3.2.5 (January 17, 2011) compiled for Windows
220: ADAM2 FTP Server ready
Connected to 99.88.77.1.
Cmd: USER adam2
331: Password required for adam2
Cmd: PASS xxxxxxxx
230: User adam2 successfully logged in
Logged in to 99.88.77.1 as adam2.
Cmd: MEDIA FLSH
200: Media set to MEDIA_FLASH
Cmd: TYPE I
200: Type set to BINARY
Cmd: PASV
227: Entering Passive Mode (99,88,77,1,36,177)
Cmd: STOR mtd1
150: Opening BINARY data connection
426: Data connection closed
ncftpput mtd1: could not send file to remote host.
Cmd: QUIT
501: Syntax error: Invalid number of parameters
Cmd: QUIT
505: Close Data connection first​

Das sind die Infos aus dem Download Log, leider kann ich hier auch nur teilweise die Daten auslesen:

5) Bootvorgang anhalten:

Adam2-IP-Adresse setzen... erfolgreich
Warten auf die Box... Box anpingen... Host ist da.
FTP-Verbindung zum Stoppen aufbauen... überprüfen... verbunden

Box-Informationen:
ProductID: Fritz_Box_7390
HWRevision: 156
HWSubRevision: 3
annex: B
autoload: yes
bootloaderVersion: 1.947
bootserport: tty0
cpufrequency: 500000000
firmware_info: 84.06.23
firmware_version: avm
firstfreeaddress: 0x810C9834
flashsize: 0x01000000
maca: 24:65:11:5A:BA:25
macb: 24:65:11:5A:BA:26
macdsl: 24:65:11:5A:BA:28
macwlan: 24:65:11:5A:BA:27
macwlan2: 24:65:11:5A:BA:2B
memsize: 0x08000000
modetty0: 38400,n,8,1,hw
modetty1: 38400,n,8,1,hw
mtd1: 0x9F020000,0x9FF00000
mtd2: 0x9F000000,0x9F020000
mtd3: 0x9FF00000,0x9FF80000
mtd4: 0x9FF80000,0xA0000000
my_ipaddress: 169.254.235.1
req_fullrate_freq: 166666666
prompt: Eva_AVM
SerialNumber: 0000000000000000
sysfrequency: 166666666
tr069_passphrase: VQLHKuydb4v8
tr069_serial: 00040E-2465115ABA25
urlader-version: 1947
usb_board_mac: 24:65:11:5A:BA:29
usb_device_id: 0x0000
usb_manufacturer_name: AVM
usb_revision_id: 0x0000
usb_rndis_mac: 24:65:11:5A:BA:2A


Flash-/Speichergrößen:
Flashsize: 16.777.216 Bytes (16.384 kB, 16 MB)
Memsize: 134.217.728 Bytes (131.072 kB, 128 MB, 0,1 GB)
mtd1: 15.597.568 Bytes (15.232 kB, 14,9 MB)
mtd2: 131.072 Bytes (128 kB, 0,1 MB)
mtd3: 524.288 Bytes (512 kB, 0,5 MB)
mtd4: 524.288 Bytes (512 kB, 0,5 MB)

ProductID: Fritz_Box_7390
HW-Revision: 156 => FRITZ!Box Fon WLAN 7390​

 

[PeterPawn]

Die FRITZ!Box ist da und antwortet vollkommen logisch. Die Frage ist, was die Übertragung tatsächlich beendet ... das kann der Bootloader bei einem Fehler der Hardware sein, daran glaube ich aber bei der Aussage "entsprechend auch meine Firewall ausgeschaltet" eher nicht. Auch sieht man ja, daß da beide Seiten vollkommen unterschiedliche Ansichten haben, ob da nun eine Datenverbindung besteht oder nicht, was die Wahrscheinlichkeit einer "dritten Partei" als Quelle für das "FIN-Paket", das zur Nachricht "426: Data connection closed" führte, auf weit über 95% (reine Effekthascherei diese Angabe ) erhöht. Die FRITZ!Box ist ja offensichtlich nach wie vor der Meinung, die Datenverbindung würde weiterhin bestehen, wie sie mit der Antwort "505: Close Data connection first" auf den Abschiedsgruß des FTP-Clients zu verstehen gibt.

Es gibt leider immer wieder irgendwelche "Security-Suiten", die es zu gut mit dem dummen Windows-Benutzer meinen und sich trotzdem noch in solche Verbindungen einklinken. Da beim Recovern schon mal ein etwas ungewöhnlicher "Dialog" im FTP abläuft, brechen sie dann solche Verbindungen auch schon mal ab.

Ich würde also mal mit einer Windows-Installation ohne solche "Erweiterungen" an den Start gehen. Die Windows-Firewall ist an dieser Stelle eher harmlos (auch wenn AVM ihre Deaktivierung empfiehlt), wenn man dem Recovery-Programm den Zugriff im richtigen Profil (ruhig auch "public", denn das "Peer-to-Peer-Netz" zwischen FRITZ!Box-Bootloader und Windows-PC ist selten "private") gestattet. Notfalls eben ein gesondertes Windows aus einem VHD-Container booten, wenn es ansonsten keine Maschinen bei Dir gibt. Wie so eine Multi-Boot-Konfiguration mit einer Containerdatei auszusehen hat, ist an vielen Stellen im Internet beschrieben, das findest Du dann schon.

Allerdings solltest Du vor dem nächsten Einsatz des Recovery-Programms (einfach nur der Ordnung halber) den "my_ipaddress"-Eintrag im Urlader-Environment wieder auf den Standard-Wert 192.168.178.1 ändern ... ist zwar nicht unbedingt erforderlich, verwirrt aber nicht noch zusätzlich.

In der AVM-Anleitung für das Recovern würde ich ohnehin die Unterpunkte 3 und 4 im Punkt "4 Firewalls beenden" durch einen Neustart von Windows ersetzen, sonst macht der Unterpunkt 2 davor

Richten Sie alle Firewalls auf Ihrem Computer (z.B. Zone Alarm, Norton Internet Security) so ein, dass die Programme nach einem Neustart des Computers nicht automatisch wieder gestartet werden.

irgendwie keinen Sinn (abgesehen davon, daß nicht darauf hingewiesen wird, daß man diese Einstellung natürlich irgendwann wieder rückgängig machen sollte). Da einige dieser Security-Programme aber ihre Treiber beim Systemstart ziemlich tief im Netzwerk-Stack verankern (und nicht nur mit den von MS für "Virenscanner" vorgesehenen Schnittstellen arbeiten), ist ein Reboot mit deaktivierter Firewall in jedem Falle zu empfehlen, wenn man die radikalste Lösung (vorübergehende Deinstallation) nicht opportun findet. Das Deaktivieren der Windows-Firewall würde ich mir aber klemmen (auch wenn es natürlich für die Zeit, wo der PC nur mit der FRITZ!Box verbunden ist, nichts schadet) ... wenn man dem Programm den Zugriff in allen Lebenslagen gestattet, klappt es spätestens beim zweiten Versuch, falls beim ersten das Beantworten der Frage nach dem Erlauben des Zugriffs zu lange dauern sollte.

 

[informerex]

wegen Sicherheits-Suites ist es immer noch am sichersten und einfachsten (oft übersieht man was), diese bei Problemen vom System zu entfernen und zwar mit einem removal-Tool des Herstellers. (da teilweise selbst die Standard-Routine nicht ausreicht)

um welche Box handelt es sich genau?
wirklich nur nach einem FW-Update og. Fehler oder wurde vielleicht nicht doch noch weitere Änderung/Versuche/Tests unternommen?
evtl. auch nur mal Werksreset per Telefoncode (analoges Telefon) und ein PoR (5 Min. alle Kabel entfernen) - denn die Box hat noch Zugangsdaten gespeichert

 

[furacer]

Hallo,

danke euch 2 schon einmal für die Tipps, ich habe noch einen alten Vista Rechner ohne irgendeine Firewall.
Muss aber hier noch Telnet nach installieren, sobald ich das startklar habe probiere ich es neu aus.

Nein ich habe nichts bewusst an der Fritzbox angepasst, bis vor ca. 2 Jahren hatte sie angepasste Parameter, da ich von Vodafone die Easybox ersetzt hatte. Dies ist aber schon seit 2 jahren passe da es seitdem Kabel Deutschland als Anbieter ist und die Fritzbox direkt nachdem Modem geschaltet ist.

Eckdaten waren nochmal die Fritzbox 7390 mit update von 84.06.23 auf 84.06.30

 

[KunterBunter]

Muss aber hier noch Telnet nach installieren

Wo und wozu?

 

[furacer]

habe gerade geschaut, ja man braucht es nur im experten modus und damit unnötig

 

[PeterPawn]

Welcher "Expertenmodus" denn nun schon wieder?

Wenn Du es nicht unnötig verkomplizieren willst, nimm das AVM-Recovery-Programm, die etwas modifizierte Anleitung und gut ist's ...

 

[tuxedonet]

leider hat sich meine Fritzbox 7390 beim letzten Update aufgehängt, dies erfolgte über die OS Oberfläche.

Hinweis: das Fehlerbild "Fritz!Box ist nach Update per WebIF nicht mehr erreichbar" ist bei mir und vielen anderen IPPF-Usern auch aufgetreten,
Ursache hier war, dass der Browser-Cache nicht aktualisiert wurde;
Lösung: Einfach Browser-Cache löschen oder temp. Browser wechseln und dann geht's.

Siehe auch AVM-Knowledgebase: http://avm.de/nc/service/fritzbox/f...n-der-FRITZ-Box-Benutzeroberflaeche-moeglich/


es wäre gut, wenn AVM mal dies gleich in dem von PeterPawn genannten Link #2 Recovery-Prozedur erwähnen würde.

 

[furacer]

Hallo zusammen,

folgender Punkt wurde ausprobiert:

Auf meinem alten Notebook habe ich nur Vista installiert ohne irgendeine Firewall oder Virenprogramm
Windows Firewall und Defender sind deaktiviert

Auch hier komme ich mit dem Recovery Programm von AVM nicht weiter

Recover der Partition mtd1 fehlgeschlagen! WinError 13

 

[furacer]

Hallo zusammen,

zusätzlich habe ich im Anschluss folgendes ausprobiert:

Auf meinem alten Notebook habe ich nur Vista installiert ohne irgendeine Firewall oder Virenprogramm
Windows Firewall und Defender sind deaktiviert

RuKernelTool Upload

myIPadress wieder auf Standard gesetzt

Jedoch gleicher Fehler wie oben

Fehlermeldung Upload:


LibNcFTP 3.2.5 (January 17, 2011) compiled for Windows
220: ADAM2 FTP Server ready
Connected to 99.88.77.1.
Cmd: USER adam2
331: Password required for adam2
Cmd: PASS xxxxxxxx
230: User adam2 successfully logged in
Logged in to 99.88.77.1 as adam2.
Cmd: MEDIA FLSH
200: Media set to MEDIA_FLASH
Cmd: TYPE I
200: Type set to BINARY
Cmd: PASV
227: Entering Passive Mode (99,88,77,1,36,177)
Cmd: STOR mtd1
150: Opening BINARY data connection
426: Data connection closed
ncftpput mtd1: could not send file to remote host.
Cmd: QUIT
501: Syntax error: Invalid number of parameters
Cmd: QUIT
505: Close Data connection first

 

[PeterPawn]

Einen Switch mit Port-Mirroring (einen Hub hat fast keiner mehr) zwischen die FRITZ!Box und den Rechner mit dem Recovery-Programm einbauen und über das Port-Mirroring den Datenverkehr zwischen Box und Rechner mit einem dritten Gerät mitschneiden.

Die entscheidende Frage ist, woher der Abbruch der FTP-Datenverbindung kommt. Da die Box in diesem Zustand noch nicht selbst einen Mitschnitt anfertigen kann und ein von irgendwelcher Software auf dem PC initiierter Verbindungsabbau auch so erfolgen könnte, daß man den in einem Mitschnitt nicht von einem tatsächlich von der Box kommenden unterscheiden kann, muß man praktisch "am Kabel" zwischen den Geräten mitschneiden.

Auch bei der 7390 wird ja erst einmal der TFFS-Inhalt neu geschrieben (nach MTD3 und MTD4), soweit ich mich erinnern kann ... da würde ich ja einen Fehler 13 (der steht eigentlich für "invalid data") noch für plausibel und möglich halten. Wie das beim Schreiben der Kernel-Partition (denn das wäre ja MTD1) passieren soll, erschließt sich mir nicht. Nachdem da sicherlich das Recovery-Programm seinerseits bloß einen Windows-Fehlercode in eine "lesbare Form" übersetzt, stellt sich die Frage, was da eigentlich am Ende schief laufen soll. Da man ja nicht genau weiß, was das Recovery-Programm da intern wirklich im Einzelnen anstellt, kann man es nur an seinen Taten erkennen und die sieht man eben am ehesten in einem Packet-Dump - nur dort kann man (wenn man weiß, wie das aussieht wenn es funktioniert) vergleichen, wie weit das Programm beim Schreiben kommt bzw. wie weit ggf. unvollständige Übertragungen fortgeschritten sind, wenn das Problem auftritt.

Wenn Du also keinen passenden Switch besitzt, kannst Du trotzdem einen solchen Recovery-Vorgang mal mit WireShark mitschneiden und das Ergebnis hier in komprimierter Form als Anhang bereitstellen ... dann kann man mal einen Blick hinein werfen. In dem Protokoll der LibNcFTP sieht man leider nicht, welche Nachricht vom FTP-Server selbst und welche vom Client ausgeht und schon gar nicht, ob zwischen dem "STOR mtd1" mit der anschließenden "150"-Message und dem Abbruch mit "426" überhaupt Daten übertragen wurden oder nicht (bei "could not send" würde ich auf "nein" tippen und die Frage ist, woran das liegt). Wenn die Datenübertragung seitens der FRITZ!Box beendet wird, stellt sich die Frage, ob die nachfolgenden Fehlernachrichten (501 und 505) von der Lib oder tatsächlich vom Server kommen. Wenn die vom Server kommt (besonders die 505), nachdem er vorher ggf. schon mit "426" festgestellt hat, daß die Datenverbindung geschlossen wurde, stimmt ja etwas mit dem Statusautomaten des FTP-Servers nicht.

BTW ... das Recovery-Programm wurde mit erweiterten Rechten (als Administrator) gestartet? Aber eigentlich stellt sich diese Frage auch nicht wirklich, denn bis zum Fehler bei der Benutzung des Recovery-Programms sollte dort ja schon einiges passiert sein, was bei fehlenden Rechten auch nicht der Fall wäre. Vielleicht solltest Du trotzdem noch die Ausgabe des Recovery-Programms (sollte sich aus dem Fenster herauskopieren lassen) mal dazupacken ...

 

[DieWilde13]

Laut log wird immer noch die ip 99.88.77.1 benutzt anstatt einer privaten und somit nicht route-baren 192.168er. Das sollte als allererstes korrigiert werden.

 

[PeterPawn]

Ohne jeden Blick in den Mitschnitt sieht man schon mal, daß das definitiv nicht dasselbe Problem/Protokoll ist ... anders als Du es lesen möchtest, ist das nämlich durchaus eine andere Antwort nach dem "STOR mtd1". Da bricht auf einmal die Control-Verbindung ab, die bei den vorhergehenden Protokollen weiterhin bestanden hat und noch einige Bemerkungen zum "BYE" abgeben zu müssen glaubte.

Wenn ich Zeit finde, schaue ich mal in den Mitschnitt ... der ist jetzt aber auch von einem Aufruf des Recovery-Tools mit der Vista-Maschine (also definitiv ohne jede Firewall) und nicht von irgendwelchen Spielereien mit dem ruKernelTool, oder? Ersteres sehe ich mir an, für die Analyse eines ruKT-Mitschnitts solltest Du Dich an den Autoren des ruKT wenden.

Was mir hier noch fehlt, ist der Inhalt des Fensters des Recovery-Programms für den im Mitschnitt protokollierten Aufruf (#11 letzter Satz, ich hätte wohl auf das "vielleicht" verzichten sollen, denn es suggeriert eine Wahl, die Du nicht wirklich hattest).

Da Du diesen Fensterinhalt vermutlich auch nicht mehr hast, wäre ggf. das Anfertigen eines neuen Mitschnitts bei einem weiteren Versuch eine gute Idee - ebenso natürlich, wenn das oben der Mitschnitt des ruKT sein sollte.

 

[DieWilde13]

Habe mal in die Daten geschaut (würde aber auch lieber den Mitschnitt des Recovery-Programms sehen).
Bis zum "STOR mtd1" läuft alles bestens und die FB sendet über die Control-Verbindung noch ein ACK.
Nun wird es merkwürdig:
Nach 25 Sekunden (ich hoffe, ich interpretiere die Zeitangabe richtig) fängt der PC nun an ungeduldig TCP-KEEPALIVEs über Control- und Datenverbindung zu senden, die aber nicht beantwortet werden ... und nach nur 38 Sekunden setzt der PC mit einem RST beide Verbindungen zurück.

Dieses frühe Einsetzen von KEEP-ALIVE und der extrem schnelle Abbruch finde ich ungewöhnlich, deshalb meine Frage: Ist auf dem Rechner irgendeine "Optimierungs-Software" gelaufen, die die Default-Netzwerkeinstellungen ändert?
Wenn ja, kann man das wieder auf die Default-Werte zurücksetzen?

In meinem Verständnis müsste die FB beim "STOR mtd1" zuerst diese Partition löschen, was sicherlich länger dauern kann bis sie wieder antwortet ... anscheinend zu lange für die aktuellen Einstellungen auf diesem PC.
Mal sehen, was es noch für Ideen und Erkenntnisse gibt. Aber der Mitschnitt des Recovery-Programms wäre schon hilfreicher.

 

[furacer]

Hallo,

ja ich hatte ein Problem den upload mit der IP 192.168.178... (darum auch oben der Teil gelöscht, das führt sonst zu einem von mir verursachtem Problem)

Bitte die Fehler zu entschuldigen, so tief bin ich sonst nicht in diesen Daten.
Vielen Dank auch nochmal an alle für die Unterstützung.

Ich glaub ich habe das detailierte Fehler Protokoll was du meinst (WLAN Key habe ich rausgelöscht):

24.09.2015, 19:08:14,392, >ru_SetOrGetAdam2IPForOthers<: => keine gültige IPv4-Adresse
24.09.2015, 19:08:14,392, >ru_SetOrGetAdam2IPForOthers<: 1 Adapters for UDP Bind
24.09.2015, 19:08:14,688, >ru_BroadcastSend<: 16 Bytes gesendet
24.09.2015, 19:08:14,688, >ru_SetOrGetAdam2IPForOthers<: -- Sending Nr 1 --
24.09.2015, 19:08:14,688, >ru_SetOrGetAdam2IPForOthers<: Receive-Socket Nr: 1 # 1
24.09.2015, 19:08:14,688, >ru_SetOrGetAdam2IPForOthers<: ReceiveLoop:1 - Chars: 34
24.09.2015, 19:08:14,704, >ru_SetOrGetAdam2IPForOthers<: ReceiveLoop:2 - Chars: 34
24.09.2015, 19:08:14,704, >ru_SetOrGetAdam2IPForOthers<: ---- Fritzbox ist da! -----
24.09.2015, 19:08:14,720, >ru_SetOrGetAdam2IPForOthers<: Adam2IP: 192.168.178.1
24.09.2015, 19:08:14,720, >ru_SetOrGetAdam2IP<: Dauer: 357
24.09.2015, 19:08:14,720, >ru_SetOrGetAdam2IP<: Ergebnis-Set: 192.168.178.1
24.09.2015, 19:08:14,751, >ru_UpDownToFile<: erfolgreich
24.09.2015, 19:08:14,766, >ru_UpDownToFile<: Warten auf die Box... Box anpingen...
24.09.2015, 19:08:15,250, >ru_Ping<: Host "192.168.178.1" wurde nach 0 Sekunden erreicht
24.09.2015, 19:08:15,266, >ru_UpDownToFile<: Host ist da.
24.09.2015, 19:08:15,437, >ru_UpDownToFile<: FTP-Verbindung zum Stoppen aufbauen...
24.09.2015, 19:08:15,968, >ru_UpDownToFile<: überprüfen...
24.09.2015, 19:08:15,999, >ru_UpDownToFile<: verbunden
24.09.2015, 19:08:15,999, >ru_GetVarsFromFTPlogFile<: ProductID = Fritz_Box_7390
24.09.2015, 19:08:15,999, >ru_GetVarsFromFTPlogFile<: HWRevision = 156
24.09.2015, 19:08:15,999, >ru_GetVarsFromFTPlogFile<: HWSubRevision = 3
24.09.2015, 19:08:15,999, >ru_GetVarsFromFTPlogFile<: annex = B
24.09.2015, 19:08:15,999, >ru_GetVarsFromFTPlogFile<: autoload = yes
24.09.2015, 19:08:16,014, >ru_GetVarsFromFTPlogFile<: bootloaderVersion = 1.947
24.09.2015, 19:08:16,014, >ru_GetVarsFromFTPlogFile<: bootserport = tty0
24.09.2015, 19:08:16,014, >ru_GetVarsFromFTPlogFile<: cpufrequency = 500000000
24.09.2015, 19:08:16,030, >ru_GetVarsFromFTPlogFile<: firmware_info = 84.06.23
24.09.2015, 19:08:16,030, >ru_GetVarsFromFTPlogFile<: firmware_version = avm
24.09.2015, 19:08:16,030, >ru_GetVarsFromFTPlogFile<: firstfreeaddress = 0x810C9834
24.09.2015, 19:08:16,030, >ru_GetVarsFromFTPlogFile<: flashsize = 0x01000000
24.09.2015, 19:08:16,046, >ru_GetVarsFromFTPlogFile<: maca = 24:65:11:5A:BA:25
24.09.2015, 19:08:16,046, >ru_GetVarsFromFTPlogFile<: macb = 24:65:11:5A:BA:26
24.09.2015, 19:08:16,046, >ru_GetVarsFromFTPlogFile<: macdsl = 24:65:11:5A:BA:28
24.09.2015, 19:08:16,046, >ru_GetVarsFromFTPlogFile<: macwlan = 24:65:11:5A:BA:27
24.09.2015, 19:08:16,046, >ru_GetVarsFromFTPlogFile<: macwlan2 = 24:65:11:5A:BA:2B
24.09.2015, 19:08:16,061, >ru_GetVarsFromFTPlogFile<: memsize = 0x08000000
24.09.2015, 19:08:16,061, >ru_GetVarsFromFTPlogFile<: modetty0 = 38400,n,8,1,hw
24.09.2015, 19:08:16,061, >ru_GetVarsFromFTPlogFile<: modetty1 = 38400,n,8,1,hw
24.09.2015, 19:08:16,061, >ru_GetVarsFromFTPlogFile<: mtd1 = 0x9F020000,0x9FF00000
24.09.2015, 19:08:16,077, >ru_GetVarsFromFTPlogFile<: mtd2 = 0x9F000000,0x9F020000
24.09.2015, 19:08:16,077, >ru_GetVarsFromFTPlogFile<: mtd3 = 0x9FF00000,0x9FF80000
24.09.2015, 19:08:16,077, >ru_GetVarsFromFTPlogFile<: mtd4 = 0x9FF80000,0xA0000000
24.09.2015, 19:08:16,092, >ru_GetVarsFromFTPlogFile<: my_ipaddress = 192.168.178.1
24.09.2015, 19:08:16,092, >ru_GetVarsFromFTPlogFile<: req_fullrate_freq = 166666666
24.09.2015, 19:08:16,092, >ru_GetVarsFromFTPlogFile<: prompt = Eva_AVM
24.09.2015, 19:08:16,108, >ru_GetVarsFromFTPlogFile<: SerialNumber = 0000000000000000
24.09.2015, 19:08:16,108, >ru_GetVarsFromFTPlogFile<: sysfrequency = 166666666
24.09.2015, 19:08:16,108, >ru_GetVarsFromFTPlogFile<: tr069_passphrase =
24.09.2015, 19:08:16,124, >ru_GetVarsFromFTPlogFile<: tr069_serial =
24.09.2015, 19:08:16,124, >ru_GetVarsFromFTPlogFile<: urlader-version = 1947
24.09.2015, 19:08:16,124, >ru_GetVarsFromFTPlogFile<: usb_board_mac = 24:65:11:5A:BA:29
24.09.2015, 19:08:16,124, >ru_GetVarsFromFTPlogFile<: usb_device_id = 0x0000
24.09.2015, 19:08:16,139, >ru_GetVarsFromFTPlogFile<: usb_manufacturer_name = AVM
24.09.2015, 19:08:16,139, >ru_GetVarsFromFTPlogFile<: usb_revision_id = 0x0000
24.09.2015, 19:08:16,139, >ru_GetVarsFromFTPlogFile<: usb_rndis_mac = 24:65:11:5A:BA:2A
24.09.2015, 19:08:16,155, >ru_GetVarsFromFTPlogFile<: wlan_key =
24.09.2015, 19:08:16,186, >ru_UpDownToFile<:
Box-Informationen:
ProductID: Fritz_Box_7390
HWRevision: 156
HWSubRevision: 3
annex: B
autoload: yes
bootloaderVersion: 1.947
bootserport: tty0
cpufrequency: 500000000
firmware_info: 84.06.23
firmware_version: avm
firstfreeaddress: 0x810C9834
flashsize: 0x01000000
maca: 24:65:11:5A:BA:25
macb: 24:65:11:5A:BA:26
macdsl: 24:65:11:5A:BA:28
macwlan: 24:65:11:5A:BA:27
macwlan2: 24:65:11:5A:BA:2B
memsize: 0x08000000
modetty0: 38400,n,8,1,hw
modetty1: 38400,n,8,1,hw
mtd1: 0x9F020000,0x9FF00000
mtd2: 0x9F000000,0x9F020000
mtd3: 0x9FF00000,0x9FF80000
mtd4: 0x9FF80000,0xA0000000
my_ipaddress: 99.88.77.1
req_fullrate_freq: 166666666
prompt: Eva_AVM
SerialNumber: 0000000000000000
sysfrequency: 166666666
tr069_passphrase:
tr069_serial:
urlader-version: 1947
usb_board_mac: 24:65:11:5A:BA:29
usb_device_id: 0x0000
usb_manufacturer_name: AVM
usb_revision_id: 0x0000
usb_rndis_mac: 24:65:11:5A:BA:2A
wlan_key:
24.09.2015, 19:08:16,248, >ru_UpDownToFile<:
Flash-/Speichergrößen:
Flashsize: 16.777.216 Bytes (16.384 kB, 16 MB)
Memsize: 134.217.728 Bytes (131.072 kB, 128 MB, 0,1 GB)
mtd1: 15.597.568 Bytes (15.232 kB, 14,9 MB)
mtd2: 131.072 Bytes (128 kB, 0,1 MB)
mtd3: 524.288 Bytes (512 kB, 0,5 MB)
mtd4: 524.288 Bytes (512 kB, 0,5 MB)
24.09.2015, 19:08:16,295, >ru_UpDownToFile<:
ProductID: Fritz_Box_7390
HW-Revision: 156 => FRITZ!Box Fon WLAN 7390
24.09.2015, 19:08:16,295, >ru_CheckFirmwareVersion<: Firmware-Version: >84.06.23<
24.09.2015, 19:08:16,326, >ru_UpDownToFile<:

6) Firmware-Transfer, clear mtd3+4, Einstellungen vornehmen:

24.09.2015, 19:08:16,342, >ru_UpDownToFile<:
A c h t u n g:

Bitte etwas Geduld! Die Datenübertragung dauert!
Nicht ausstecken und auch nicht unterbrechen!

24.09.2015, 19:08:16,373, >ru_UpDownToFile<:
Eintrag aus der Flash-Speed-Datenbank (ungefähre Werte!):
ProductID: Fritz_Box_7390
Übertragungsrate: 90.000 Bytes/sec
Kernel-Übertragung: 169 Sekunden
Clear MTD3: 23 Sekunden
Clear MTD4: 22 Sekunden
Settings+Neustart: 3 Sekunden
Gesamtzeit: 217 Sekunden
24.09.2015, 19:08:16,389, >ru_UpDownToFile<:
Kernel- und mtd1-Größenüberprüfung:
kernel.image-Größe: 15.254.644 Bytes (14.897,1 kB, 14,5 MB)
mtd1-Größe: 15.597.568 Bytes (15.232 kB, 14,9 MB)
freier Platz danach in mtd1: 342.924 Bytes (334,9 kB, 0,3 MB)
24.09.2015, 19:08:16,420, >ru_UpDownToFile<:
kernel_aus_FRITZ.Box_7390.Int.84.05.23.image übertragen...
24.09.2015, 19:08:16,420, >ru_Upload<: Upload mtd1...
24.09.2015, 19:09:51,315, >ru_Upload<: kernel: kernel_aus_FRITZ.Box_7390.Int.84.05.23.image
24.09.2015, 19:09:51,315, >ru_Upload<: Verbrauchte Ticks: 94605
24.09.2015, 19:09:51,315, >ru_Upload<: File-Größe: 15254644
24.09.2015, 19:09:51,315, >ru_Upload<: Bytes pro Sekunde: 161245.6
24.09.2015, 19:09:51,377, >ru_UpDownToFile<: überprüfen...
24.09.2015, 19:09:51,393, >ru_CheckFTPlogFile<: Kernel-Übertragung-LogFile: Suchstring1 "226: Transfer complete" konnte nicht im Array gefunden werden
24.09.2015, 19:09:51,424, >ru_UpDownToFile<: gescheitert!
24.09.2015, 19:09:51,455, >ru_UpDownToFile<:
Das kernel.image konnte nicht übertragen werden!​

 

[DieWilde13]

Sorry, habe mich wohl falsch ausgedrückt. Peter (und ich) möchten gern den WireShark-Mitschnitt, wenn Du das originale AVM Recovery-Programm laufen lässt.

 

[furacer]

Ok mache ich

 

[informerex]

bescheidene Frage, warum wurde noch immer kein Werksreset per Telefoncode durchgeführt? (mindestens jedoch bitte mal die tr069 codes entfernt/editiert)

des weiteren warum wird eine FRITZ.Box_7390.Int.84.05.23.image verwendet, wenn es eine dt.-Box ist?

 

[furacer]

Hallo,

hier ist der Mitschnitt von Wireshark beim AVM Recovery Tool beim letzten Fehler:


Die Gesamte Datei ist auch gezipt >8MB (ich habe auch erst aufgezeichnet als ich das Programm gestartet habe), d.h. ich kann die nicht ohne weiteres anhängen...

 

[furacer]

bescheidene Frage, warum wurde noch immer kein Werksreset per Telefoncode durchgeführt? (mindestens jedoch bitte mal die tr069 codes entfernt/editiert)

Hallo was empfiehlst du mir um die tr069 codes zu entfernen/editieren?