Fritzbox 7490 recovery funktioniert nicht

I did this TCP stream, the results are... well.. not what I expected...

Code:
323230204144414d3220465450205365727665722072656164790d0a

55534552206164616d320d0a
3333312050617373776f726420726571756972656420666f72206164616d320d0a
50415353206164616d320d0a
3233302055736572206164616d32207375636365737366756c6c79206c6f6767656420696e0d0a
535953540d0a
3231352041564d204556412056657273696f6e20312e3139363420307830203078373430440d0a
474554454e56206d656d73697a650d0a
6d656d73697a65202020202020202020202020202020307831303030303030300d0a0d0a32303020474554454e5620636f6d6d616e64207375636365737366756c0d0a
534554454e56206d656d73697a6520307830363761356630300d0a
32303020534554454e5620636f6d6d616e64207375636365737366756c0d0a
534554454e56206b65726e656c5f617267735f746d70206d746472616d313d307838363761356630302c307838383030303030300d0a
32303020534554454e5620636f6d6d616e64207375636365737366756c0d0a
5459504520490d0a
32303020547970652073657420746f2042494e4152590d0a
4d4544494120534452414d0d0a
323030204d656469612073657420746f204d454449415f534452414d0d0a
504053570d0a
32323720456e746572696e672050617373697665204d6f646520283139322c3136382c3137382c312c31322c32290d0a
53544f52203078383637613566303020307838383030303030300d0a
313530204f70656e696e672042494e415259206461746120636f6e6e656374696f6e0d0a
35353320457865637574696f6e206661696c65642e0d0a
534554454e56206d656d73697a65203078307831303030303030300d0a
32303020534554454e5620636f6d6d616e64207375636365737366756c0d0a
554e534554454e56206b65726e656c5f617267735f746d700d0a
35303120656e7669726f6e6d656e74207661726961626c65206e6f74207365740d0a
515549540d0a
323231205468616e6b20796f7520666f72207573696e6720746865204654502073657276696365206f6e204144414d320d0a32323120476f6f646279652e0d0a
In more readable ascii:
Code:
220 ADAM2 FTP Server ready
USER adam2
331 Password required for adam2
PASS adam2
230 User adam2 successfully logged in
SYST
215 AVM EVA Version 1.1964 0x0 0x740D
GETENV memsize
memsize               0x10000000

200 GETENV command successful
SETENV memsize 0x067a5f00
200 SETENV command successful
SETENV kernel_args_tmp mtdram1=0x867a5f00,0x88000000
200 SETENV command successful
TYPE I
200 Type set to BINARY
MEDIA SDRAM
200 Media set to MEDIA_SDRAM
P@SW
227 Entering Passive Mode (192,168,178,1,12,2)
STOR 0x867a5f00 0x88000000
150 Opening BINARY data connection
553 Execution failed.
SETENV memsize 0x0x10000000
200 SETENV command successful
UNSETENV kernel_args_tmp
501 environment variable not set
QUIT
221 Thank you for using the FTP service on ADAM2
221 Goodbye.

I've also tried to upload the image with my linux computer with this command run from the eva_tools folder.

Code:
bash eva_to_memory ToTest.img 192.168.178.1

But this line just get stuck with no further info. The log file remains empty
 
You've selected the wrong connection to follow ... this one is the "control connection" used to send commands to the device and to receive its answers. For data transmissions, additional connections are used - re-check your packet dump for a connection to 192.168.178.1 on port 3074 (computed from (12 * 256) + 2 according to the 227 answer).
 
Since I didn't fully understand you I checked all the TCP connections. There are 2 types. One as mentioned above and an other one, who's so huge that wireshark just get stuck itself. I've to escape with ctrl + alt + del

I also don't see how wireshark can bring me closer to a solution. It's clear that the FB refuses any new image.
I'm starting to think on giving up and buy a new one. At least now I know how to install an other firmware.
 
Zuletzt bearbeitet:
I also don't see how wireshark can bring me closer to a solution.
That's correct ... if the transmission from your host to the box isn't the cause of your problem, you will not see anything weird in the packet dump.

But if the data is received without error by the box, it becomes even more mysterious, why the image will not be booted.

What should be the root of an error, where the bootloader is able to communicate with a FTP client without any problem, but still isn't able to unpack and start the uploaded image? I'm puzzled - and the only way to find the reason and - possibly - a solution I might imagine, is a step by step check of each possible point of failure.

As I wrote above, you have to use the legacy version of Wireshark ... even my Wireshark 2 installation was unable to collect all packets, too.

