[Frage] 6490 Cable debranding

Nein, die Tools machen alle das gleichem, die Flash Vorgänge wurden in allen Fällen erfolgreich abgeschlossen.
Vielen Dank für den Link zur Anleitung.
 
Wie sieht denn die Ausgabe von
Code:
 quote GETENV firmware_version
aus, wenn Du Dich per FTP in adam2 eingeloggt hast?
 
quote GETENV firmware_version
firmware_version avm
200 GETENV command successful
 
Solange die Box auf ARP-Requests im Bootloader korrekt antwortet, ist es jedenfalls schon mal nicht das Problem mit gelöschten TFFS-Partitionen nach dem Schreiben "leerer" Images nach MTD3 oder MTD4 - das trat ohnehin nur bei einer bestimmten Bootloader-Version auf (auch wenn die ziemlich verbreitet war in 2016), iirc.

Das Auslesen des Environments kann aber grundsätzlich(!) nicht schaden und wenn man zuvor mal ein "falsches" Recovery-Programm von AVM verwendet hat, um EVA zu umwerben, wurde dabei i.d.R. auch das vom Recovery-Programm ausgelesene Environment (bis zu 20 davon werden gespeichert, siehe Recovery-Thread hier irgendwo) auf dem verwendeten PC abgelegt.

Damit kann man dann den neuen Stand vergleichen (so es solch ein älteres File gibt), ob es da tatsächlich (bzw. eher überhaupt) Unterschiede gibt. Ist das nicht der Fall, ist ein komplettes neues TFFS-Image für MTD3/MTD4 eher nur eine Sackgasse.

Ich tippe weiterhin auf Abweichungen beim Flashen der richtigen(!) Daten in die jeweiligen Partitionen - ein entsprechendes Protokoll wäre hilfreich, wenn man mich vom Gegenteil und "ich mache aber alles richtig" überzeugen will.

Komplett meint dabei "mit alles" - angefangen beim Auslesen und Anzeigen des aktuellen Environments (und nicht nur einzelner Werte mit GETENV, was mit "normalen" FTP-Clients bekanntlich ohnehin Späne machen kann, weil die (positiven) Ausgaben der Box nicht dem FTP-Protokoll für mehrzeilige Antworten entsprechen) über das Entpacken der AVM-Firmware bis zum Flashen der Images in die passenden Partitionen, das natürlich mögllchst auch erfolgreich sein und ohne irgendwelche Fehlermeldungen quittiert werden sollte.

Startet die Box dann immer noch nicht, wäre eine deutlich genauere Beschreibung sehr hilfreich … die 10 Sekunden Erreichbarkeit für Pings habe ich gelesen - nur ist die Angabe "wenn die Box nun hochfährt" höchst "ambiguous", solange da nichts steht, wann dieses "Hochfahren" nun eigentlich beginnt.

Das kann ja sowohl der Bootloader sein, der da antwortet oder das startende System - irgendwann hat AVM bei den Puma6-Firmwares mal einen "killswitch" eingebaut, der die Box dann wieder neu startete, wenn die installierte Firmware nicht zu den in der Bootloader-Konfiguration hinterlegten Angaben paßte.
 
Das klingt vielversprechend, ich versuche mal so ein image zu erstellen.
Besten dank für den konstruktiven hinweis.


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.2411 0x0 0x36409





================


DEBUG: Sent


TYPE I


================


DEBUG: Response:


200 Type set to BINARY





================


DEBUG: Sent


MEDIA SDRAM


================


DEBUG: Response:


200 Media set to MEDIA_SDRAM





================


DEBUG: Sent


P@SW


================


DEBUG: Response:


227 Entering Passive Mode (192,168,178,1,54,69)





================


DEBUG: Sent


RETR env


================


DEBUG: Response:


150 Opening BINARY data connection


226 Transfer complete





================



HWRevision 213


SerialNumber 0000000000000000


annex Kabel


autoload yes


bootloaderVersion 1.2411


bootserport tty0


cpufrequency 1200000000


firstfreeaddress 0x00b20000


