Fritzbox 6490 Cable Firmware Update?

[BB_Nord]

Hallo PeterPawn,

Bei mir funktioniert der Weg via Bootloader nicht:

• Win10 & EVA-FTP-Client.ps1 get nicht
• Ubuntu 18.04.2 via NCFTP oder FTP-> geht ebenfalls nicht
• MacOS via NCFTP oder FTP-> geht ebenfalls nicht
• zwei unterschiedliche PC's ausprobiert EDIT: IMac mit eingebauter Ethernet-Schnittstelle und einen Barebone PC (Intel Atom, ebenfalls normale Ethernet-Schnittstelle auf dem Board vorhanden)
• Netzwerkkabel getauscht

Daher war meine Idee nun, über einen anderen Weg ein neues Image zu laden:

• WebInterface via HTML Script & Switchen von linux_fs_start nach dem 106 Fehler -> kein Update
• Starten der 6.24 und Einschalten von Telnet via #96*7* -> kein Erfolg (ohne Telefonnummer bzw. nur mit Eintrag und Click im Telefonbuch scheint es nicht zu funktionieren)
• Versuch nach Analyse Deines Scripts "BootDeviceFromImage" zu verwenden

Wenn Du einen Tipp hast, wie es doch noch funktionieren könnte wäre ich dankbar.

Hier noch das Environment meiner Box

annex                 Kabel
autoload              yes
bootloaderVersion     1.2411
bootserport           tty0
country               049
cpufrequency          1200000000
crash                 [0]ccf14a23,7be,6[1]ff570524,15d,6[2]68ab016,15d,6[3]b1caad4,570b95a9,1
firstfreeaddress      0x00b20000
firmware_info         141.06.24
firmware_version      avm
flashsize             nor_size=0MB sflash_size=2MB nand_size=2048MB
language              en
linux_fs_start        1
maca                  <deleted>
macb                  <deleted>
macwlan               <deleted>
macwlan2              <deleted>
macdsl                <deleted>
memsize               0x10000000
modetty0              38400,n,8,1,hw
modetty1              38400,n,8,1,hw
modulemem             4033982
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
tr069_passphrase      <deleted>
tr069_serial          <deleted>
urlader-version       3411
usb_board_mac         <deleted>
usb_device_id         0x0000
usb_device_name       USB DSL Device
usb_manufacturer_name  AVM
usb_revision_id       0x0000
usb_rndis_mac         <deleted>
wlan_key              <deleted>

.\EVA-FTP-Client.ps1 -ScriptBlock { GetEnvironmentFile count }
reboot_major          u
reboot_minor          u
run_hours             u
run_days              u
run_mounths           u
run_years             u

Gruß,
BB_Nord

 

[PeterPawn]

Ich würde mal vermuten, daß die 06.24 ganz normal über eine "provider_additive.tar" "gekapert" werden kann. Wie das funktioniert, steht hier irgendwo in diesem Thread, wenn ich mich recht erinnere. Aber da steht sicherlich auch, daß das einfache Einschalten von Telnet über den Telefoncode bei einer DOCSIS-Box von AVM noch nie funktionierte ... das hast Du ja trotzdem versucht.

Wie man jetzt die (zweifellos vorhandene) Beschreibung findet, wie das mit der "provider_additive"-Lücke funktioniert, kann ich Dir auch nicht sagen ... ich persönlich habe auch den Link dahin nicht gespeichert - einfach weil ich diese Anleitung nie brauchte.

Aber mit ihr sollte man zu einem Shell-Zugriff gelangen ... nur muß man dann immer noch beachten, daß bei der alten Architektur der (AVM-)Firmware die meisten Sachen auf dem ARM-Core abliefen und das mit der heutigen Architektur nicht zu vergleichen ist. Das läßt mich dann wieder vermuten, daß der beste Weg am Ende doch das "Einlesen" in diesen Thread wäre (unabhängig von dessen Länge), denn der größte Teil hier bezieht sich eben noch auf die Situation vor dem Erscheinen der Version 06.8x, bei der dann der ATOM-Core die Regie (bzw. den "eRouter") übernahm.