But I'm absolutely satisfied, if you want to stop here ... my own interest was certitude, that my scripts work as expected and due to my parallel actions I may summarize: They do.

Good luck ...
 
Hello everybody,

I decided to give up. Since I see my changes on recovering this one on myself almost as nothing. Thank you all for your support and patience. It has been a ride and a learned a lot.
Since I was planning to install an openVPN client on the FB, this knowledge can be handy.

thanks!
 
Aus unbekannter Quelle ist mir eine optisch neuwertige 7490 von 2016 zugeflogen. Sie startet nur im Bootloop.

Das Recovery-Tool meldet:

FRITZ!Box 7490 suchen an: 169.254.151.1
Eine Anlage gefunden! - Ermitteln der aktuellen Version.
Version erfolgreich ermittelt!
Hardware: FRITZ!Box 7490
Urlader: 1964
Firmware:
Flashbereich (mtd3)
Lösche Flashbereich (mtd3)
Restauriere Flashbereich (mtd3)
Recover der Partition mtd3 fehlgeschlagen! WinError -3


Ist da noch was zu retten?
 
Erstmal PeterPawns eva_discover Script drüberlaufen lassen, um den status-quo zu eruieren. Die Vergabe einer festen IP 192.168.178.2 Gateway 192.168.178.1 könnte auch ein Hint sein, neben Firewall -Deaktivierung.
LG
 
Was sagt denn das FTP-Protokoll des Recovery-Programms? Wenn das Environment gelesen werden kann, was steht da konkret drin?

Im erwähnten Protokoll sollte man dann auch den Upload-Versuch für die erste TFFS-Partition sehen können und wie die Box darauf reagiert.

Komplett defekt kann der SPI-Flash nicht sein, wenn der Bootloader noch arbeitet (und damit noch gelesen werden kann).
 
  • Like
Reaktionen: diet59
Das eva_discover Script läßt PowerShell kurz aufpoppen und wieder schließen.
 
Das irritiert mich schon etwas - eva_discover ist ein (Linux-)Shell-Skript und wäre im Zusammenhang mit der (Windows-)PowerShell schon recht seltsam eingesetzt und - falls das doch mit PS unter Linux versucht wurde - meinerseits weder getestet noch beabsichtigt.

Aber darum ging es in #48 ja ohnehin nicht … und wie immer ist das alles ohne die passenden Protokolle nur Stochern im Nebel. Und ganz ehrlich - das "Vorzeigen" dieser Informationen tut gar nicht weh und spart jede Menge anderen Aufwand. Also ganz klar eine "Entweder-Oder"-Situation …
 
  • Like
Reaktionen: diet59
Linux ist für mich leider fremdes Land.

Wo finde ich das FTP-Protokoll?
 
  • Like