firmware_info 141.07.57


flashsize nor_size=0MB sflash_size=2MB nand_size=2048MB


maca 00:04:0E:FF:FF:01


macb 00:04:0E:FF:FF:02


macwlan 00:04:0E:FF:FF:03


macdsl 00:04:0E:FF:FF:04


memsize 0x10000000


modetty0 38400,n,8,1,hw


modetty1 38400,n,8,1,hw


mtd0 0x0,0x4000000


mtd1 0x4000000,0x4800000


mtd2 0xa0000,0xc0000


mtd3 0xc0000,0x100000


mtd4 0x100000,0x140000


mtd5 0x140000,0x1e0000


mtd6 0x4800000,0x8800000


mtd7 0x8800000,0x9000000


mtd8 0x0,0x80000


mtd9 0x80000,0x90000


mtd10 0x90000,0xa0000


mtd11 0x9000000,0xd000000


mtd12 0xd000000,0xd800000


mtd13 0xd800000,0x11800000


mtd14 0x11800000,0x12000000


my_ipaddress 192.168.178.1


prompt Eva_AVM


req_fullrate_freq 100000000


sysfrequency 100000000


urlader-version 3411


usb_board_mac 00:04:0E:FF:FF:05


usb_rndis_mac 00:04:0E:FF:FF:06
 
Danach habe ich nochmal ein paar werte korrigiert und neu gesetzt:

quote SETENV firmware_version avm
quote SETENV maca C8:0E:14:92:EC:67
quote SETENV macb C8:0E:14:92:EC:68
quote SETENV macwlan C8:0E:14:92:EC:69
quote SETENV macdsl C8:0E:14:92:EC:6A
quote SETENV linux_fs_start 0
quote SETENV autoload yes
quote REBOOT

Neues Ergebnis:

HWRevision 213
SerialNumber 0000000000000000
annex Kabel
autoload yes
bootloaderVersion 1.2411
bootserport tty0
cpufrequency 1200000000
firstfreeaddress 0x00b20000
firmware_info 141.07.57
firmware_version avm
flashsize nor_size=0MB sflash_size=2MB nand_size=2048MB
linux_fs_start 0
maca C8:0E:14:92:EC:67
macb C8:0E:14:92:EC:68
macwlan C8:0E:14:92:EC:69
macdsl C8:0E:14:92:EC:6A
memsize 0x10000000
modetty0 38400,n,8,1,hw
modetty1 38400,n,8,1,hw
mtd0 0x0,0x4000000
mtd1 0x4000000,0x4800000
mtd2 0xa0000,0xc0000
mtd3 0xc0000,0x100000
mtd4 0x100000,0x140000
mtd5 0x140000,0x1e0000
mtd6 0x4800000,0x8800000
mtd7 0x8800000,0x9000000
mtd8 0x0,0x80000
mtd9 0x80000,0x90000
mtd10 0x90000,0xa0000
mtd11 0x9000000,0xd000000
mtd12 0xd000000,0xd800000
mtd13 0xd800000,0x11800000
mtd14 0x11800000,0x12000000
my_ipaddress 192.168.178.1
prompt Eva_AVM
req_fullrate_freq 100000000
sysfrequency 100000000
urlader-version 3411
usb_board_mac 00:04:0E:FF:FF:05
usb_rndis_mac 00:04:0E:FF:FF:06

Hänge aber immernoch in der BootLoop
 
Warum fummelst Du an den MAC Adressen herum?
Führt dazu, dass die DOCSIS Zertifikate nicht mehr passen...
 
Hatte mal ein leeres image geflasht, was dazu geführt hat das die Box auf die Standardadresse zurück fällt.
Das ist jetzt wieder die Adresse die hinten auf dem Aufkleber aufgedruckt ist.
 
Die USB-Adressen sollten Imho auch korrigiert werden?
Zitat: Hatte mal ein leeres image geflasht,..

Das klingt nicht so gut
 
Aufgedruckt ist nur die CM MAC, die anderen werden wohl nur um eins hinten hochgezält.
Muss ich für die USB-Adressen einfach nur weiter hochzählen?
 