Das alles erklärt aber auch noch nicht wirklich, warum die FTP-Verbindungen mit "426" beendet werden ... allerdings gingen alle bisherigen Schreibversuche ja in Richtung eMMC. Wenn da der Controller ein Problem hat und wg. eines solchen elektrischen Problems tatsächlich von einem Schreibschutz ausgeht, sollte ja zumindest das Beschreiben von MTD3 und MTD4 funktionieren, denn die liegen ja im SPI-Flash.

Solange man nur eine der beiden Partitionen löscht, passiert auch nichts (bzw. nur wenig) ... es gehen ggf. die zuletzt vorgenommenen Einstellungen verloren. Daher schaut man besser mal nach, welche Partition die ältere Version enthält (die erweiterten(!) Supportdaten extrahieren [die sollte man mindestens einmal ja ohnehin schon haben] und unmittelbar danach die Box herunterfahren) und beschreibt dann nur diese eine mit einem selbstgebastelten TFFS-Image (oder ausnahmsweise auch mal mit Unfug, weil die andere ja die korrekten Daten enthalten sollte). Dann kriegt man zumindest schon mal heraus, ob das Problem am FTP-Server allgemein oder tatsächlich am Ziel der Speicherung liegt. Ist es letzteres, sollte sich die Partition für das TFFS ja beschreiben lassen ... ansonsten ist es wohl doch etwas anderes als ein Problem mit dem eMMC-Controller.

Gleichzeitig ist der Erfolg beim Beschreiben der TFFS-Partition auch eine Voraussetzung dafür, daß der Versuch über eine "provider_additive.tar" überhaupt lohnt ... läßt sich auch der SPI-Flash nicht über den Bootloader beschreiben, kriegt man das geänderte TFFS-Image ja auch nicht in die Box.

Ansonsten verweise ich noch einmal auf die Notwendigkeit des Paketmitschnitts ... es ist schon ein erheblicher Unterschied, zu welchem Zeitpunkt diese 426-Meldung ausgegeben wird und was bis dahin mit den bereits übertragenen TCP-Paketen geschehen ist ... wurden die nun von der Box mit ACK quittiert (und sind damit definitiv auch angekommen) oder nicht? Ich habe auch schon FIN-Pakete (anstelle ACK) von einer Box gesehen, nachdem die ersten Blöcke übertragen wurden ... aber lange bevor die Daten tatsächlich komplett (gesendet) waren. Bei anderen Geräten (u.a. der 7390) habe ich auch Probleme festgestellt (sogar mit dem originalen AVM-Recovery-Programm), wenn da auf einmal Jumbo-Packets (also Ethernet-Pakete mit mehr als 1500 Byte Payload) verwendet wurden (i.d.R. eine Treibereinstellung, die aber auch mal "falsch" sein kann als Standardeinstellung). Alles das muß man ggf. auch erst mal ausschließen ... nur bringt reines "Raten" eben auch nichts. Die Werkzeuge zur Diagnose existieren ... man muß sie halt anwenden und das kann nur derjenige, der die Box in seinen Händen hat.

 

[stoney]

Bei der 6.24 wäre in diesem Fall (auch wenn es für spätere Aktionen ggf sinnvoll wäre, auch die neuen Möglichkeiten zu nutzen) ja auch die Uploadlücke nutzbar/ein gangbarer Weg, welche ja bereits zig mal im Netz zu finden ist (auch hier im IPPF) oder wird das mit "HTML-Script" gemeint? (Einen Link zur befolgten Anleitung bzw das Aufschreiben Deines genauen Vorgehens ggf incl Screenshots wären da auch hilfreich)

Die Certs sind ja neu, wurden auf 6.50 mal die Werkseinstellungen geladen (ab der 6.50 sollten diese ja peristent erhalten bleiben - bitte selbst nochmals recherchieren) dann zurück auf 6.24 und den Weg über den Uploadbutton nochmals bestreiten.

 

[BB_Nord]