Reaktionen: diet59
0:04:107: 2.02 fca279e
0:04:107: Registry: SYSTEM\CurrentControlSet\Services\TcpIp\Parameters\DisableDHCPMediaSense=0
0:04:107: recover-firmware-id: 185
0:04:107: recover-firmware-version: 113.07.59
0:04:423: check adapter(Realtek PCIe GbE Family Controller) adapter 0x3: Ip: 169.254.151.13(255.255.0.0) (dhcp)
0:04:423: check adapter(Intel(R) Centrino(R) Wireless-N 1000) adapter 0x13: Ip: 192.168.178.85(255.255.255.0) (dhcp)
0:04:423: dhcp-adapter (3) with ip 169.254.151.13 found: first choice
0:04:457: search on addr: 169.254.151.1
0:04:887: ---> read environment <---
0:05:000: open ftp 169.254.151.1 port 21
0:05:015: recv: 220 ADAM2 FTP Server ready
0:05:015: send: USER adam2
0:05:015: recv: 331 Password required for adam2
0:05:015: send: PASS adam2
0:05:015: recv: 230 User adam2 successfully logged in
0:05:015: send: SYST
0:05:015: recv: 215 AVM EVA Version 1.1964 0x0 0x740D
0:05:015: send: TYPE I
0:05:015: recv: 200 Type set to BINARY
0:05:015: send: MEDIA SDRAM
0:05:015: recv: 200 Media set to MEDIA_SDRAM
0:05:015: send: P@SW
0:05:015: recv: 227 Entering Passive Mode (169,254,151,1,12,7)
0:05:015: open ftp data 169.254.151.1 port 3079
0:05:047: send: RETR env
0:05:047: recv: 150 Opening BINARY data connection
0:05:109: recv: 226 Transfer complete
0:05:222: payload successfully read(1404 bytes)
0:05:222: send: USER adam2
0:05:222: recv: 331 Password required for adam2
0:05:222: send: PASS adam2
0:05:222: recv: 230 User adam2 successfully logged in
0:05:222: send: SYST
0:05:222: recv: 215 AVM EVA Version 1.1964 0x0 0x740D
0:05:222: send: TYPE I
0:05:222: recv: 200 Type set to BINARY
0:05:222: send: MEDIA SDRAM
0:05:222: recv: 200 Media set to MEDIA_SDRAM
0:05:222: send: P@SW
0:05:222: recv: 227 Entering Passive Mode (169,254,151,1,12,11)
0:05:222: open ftp data 169.254.151.1 port 3083
0:05:238: send: RETR count
0:05:238: recv: 150 Opening BINARY data connection
0:05:285: recv: 226 Transfer complete
0:05:397: payload successfully read(150 bytes)
0:05:397: send: BYE
0:05:397: recv: 221 Thank you for using the FTP service on ADAM2
0:05:397: hardware-revision: 185
0:05:397: firmware-version:
0:05:397: urloader-version: 1.1964
0:05:397: oem: avm
0:05:397: provider:
0:06:023: set defaultsettings mtd3 (size: zu)
0:06:023: ---> write image (mtd3) <---
0:06:134: open ftp 169.254.151.1 port 21
0:06:165: recv: 220 ADAM2 FTP Server ready
0:06:165: send: USER adam2
0:06:165: recv: 331 Password required for adam2
0:06:165: send: PASS adam2
0:06:165: recv: 230 User adam2 successfully logged in
0:06:165: send: SYST
0:06:165: recv: 215 AVM EVA Version 1.1964 0x0 0x740D
0:06:165: send: TYPE I
0:06:165: recv: 200 Type set to BINARY
0:06:165: send: MEDIA FLSH
0:06:165: recv: 200 Media set to MEDIA_FLASH
0:06:165: send: P@SW
0:06:165: recv: 227 Entering Passive Mode (169,254,151,1,12,1)
0:06:165: open ftp data 169.254.151.1 port 3073
0:06:196: clear flash-partition (mtd3)
0:09:587: send: STOR mtd3
0:09:587: recv: 150 Opening BINARY data connection
0:09:587: flash clear (mtd3) ok : now send image
0:09:692: update flash-partition (mtd3)
0:09:708: send image (size=393216) for mtd3
0:09:723: recv: 426 Data connection closed
0:09:723: flash error 426 Data connection closed
0:09:817: error (write image): -3
0:09:817: error on defaultsettings (mtd3)
0:09:926: exit: errorcode=-3
0:09:926: ----EOF---

HWRevision 185
HWSubRevision 6
ProductID Fritz_Box_HW185
SerialNumber 0000000000000000
annex B
autoload yes
bootloaderVersion 1.1964
bootserport tty0
cpufrequency 500000000
firstfreeaddress 0x81116240
firmware_version avm
flashsize nor_size=0MB sflash_size=1024KB nand_size=512MB
maca 38:10:D5:5E:1F:3D
macb 38:10:D5:5E:1F:3E
macwlan 38:10:D5:5E:1F:3F
macwlan2 38:10:D5:5E:1F:40
macdsl 38:10:D5:5E:1F:41
memsize 0x10000000
modetty0 38400,n,8,1,hw
modetty1 38400,n,8,1,hw
mtd0 0x400000,0x3400000
mtd1 0x0,0x400000
mtd2 0x0,0x40000
mtd3 0x40000,0xA0000
mtd4 0xA0000,0x100000
mtd5 0x0,0x200000
my_ipaddress 169.254.151.1
prompt Eva_AVM
req_fullrate_freq 250000000
sysfrequency 250000000
tr069_passphrase 7xXpuZN6uPVq
tr069_serial 00040E-3810D55E1F3D
urlader-version 2964
usb_board_mac 38:10:D5:5E:1F:42
usb_device_id 0x0000
usb_manufacturer_name AVM
usb_revision_id 0x0000
usb_rndis_mac 38:10:D5:5E:1F:43
wlan_key 30916699963104464833
 
0:09:708: send image (size=393216) for mtd3
0:09:723: recv: 426 Data connection closed
0:09:723: flash error 426 Data connection closed
Das Environment sieht normal aus und auch so, als wäre es das Ergebnis eines vorhergehenden Recovery-Vorgangs (es fehlen u.a. die Werte für linux_fs_start und firmware_info, die beim Start des FRITZ!OS bzw. beim Firmware-Update entstehen).