Die Syntax für alle Adressen habe ich nicht im Kopf. Einige werden von der CM-MAC aus hoch, andere heruntergezählt iirc. Am besten anhand einer Supportdatei von einer intakten Box - kann auch ein anderes Modell sein imho- ausknobeln.
Edit: Korrigiert
 
Zuletzt bearbeitet:
Zuletzt bearbeitet:
So falsch war deine Aussage nicht, die 7530 AX Typ A hat beispielsweise noch denselben Aufbau wie meine 6490, aber es gibt eben Abweichungen bei neueren Boxen und bei Boxen mit abweichendem Funktionsumfang...
 
  • Like
Reaktionen: Micha0815
Solange die Box auf ARP-Requests im Bootloader korrekt antwortet, ist es jedenfalls schon mal nicht das Problem mit gelöschten TFFS-Partitionen nach dem Schreiben "leerer" Images nach MTD3 oder MTD4 - das trat ohnehin nur bei einer bestimmten Bootloader-Version auf (auch wenn die ziemlich verbreitet war in 2016), iirc.

Das Auslesen des Environments kann aber grundsätzlich(!) nicht schaden und wenn man zuvor mal ein "falsches" Recovery-Programm von AVM verwendet hat, um EVA zu umwerben, wurde dabei i.d.R. auch das vom Recovery-Programm ausgelesene Environment (bis zu 20 davon werden gespeichert, siehe Recovery-Thread hier irgendwo) auf dem verwendeten PC abgelegt.

Damit kann man dann den neuen Stand vergleichen (so es solch ein älteres File gibt), ob es da tatsächlich (bzw. eher überhaupt) Unterschiede gibt. Ist das nicht der Fall, ist ein komplettes neues TFFS-Image für MTD3/MTD4 eher nur eine Sackgasse.

Ich tippe weiterhin auf Abweichungen beim Flashen der richtigen(!) Daten in die jeweiligen Partitionen - ein entsprechendes Protokoll wäre hilfreich, wenn man mich vom Gegenteil und "ich mache aber alles richtig" überzeugen will.

Komplett meint dabei "mit alles" - angefangen beim Auslesen und Anzeigen des aktuellen Environments (und nicht nur einzelner Werte mit GETENV, was mit "normalen" FTP-Clients bekanntlich ohnehin Späne machen kann, weil die (positiven) Ausgaben der Box nicht dem FTP-Protokoll für mehrzeilige Antworten entsprechen) über das Entpacken der AVM-Firmware bis zum Flashen der Images in die passenden Partitionen, das natürlich mögllchst auch erfolgreich sein und ohne irgendwelche Fehlermeldungen quittiert werden sollte.

Startet die Box dann immer noch nicht, wäre eine deutlich genauere Beschreibung sehr hilfreich … die 10 Sekunden Erreichbarkeit für Pings habe ich gelesen - nur ist die Angabe "wenn die Box nun hochfährt" höchst "ambiguous", solange da nichts steht, wann dieses "Hochfahren" nun eigentlich beginnt.

Das kann ja sowohl der Bootloader sein, der da antwortet oder das startende System - irgendwann hat AVM bei den Puma6-Firmwares mal einen "killswitch" eingebaut, der die Box dann wieder neu startete, wenn die installierte Firmware nicht zu den in der Bootloader-Konfiguration hinterlegten Angaben paßte.
 
1. Ich habe die 7.57 von der AVM Webseite heruntergeladen.
2. .image datei auf einem mac in in .tar umbenannt.
3. .tar datei mit einem doppeklick im Finder entpackt

Fritzbox mit Kabel über LAN1 direkt an dem Mac verbunden.

Auf dem Mac:
lftp -u adam2,adam2 192.168.178.1

in lftp:
set ftp:passive-mode yes

quote TYPE I
quote MEDIA FLSH

put /Users/johannes/Desktop/var/remote/var/tmp/filesystem.image -o mtd0
put /Users/johannes/Desktop/var/remote/var/tmp/filesystem.image -o mtd11
put /Users/johannes/Desktop/var/remote/var/tmp/kernel.image -o mtd1
put /Users/johannes/Desktop/var/remote/var/tmp/kernel.image -o mtd12