Ich habe einen Mitschnitt via tcpdump gemacht. Es kommen zwar immer ACK Pakete, allerdings mit Len = 0.
Ich bin Wireshark Neuling und mir fehlt der Vergleich wie es korrekt aussehen sollte, daher wäre es nett wenn jemand sich den Mitschnitt mal anschauen könnte.


Mit HTML-Script ist der Upload via HTML-Code gemeint:

<html>
    <head>
        <base href="http://192.168.178.1" />
        <title>FRITZ!OS upload image file</title>
    </head>
    <body>
        <form method="POST" action="/cgi-bin/firmwarecfg" enctype="multipart/form-data">
            <input name="sid" value="hier SID eintragen" type="text" />
            <br />
            <input name="UploadFile" type="file" />
            <br />
            <input name="upgrade" type="submit" value="Upload starten" />
            <br />
        </form>
    </body>
</html>

 

[PeterPawn]

Da kommt ein FIN-ACK von der Box nach ~ 128 KB übertragenen Daten (Paket 243). Dem Rest hört sie also gar nicht mehr zu ... der wird also garantiert auch nirgendwo mehr hingeschrieben, so daß die fehlenden Änderungen eher nicht verwunderlich sind. Gleich danach kommt ja auch von der Box der Hinweis mit dem "426" ... ich habe auch keine Ahnung/Idee, warum die Box hier einfach die Verbindung schließt.