Aus dem FTP-Log geht immerhin hervor, daß die Box der Ansicht ist, der PC hätte die Datenverbindung unerwartet nach 15 ms geschlossen - und das, ohne Daten in dieser Verbindung zu übertragen (wenn Daten geflossen wären, hätte der Bootloader den Inhalt nicht beurteilen können oder wollen).

Wenn ich raten müßte, würde ich hier auf irgendeine "security suite" tippen, die gerne in per FTP übertragene Daten hineinschauen möchte (das machen manche so, um die Übertragung sensibler Daten auf diesem Weg zu blockieren) und dabei die Verbindung (anstelle des Recovery-Programms) aus irgendeinem Grund schließt.

Da sich derartige Software häufig sehr, sehr tief ins System einklinkt, hilft es oft auch nicht, wenn man diese vorübergehend deaktiviert (auch wenn man es zumindest mal versuchen kann) - dann bliebe noch ein anderes System OHNE diese Software als Alternative (hoffentlich ist es nicht gleich eine "family license" und das Schlangenöl findet sich auf allen Geräten) oder man startet sein (Windows-)System im "abgesicherten Modus", wo diese Software dann ebenfalls inaktiv sein sollte.

Kann hier DEFINITIV ausgeschlossen werden, daß Schlangenöl die Ursache ist, könnte man sich noch den Netzwerk-Verkehr genauer ansehen (z.B. mit WireShark), um vollkommen sicherzugehen, daß da tatsächlich keine Daten in der (FTP-Daten-)Verbindung übertragen werden und wer die Kommunikation beendet.

Je nachdem, was bei diesen Zwischenschritten herauskommt, kann/muß man dann weitersehen - ich würde die Box jedenfalls noch nicht abschreiben nach den bisherigen Ergebnissen.
 
  • Like
Reaktionen: diet59
Derart Schlangenöl kann ich ausschließen, habe und hatte ich nie drauf.

Mit neueren PCs wird die Box in der Recovery nicht gefunden, nur mit einem alten PC mit 54 Mbit-LAN.
Dann aber auch nicht sofort nach dem Bestromen, sondern erst in einer bestimmten Phase des Bootloops.
Wenn die Verbindung da ist, hört der Bootloop auf und die Power-LED blinkt dauerhaft.
 
Was bitte soll ein 54 Mbit-LAN sein?
Gibts neben 10/100M und 1/2,5/5/10 Gb/s im Hausgebrauch noch andere Standards?
54 gibts doch nur beim WLAN ...
 
54 Mbit war eine Schätzung, kann auch 10/100 Mbit sein, jedenfalls langsamer als mit neueren PCs, wo es gar nicht geht.
Verschiedene LAN-Kabel habe ich probiert - ohne Unterschied.
OS war 1x win10-32 22H2 und 2x win11-64 23H2 auf einem PC (Multiboot).
Das Ergebnis war bei allen das gleiche, ebenso wenn ich einen USB-LAN-Adapter (auch Realtek) verwende.
Mit dem Adapter geht es aber auch bei neueren PCs nicht.
 
Bitte die Anleitung für richtiges Recovery beachten, insbesondere
- Geschwindigkeit des mit der Recovery-Box verbundenen Netzwerkadapters (100 MBit/s ist die Boot-Geschwindigkeit, oder?)
- IP-Adresse des Netzwerkadapters (im obigen Fall aufgrund von my_ipaddress 169.254.151.1 also 169.254.151.2 oder höher)
- MediaSensing abschalten, (Netzwerk-Adapter ist dann dauerhaft aktiv anstatt auf Verbindung zu warten)
- Nur *eine* FritzBox (die zu recovernde) im Netzwerk - alle AVM-Boxen haben werksseitig dieselben Arbeits- und Notfall-IP-Adressen

Den PC an LAN1 anschließen. Es gibt Berichte, daß LAN2 und LAN3 auch funktionieren. Da LAN4 vom internen LAN entkoppelt werden kann (Gastzugang), funktioniert an diesem Port das Recovery möglicherweise nicht.

Nach erfolgreichem Recovery ist die IP-Adresse der Box evtl. auf Werkseinstellungen gesetzt (192.168.178.1), d.h. die IP-Adresse des Netzwerkadapters muss entsprechend geändert oder wieder auf DHCP gesetzt werden.
 
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.