put /Users/johannes/Desktop/var/remote/var/tmp/x86/filesystem.image -o mtd6
put /Users/johannes/Desktop/var/remote/var/tmp/x86/filesystem.image -o mtd13
put /Users/johannes/Desktop/var/remote/var/tmp/x86/kernel.image -o mtd7
put /Users/johannes/Desktop/var/remote/var/tmp/x86/kernel.image -o mtd14

quote SETENV firmware_version avm
quote UNSETENV provider
quote REBOOT

Ausagbe biem flashen:
200 Type set to BINARY
200 Media set to MEDIA_FLASH
5443592 Bytes übertragen in 11 Sekunden (494.1 KiB/s)
5443592 Bytes übertragen in 10 Sekunden (510.1 KiB/s)
1932808 Bytes übertragen in 4 Sekunden (485.4 KiB/s)
1932808 Bytes übertragen in 4 Sekunden (485.8 KiB/s)
28200968 Bytes übertragen in 34 Sekunden (802.8 KiB/s)
28200968 Bytes übertragen in 34 Sekunden (813.0 KiB/s)
3552264 Bytes übertragen in 6 Sekunden (615.2 KiB/s)
3552264 Bytes übertragen in 6 Sekunden (615.7 KiB/s)
200 SETENV command successful
200 UNSETENV command successful
221 Thank you for using the FTP service on ADAM2


@erst_nachdenken beantwortet das ausführlich genug den Vorgang? Oder welche Info fehlt dir noch?

bzgl dem Starten:
Wenn ich gleichzeit ein Ping auf die Box absetze und den Strom einstecke Sie die Ausgabe wiefolgt aus:
Hilft das zur Zeitlichen einordnung?

PING 192.168.178.1 (192.168.178.1): 56 data bytes


Request timeout for icmp_seq 0


Request timeout for icmp_seq 1


Request timeout for icmp_seq 2


Request timeout for icmp_seq 3


Request timeout for icmp_seq 4


Request timeout for icmp_seq 5


Request timeout for icmp_seq 6


Request timeout for icmp_seq 7


64 bytes from 192.168.178.1: icmp_seq=8 ttl=250 time=0.448 ms


64 bytes from 192.168.178.1: icmp_seq=9 ttl=250 time=0.423 ms


64 bytes from 192.168.178.1: icmp_seq=10 ttl=250 time=0.381 ms


64 bytes from 192.168.178.1: icmp_seq=11 ttl=250 time=0.420 ms


64 bytes from 192.168.178.1: icmp_seq=12 ttl=250 time=0.373 ms


64 bytes from 192.168.178.1: icmp_seq=13 ttl=250 time=0.414 ms


64 bytes from 192.168.178.1: icmp_seq=14 ttl=250 time=0.300 ms


64 bytes from 192.168.178.1: icmp_seq=15 ttl=250 time=0.342 ms


64 bytes from 192.168.178.1: icmp_seq=16 ttl=250 time=0.353 ms


Request timeout for icmp_seq 17


Request timeout for icmp_seq 18


Request timeout for icmp_seq 19


Request timeout for icmp_seq 20


Request timeout for icmp_seq 21


Request timeout for icmp_seq 22


Request timeout for icmp_seq 23


Request timeout for icmp_seq 24


Request timeout for icmp_seq 25


Request timeout for icmp_seq 26


Request timeout for icmp_seq 27


Request timeout for icmp_seq 28


Request timeout for icmp_seq 29


Request timeout for icmp_seq 30


Request timeout for icmp_seq 31


Request timeout for icmp_seq 32


Request timeout for icmp_seq 33


Request timeout for icmp_seq 34


Request timeout for icmp_seq 35


Request timeout for icmp_seq 36


Request timeout for icmp_seq 37


Request timeout for icmp_seq 38


Request timeout for icmp_seq 39


Request timeout for icmp_seq 40