Allerdings würde ich auch (wenn ich's "von Hand" mache) erst einmal die Message "150 Opening BINARY data connection" abwarten und per ACK bestätigen, BEVOR ich die Datenverbindung mit Paketen flute.

Zumindest machen das meine Skript-Dateien (konkret "eva_store_tffs", wo erst nach dem "150" das "cat" startet) so - hier (also mit "ncftp") geht das Schreiben in die Datenverbindung schon vor dem ACK los. Möglich, daß der FTP-Server genau das nicht mag ... das ist schließlich weder ein vollumfänglicher TCP-Stack, noch ein "full featured FTP server" und daß da bei AVM auch mal Fehler im Bootloader sein können, zeigt das Beispiel mit den MAC-Adressen "0x00, ".

Bleibt die Frage, warum da so ein Feuerwerk an Unsinn vor dem eigentlichen "STOR" abgebrannt wird - bis hin zum sinnlosen Öffnen und Schließen einer Datenverbindung durch den Client. Die Tatsache, daß dieser ganze Unsinn bei anderen funktioniert hat, sollte nur dann die eigene Erwartungshaltung verändern, wenn man sich auch sicher ist, daß diese "anderen" tatsächlich dieselbe Bootloader-Version (1.2411) verwendet haben. Ich wäre hier also wieder hingegangen (ist ja offenbar ein Ubuntu) und hätte "eva_store_tffs" genommen ... das macht nichts anderes, als das AVM-Recovery-Programm auch und verzichtet auf den ganzen anderen Quatsch, der von der Box ohnehin immer nur mit "not implemented" abgewiesen wird.

Denkbar, daß die zwei doppelten ACK-Pakete von der Box (eines für die erste Datenverbindung und eines in der Control-Verbindung) eigentlich anderen Inhalt haben sollten ... ich kann jedenfalls keinen Grund im Mitschnitt erkennen, warum man diese Pakete überhaupt senden sollte - verloren gehen sollten auf der direkten Ethernet-Verbindung ja eigentlich keine Pakete.

Eine Wiederholung des ACK für ein SYN (Paket 95), wenn man gerade ein FIN-ACK für diese Verbindung erhalten hat (Paket 100), erscheint mir jedenfalls prädestiniert dafür, daß da irgendwelche FSMs (finite state machines) bei der Implementierung eines TCP-Stacks durcheinander geraten und dann würde es mich auch nicht wundern, wenn die Datenverbindung danach nicht mehr funktioniert. Immerhin unterstützt der FTP-Server auch (nach allem, was bisher bekannt ist) nur eine Control-Connection und eine Data-Connection. Da reicht schon ein falsch gesetztes Flag, damit die Daten irgendwo im Nirwana landen. Ich würde es also - schon aus Gründen der Überschaubarkeit - komplett vermeiden, da mit irgendwelchen überflüssigen Kommandos und sinnlosen Datenverbindungen aufzulaufen ... das alles sind potentielle Fehlergründe, die vielleicht nur mit dieser Version des Bootloaders zutage treten.

 

[BB_Nord]

Hallo PeterPawn,

Danke für die Analyse des Logs. Ich habe inzwischen über 6.24 und dem Upload eines Pseudo Images (telnet-1.tar) einen Zugang zur Box bekommen.

Danach habe ich ein aktuelles 7.10 image so modifiziert, dass der Log statt auf die Konsole in /nvram/install.log gespeichert wird.

Fazit: Schreiben sieht ok aus, der "übliche" Abbruch dank der Cert Prüfung am Ende. Nach Reboot & manuellem Umsetzen vo linux_fs_start 0 startet aber weiterhin das alte 6.50 FritzOS.

/var/install [1723]: +++++++++++++ update start
/var/install [1723]: +++++++++++++ FlashCMDs (to be executed):
/var/install [1723]: +++++++++++++ ATOM Kernel     FlashCMD: dd if=/var/remote/var/tmp/x86/kernel.image of=/dev/mmcblk0p4 count=2048 bs=4096 conv=sync
/var/install [1723]: +++++++++++++ ATOM Filesysten FlashCMD: dd if=/var/remote/var/tmp/x86/filesystem.image of=/dev/mmcblk0p3 count=16384 bs=4096 conv=sync
/var/install [1723]: +++++++++++++ ARM Kernel     FlashCMD: dd if=/var/remote/var/tmp/kernel.image of=/dev/mmcblk0p2 count=2048 bs=4096 conv=sync
/var/install [1723]: +++++++++++++ ARM Filesysten FlashCMD: dd if=/var/remote/var/tmp/filesystem.image of=/dev/mmcblk0p1 count=16384 bs=4096 conv=sync
/var/install [1723]: +++++++++++++ ATOM flash kernel
/var/install [1723]: +++++++++++++ ATOM check kernel
/var/install [1723]: +++++++++++++ ATOM md5sum of kernel image:
/var/install [1723]: +++++++++++++ ATOM size of kernel image: 3489968
/var/install [1723]: +++++++++++++ ATOM md5sum of kernel mtd :
/var/install [1723]: +++++++++++++ ATOM write to /dev/mmcblk0p4 done
/var/install [1723]: +++++++++++++ ATOM flash filesystem
/var/install [1723]: +++++++++++++ ATOM check filesystem
/var/install [1723]: +++++++++++++ ATOM md5sum of filesystem image:
/var/install [1723]: +++++++++++++ ATOM size of filesystem image: 24216951
/var/install [1723]: +++++++++++++ ATOM md5sum of filesystem mtd :
/var/install [1723]: +++++++++++++ ATOM write to /dev/mmcblk0p3 done
/var/install [1723]: +++++++++++++ ARM flash kernel
/var/install [1723]: +++++++++++++ ARM check kernel
/var/install [1723]: +++++++++++++ ARM md5sum of kernel image:
/var/install [1723]: +++++++++++++ ARM size of kernel image: 1873966
/var/install [1723]: +++++++++++++ ARM md5sum of kernel mtd :
/var/install [1723]: +++++++++++++ ARM write to /dev/mmcblk0p2 done
/var/install [1723]: +++++++++++++ ARM flash filesystem
/var/install [1723]: +++++++++++++ ARM check filesystem
/var/install [1723]: +++++++++++++ ARM md5sum of filesystem image:
/var/install [1723]: +++++++++++++ ARM size of filesystem image: 5791048
/var/install [1723]: +++++++++++++ ARM md5sum of filesystem mtd :
/var/install [1723]: +++++++++++++ ARM write to /dev/mmcblk0p1 done
/var/install [1723]: +++++++++++++ ARM Calling additional procedure (ewnw_check_install)
/var/install [1723]: +++++++++++++ ARM Calling additional procedure failed: UPDATE FAIL (1)

Danach der direkte Test via Telnet: Flash wird nicht geschrieben

# dd if=/dev/mmcblk0p1 count=1 bs=67108864 | md5sum
bd5de58a9b5d1d9692c63a7ae4128e42  -
1+0 records in
1+0 records out
# dd if=/dev/zero of=/dev/mmcblk0p1 count=16384 bs=4096 conv=sync
16384+0 records in
16384+0 records out
# dd if=/dev/mmcblk0p1 count=1 bs=67108864 | md5sum
bd5de58a9b5d1d9692c63a7ae4128e42  -
1+0 records in
1+0 records out

Muss zum Flashen das Kernel Modul flash_update.ko geladen sein? Es ist zwar vorhanden, aber nicht geladen und auch nicht in den module.dep des Kernels vorhanden:

# lsmod
Module                  Size  Used by    Tainted: P 
userman_mod            61920  4
atd                   146047  0
fwd                     1332  1 atd
athlogger               6710  0
hif_gmac                8878  2 atd,athlogger
adf                   102438  1 atd
aae                    73300  1 atd
edocsis_mod             4896  0
sch_sfq                 5152  4
sch_llq                 6931  1
sch_tbf                 3701  1
docsis_pp             135191  0
avalanche_cnid         33649  0
docsis_fltr_class      26972  0
docsis_bridge         136896  4 edocsis_mod,avalanche_cnid,docsis_fltr_class
kintr                  28965 60
docsis_management      94693  5 docsis_fltr_class
soc_if_driver          34196  0
kdsldmod             1347016  9 userman_mod
l2switch_proxy_driver     4434  0
cat_l2switch_netdev     8236  1 l2switch_proxy_driver
zram                    8558  1
lzo_compress            1823  1 zram
dect_io                10544  2
avm_dect              217896  1 dect_io
capi_codec            350669  0
isdn_fbox_fon5        710727  6
pcmlink               258317  4 avm_dect,capi_codec,isdn_fbox_fon5
led_modul_Fritz_Box_HW213a    85111  8

 

[PeterPawn]

Meines Wissens ist das "flash_update.ko" nur für das Flashen von (sehr alten) NOR-Boxen notwendig, wo nach dem Flashen nichts vom alten System mehr vorhanden war und unmittelbar neu gestartet werden mußte.

Spätere Versionen verwenden "update_kernel", was über die MTD-Architektur schreibt und beim eMMC-Speicher sollte das auch nicht mehr notwendig sein, denn der emuliert ja ein Disk-Device (inkl. Partition-Table).

Dann wird wohl tatsächlich der eMMC-Speicher defekt sein ... der Test für den SPI-Speicher steht ja wohl immer noch aus, zumindest vom Bootloader ausgehend.

Wenn das tatsächlich so sein sollte (ich kenne jedenfalls auch keine Möglichkeit, den irgendwie auf "read-only" zu setzen - aber vielleicht gibt es tatsächlich irgendeinen GPIO-Pin für ein "write enable" am eMMC-Chip, das findet sich dann garantiert in den Kernel-Quellen der alten Versionen in der entsprechenden "hw_config"-Datei für dieses Modell), wirst Du da kein Update mehr installiert kriegen ... dann sollte sich aber auch der NAS-Speicher nicht beschreiben lassen, was man als weiteres Indiz für "eMMC defekt" heranziehen könnte und was dann ein "Nur die Systempartitionen lassen sich nicht ändern." wieder ausschließt.

 

[vaxinf]

Es passt vielleicht nicht wirklich zu den vorherigen Beiträgen.

Ich habe eine Kopie der Firmware 7.02 für die FB6490, die Unitymedia für ihre eigenes FB6490 / Business Gerät benutzt.
Erzeugt als dumps, nachdem ich auf die inaktiven Partitionen eine freetz-Version gebracht habe.

Wer interessiert ist, kann mich ja kontaktieren.

Eberhard

 

[Kaosmann]

Leider funktioniert der Link in den Beiträgen zuvor nicht mehr.
Möchte die 6490 als Mesh Repeater einsetzen.
Vielen Dank für eure Hilfe

 

[PeterPawn]

Leider funktioniert der Link in den Beiträgen zuvor nicht mehr.

Lies Dir einfach mal die Seite 115 auch wirklich durch (und "scanne" nicht nur nach irgendwelchen Download-URLs) ... da gab es nie einen funktionierenden Link auf die Firmware (das ist auch Absicht), dafür aber mehr als genug Informationen, wie Du die URL für den Download SELBST ERMITTELN kannst.

 

[Kaosmann]

Danke PeterPawn für die schnelle Antwort.
Leider bin ich auf 115 nicht wirklich fündig geworden ;-(
ich bin sicher, dass dort alles steht für Leute die Ahnung von der Materie haben.
[...]
Vielen Dank für eure Hilfe

Edit DM41: Firmwareanfragen bitte im dafür eingerichteten Thread platzieren.

 

[PeterPawn]

für Leute die Ahnung von der Materie haben.

Da sich gerade eine 6490 nicht ohne weiteres (auch nicht, wenn da eine Version jenseits von 07.10 installiert sein wird in der Zukunft) downgraden läßt (es gibt ja kein Recovery-Programm) und eine Box mit bereits installierter Retail-Firmware problemlos ein Online-Update ausführen könnte (das kann sie auch im LAN1-Router-Modus, wenn sie keine öffentliche IP hat und nicht am BK-Netz betrieben wird - warum bräuchte es da also unbedingt die Image-Datei, deren Download AVM eigentlich gar nicht vorgesehen hat), bleibt ja als erkennbare Notwendigkeit für eine solche Suche nur noch die Variante mit der Provider-Box übrig.

Dafür sollte man aber auch genug Ahnung von der Materie haben oder sich diese zumindest aneignen ... ansonsten kann man mit dem Image gar nichts anfangen bzw. schlägt dann mit der nächsten Frage hier auf, wenn man seine Box erst mal unbenutzbar gemacht hat.

Ich verstehe also nicht, wieso jemand - der sich nicht in der Lage sieht, mit einer der drei angebotenen Varianten die Download-URL für ein Firmware-Image selbst zu ermitteln (obendrein noch bei vorhandener Box, wo man praktisch außer deren Adresse nichts wissen muß von dem Modell) und die decken nun wirklich fast jede denkbare Situation "in einem Haushalt" ab, was die vorhandenen PCs betrifft - auf der Suche nach einem solchen Image ist ... außer er geht von falschen Annahmen aus.

Alles, was es da an Möglichkeiten zum "Ermitteln" der URLs zusammenzufassen gibt, steht jedenfalls in #2292 - wer da "nicht fündig" wird, hat wohl eher nicht den notwendigen Willen zur Investition eigener Zeit und Anstrengung. Da so jemand dann bei der nächsten Version erneut "fragen" müßte, halte ich es auch insgesamt eher für kontraproduktiv, wenn diese Haltung am Ende Erfolg hat oder "belohnt" wird ... aber das ist nur meine eigene Ansicht und irgendjemand, der dazu in Opposition steht, wird Dir die URL garantiert zukommen lassen.

 

[Kaosmann]

Hallo, vielen Dank an alle die mir so schnell und unkompliziert das Image zur Verfügung gestellt haben.
Vielen vielen Dank.

 

[Larsenz]

Hallo zusammen,

ich bin neu hier im Forum und möchte, ähnlich wie User Kaosmann meine alte Fritzbox 6490 mit Branding von Unitymedia als Mesh Repeater einsetzten. Durch das UM Branding sind einige Funktionen, darunter die Updatefunktion nicht vorhanden.
Nun habe ich die "How to" Anleitung zum entfernen des Brandings und aufspielen des Retail OS schon durchgearbeitet. Ich habe mir den Juischeck in Form des Programms und des Excel Programms runtergeladen. Problem ist, dass das Programm meine Fritzbox auch erkennt, die darauf enthaltene Firmware als 6.52 indentifiziert, mir beim Updatecheck aber sagt, dass keine Aktualisierung vorhanden ist.
Zum Test habe ich das gleiche Prozeder mit einer vorhandenen 7490 durchgeführt und da kam nach dem Updatecheck der Hinweis, dass ein neues OS erhaltbar ist, dieses runtergeladen werden kann, was ich daraufhin auch getan habe.

Wer von euch kann mir helfen? Mache ich irgendwas in der Herangehensweise falsch?

Vorab vielen Dank für eure Antworten.

Gruß Larsenz

 

[keller-s]

Gebe manuell eine ältere Firmware an siehe Bsp.
OEM auf AVM stellen

 

[BB_Nord]

Meines Wissens ist das "flash_update.ko" nur für das Flashen von (sehr alten) NOR-Boxen notwendig, wo nach dem Flashen nichts vom alten System mehr vorhanden war und unmittelbar neu gestartet werden mußte.

Spätere Versionen verwenden "update_kernel", was über die MTD-Architektur schreibt und beim eMMC-Speicher sollte das auch nicht mehr notwendig sein, denn der emuliert ja ein Disk-Device (inkl. Partition-Table).

Dann wird wohl tatsächlich der eMMC-Speicher defekt sein ... der Test für den SPI-Speicher steht ja wohl immer noch aus, zumindest vom Bootloader ausgehend.

Wenn das tatsächlich so sein sollte (ich kenne jedenfalls auch keine Möglichkeit, den irgendwie auf "read-only" zu setzen - aber vielleicht gibt es tatsächlich irgendeinen GPIO-Pin für ein "write enable" am eMMC-Chip, das findet sich dann garantiert in den Kernel-Quellen der alten Versionen in der entsprechenden "hw_config"-Datei für dieses Modell), wirst Du da kein Update mehr installiert kriegen ... dann sollte sich aber auch der NAS-Speicher nicht beschreiben lassen, was man als weiteres Indiz für "eMMC defekt" heranziehen könnte und was dann ein "Nur die Systempartitionen lassen sich nicht ändern." wieder ausschließt.

Antwort hat etwas gedauert, da ich inzwischen im Urlaub war. Der gesamte Flash Speicher ist read-only, auch die FTP Partition für den NAS Speicher. Ich schreaube die Box mal auf und schaue mir den eMMC Chip an. Es wird dann wohl eher ein WLAN Repeater + DVB-C Verteiler auf 6.50 OS werden.
Vielen Dank nochmal für die Hilfe und die Infos

 

[Delorean]

Hallo zusammen,

ich habe mir nun ebenfalls eine 6490 Kabelbox (2000 2691, wohl KD)gekauft und möchte diese für Unitymedia nutzen. Sie hat die FW 6.22. Ich möchte Sie nun upgraden. Habe hier die FW7.01 gefunden.

Habe die Box nun per FTP-Zugang (Adam2 usw.) entbrandet. Allerdings bekomme ich beim Versuch ein Upgrade durchzuführen folgenden Fehler: Es trat ein nicht näher spezifizierter Fehler während des Updates auf.

Muss ich erst eine ältere Firmware nehmen? Habt Ihr eine Idee zur weiteren Vorgehensweise?

Vielen Dank im Voraus.

 

[vaxinf]

Welche Firmwareversion ist denn jetzt nach dem entbranden drauf?

Oft muss man Zwischenschritte einlegen. die juis-update Tools z.B. JuisCheck helfen dabei, das richtige Image zu finden und runterzuladen.

 

[Delorean]

Hallo, habe aktuell die 6.10 Version und 6.22 Version, je nachdem welchen Bootloader ich wähle.




Die Box synchronisiert nicht mit Unitymedia...

 

[vaxinf]

Um sicher zu gehen, folgende Frage:

Wurde ein Firmware-Image 6.10 mit der "adam2-Methode" auf die Maschine gebracht und die Environment-Variable
firmware_version auf "AVM" gesetzt?