Request timeout for icmp_seq 41


Request timeout for icmp_seq 42


Request timeout for icmp_seq 43


Request timeout for icmp_seq 44


Request timeout for icmp_seq 45


Request timeout for icmp_seq 46


Request timeout for icmp_seq 47


Request timeout for icmp_seq 48


Request timeout for icmp_seq 49


64 bytes from 192.168.178.1: icmp_seq=50 ttl=250 time=0.443 ms


64 bytes from 192.168.178.1: icmp_seq=51 ttl=250 time=0.420 ms


64 bytes from 192.168.178.1: icmp_seq=52 ttl=250 time=0.363 ms


64 bytes from 192.168.178.1: icmp_seq=53 ttl=250 time=0.419 ms


64 bytes from 192.168.178.1: icmp_seq=54 ttl=250 time=0.399 ms


64 bytes from 192.168.178.1: icmp_seq=55 ttl=250 time=0.402 ms


64 bytes from 192.168.178.1: icmp_seq=56 ttl=250 time=0.403 ms


64 bytes from 192.168.178.1: icmp_seq=57 ttl=250 time=0.417 ms


64 bytes from 192.168.178.1: icmp_seq=58 ttl=250 time=0.359 ms


64 bytes from 192.168.178.1: icmp_seq=59 ttl=250 time=0.401 ms


Request timeout for icmp_seq 60


Request timeout for icmp_seq 61


Request timeout for icmp_seq 62


Request timeout for icmp_seq 63


Request timeout for icmp_seq 64


Request timeout for icmp_seq 65


Request timeout for icmp_seq 66


Request timeout for icmp_seq 67


Request timeout for icmp_seq 68


Request timeout for icmp_seq 69


Request timeout for icmp_seq 70


Request timeout for icmp_seq 71


Request timeout for icmp_seq 72


Request timeout for icmp_seq 73


Request timeout for icmp_seq 74


Request timeout for icmp_seq 75


Request timeout for icmp_seq 76


Request timeout for icmp_seq 77


Request timeout for icmp_seq 78


Request timeout for icmp_seq 79


Request timeout for icmp_seq 80


Request timeout for icmp_seq 81


Request timeout for icmp_seq 82


Request timeout for icmp_seq 83


Request timeout for icmp_seq 84


Request timeout for icmp_seq 85


Request timeout for icmp_seq 86


Request timeout for icmp_seq 87


Request timeout for icmp_seq 88


Request timeout for icmp_seq 89


Request timeout for icmp_seq 90


Request timeout for icmp_seq 91


64 bytes from 192.168.178.1: icmp_seq=92 ttl=250 time=0.458 ms


64 bytes from 192.168.178.1: icmp_seq=93 ttl=250 time=0.452 ms
 
Zuletzt bearbeitet:
Das sieht eigentlich m.E. i.O. aus. Der
Code:
quote UNSETENV provider
ist iirc überflüssig wenn nicht sogar kontraproduktiv.
 
Bei den Mac Adressen war doch noch n Fehler drin und die Seriennummer fehlte
(Wird die Seriennummer mit den Punkten gespeichert? Oder sind die nur auf dem Aufkleber drauf, zur besseren lesbarkeit?)

Folgendes hab ich jetzt übertragen:
Bootloop bleibt aber bestehen

quote SETENV SerialNumber F502.547.30.301.438
quote SETENV macdsl C8:0E:14:92:EC:67
quote SETENV maca C8:0E:14:92:EC:68
quote SETENV macb C8:0E:14:92:EC:69
quote SETENV macwlan C8:0E:14:92:EC:6A
quote SETENV usb_board_mac C8:0E:14:92:EC:6B
quote SETENV usb_rndis_mac C8:0E:14:92:EC:6C
quote SETENV macdsl C8:0E:14:92:EC:67

quote REBOOT

Hat jede box ne macwlan2?
Die fehlt mir sonst noch.
 
Kostenlos!

Statistik des Forums

Themen
248,975
Beiträge
2,307,563
Mitglieder
378,751
Neuestes Mitglied
ieso04