Fritzbox 6490 Cable Firmware Update?

[PeterPawn]

#808, Satz 1: +1 ... kwT.

 

[KunterBunter]

Ich habe schon auf deine Antwort gewartet. Ich mache ja schon immer recht kurze Posts, aber so einen minimalistischen hätte ich gerade dir nicht zugetraut.

 

[PeterPawn]

Ist ja auch nicht böse gemeint ... aber wenn der Nächste dann auf die Idee kommt, die zweite Datei "kernel.image" (so eine 6490-Firmware hat nun mal zwei davon) gehört dann nach MTD2 (wo auch hier der Bootloader residiert, glücklicherweise läßt der sich vermutlich nicht so einfach überschreiben, auch wenn ich das bisher noch nie ausprobiert habe), dann steigt der Absatz neuer Geräte.

 

[pilsfreund]

Ich muss gestehen, dass ich just heute Morgen auch darüber nachgedacht habe, ob man die Firmware nicht direkt im EVA flashen könnte. Ich habe eine 6490 mit KDG Branding und Firmware 6.31, da geht also nach aktuellem Wissenstand nichts mit Pseudo-Images um Telnet zu aktivieren, etc. Sofern ich heute Abend dazukomme, werde ich mal versuchen, ob die Tips von Peter in #804 weiterführen, aber zumindest mein letzter Versuch die 6.61 mittels Developer-Tools im Browser zu flashen, sind gescheitert - wenn ich mich recht entsinne komplett ohne Fehlermeldung. Ich will aber auch nicht ausschließen, dass ich da einen Fehler gemacht habe.

Anyway, zurück zur EVA: Insgesamt müssen ja 4 Partitionen geflash werden, 2xKernel und 2xFilesystem. Das Layout bekommt man aus der Support-Datei und sinnvollerweise flasht man natürlich in die nicht aktiven Partitionen. Stellt sich mir nur die Frage, wie ich auf die in der EVA zugreife. Wie heissen denn die mmcblk0p? Partitionen dort?

Oder alternativ: mit image2ram und eva_to_memory ein Image mit Telnet aus dem SDRAM booten. Wobei mir da noch nicht klar ist, ob das auf einer 6490 überhaupt funktionieren kann. Auf welcher CPU läuft denn die EVA? Auf dem ARM oder dem x86? Und reicht es dann nur einen Kernel und Filesystem für diese CPU in den Speicher zu laden, oder brauchts das für beide CPUs?

 

[MalikatSaba]

#808, Satz 1: +1 ... kwT.

habe nicht verstanden, muss vielleicht auch nicht.

Übrigens welches kernel-image wohin gehört, und dass es zwei gibt, hatte schon rausgefunden. Das ist nicht schwer. Die Frage, ob es jemand probiert hat. Ich traue mich nicht. Vielleicht geht es auch gar nicht. Ich habe da keine Erfahrung...

 

[KunterBunter]

Es hat noch zum Glück noch keiner probiert. Wo hast du denn den zitierten tollen Ratschlag aufgeschnappt?

 

[MalikatSaba]

Weiss jetzt nicht wirklich, ob ich mich darüber freuen soll, dass du jetzt noch glücklich bist

 

[pilsfreund]

So, habe jetzt nochmal die Tipps von Peter aus Post #804 probiert und versucht meine KDG 6.31 Box mit dem 6.62 Image zu aktualisieren:
http://fritz.box/tools/update_result.html existiert und ich konnte damit das Update hochladen, das Ergebnis ist aber das gleiche wie bei meinen Versuchen mit den Developer-Tools: es passiert nichts. Nachdem der Upload abgeschlossen ist, wird nach wenigen Sekunden (ich würde schätzen 5) wieder das Hauptmenü der Weboberfläche.geladen. Keine Fehlermeldung, nichts.

Ich habe dann mal das Image entpackt, den OEM-Check in der var/install entfernt und mit einem Busybox-tar neu gepackt. Ergebnis war das gleiche.

Dann habe ich das Image mit den YourFritz Tools signiert und hochgeladen, aber wieder mit dem gleichen Ergebnis.

Hat sonst noch jemand irgendwelche Vorschläge/Ideen, was man probieren könnte?

 

[PeterPawn]

Als Reaktion auf einen erfolgreichen Upload sollte als erstes auf der Box "prepare_fwupgrade" aufgerufen werden, damit werden erst einmal alle Dienste heruntergefahren. Das sollte man in einer parallel zum Upload erstellten Support-Datei eigentlich sehen können.

Im Anschluß sollte dann die Signatur des Images geprüft werden, das erzeugt ein paar Dateien in /var/tmp (fwsign.log, fw_ip, firmware_stream_result), die sollte man ebenfalls in den Support-Daten sehen (also deren Existenz, nicht den Inhalt).

Wenn die Signatur-Prüfung bestanden wird, kommt /var/install zum Einsatz - auch das würde man in den Support-Daten sehen, daß dort /var/tmp komplett aufgelistet ist.

Eigentlich sollte jeder Fehler anhand des Zeitpunktes einzugrenzen sein ... insbesondere irritiert mich, daß die Reaktion beim AVM-Image und beim selbstsignierten dieselbe sein soll. Wenn das so ist, stirbt der Versuch des Uploads ja irgendwo vorher bereits und ich bin etwas verwundert, wo das bei der 06.31 sein soll. Bei der 06.50 hätte ich den Abbruch dann bei der Signatur-Prüfung erwartet.

Was liegt denn bei Dir in der anderen Partition für ein System? Oder hat die Box nur ein einziges und wurde mit 06.31 "produziert"?

Hat die 06.31 vielleicht "UpgradesManaged" gesetzt? Wobei dann bisher "Fehler 0" berichtet wurde ...

 

[Presswurst]

sagt mal wo habt ihr die Links zur Firmware gefunden?
z.B. diesen hier?
http://download.avm.de/firmware/6490/35727360/FRITZ.Box_6490_Cable.de-en-es-it-fr-pl.141.06.62.image

lässt sich dort in den Verzeichnissen evtl. auch eine Recovery.exe für die 6490 finden ( ich kenne mich damit nicht aus )
ich habe nämlich eine 6490 mit 6.31 "kdg"-Branding die sich ja bekanntlich nicht entbranden lässt

 

[Izlbrizl]

Hallo Zusammen

Habe meine 6490er mit Os 6.26 auf avm umgestellt und versucht das Update gem. Post Nr. 682 einzuspilen.
Ich bekam jedoch folgende Fehlermeldung:
Das Update ist fehlgeschlagen:
Es trat ein nicht näher spezifizierter Fehler während des Updates auf. (0)
Wiederholen Sie das Update oder starten Sie die FRITZ!Box neu.

Habe daraufhin versucht den Bootloader mit quote SETENV linux_fs_start 1 umzustellen, mit bye beendet und den stecker gezogen. Jetzt startet die Box aber nach ca 5 sekunden blingt nur noch die rote info LED
kann mir jemand helfen? da die Box mit FTP nicht mehr erkannt wird kann ich nichts mehr umstellen

 

[Presswurst]

Hallo Zusammen

Habe meine 6490er mit Os 6.26 auf avm umgestellt und versucht das Update gem. Post Nr. 682 einzuspilen.
Ich bekam jedoch folgende Fehlermeldung:
Das Update ist fehlgeschlagen:
Es trat ein nicht näher spezifizierter Fehler während des Updates auf. (0)
Wiederholen Sie das Update oder starten Sie die FRITZ!Box neu.

Habe daraufhin versucht den Bootloader mit quote SETENV linux_fs_start 1 umzustellen, mit bye beendet und den stecker gezogen. Jetzt startet die Box aber nach ca 5 sekunden blingt nur noch die rote info LED
kann mir jemand helfen?da die Box mit FTP nicht mehr erkannt wird kann ich nichts mehr umstellen

die Box mit einem Recovery-Tool z.B. von der 7490 in den FTP-Modus bringen, danach kannst du dich wie gewohnt darauf einloggen mit adam2 usw..... danach wieder quote SETENV linux_fs_start 0 einstellen
dann das Ganze nochmals versuchen..

 

[scuros]

Anscheinend bissl aufpassen wer bei UM ist und eine Mietbox hat, diejenigen die ihre Mietbox selber updaten werden wohl gerade angerufen und die Box wird durch einen Techniker ausgetauscht. Im UM Forum nachzulesen.

Thread Titel dort: Original Firmware auf 6490 einspielen?

Auch ne Möglichkeit, ich kenne KNBs die dann die Boxen einfach in kompletten Bridge Modus setzen.
----

Nie gegen die die versuchen hier ne Ebay Box versuchen zu registrieren, auch wenn ich denke das früher oder später alle Boxen mit Certs old/old vom Netz gesperrt werden.

 

[pilsfreund]

Als Reaktion auf einen erfolgreichen Upload sollte als erstes auf der Box "prepare_fwupgrade" aufgerufen werden, damit werden erst einmal alle Dienste heruntergefahren. Das sollte man in einer parallel zum Upload erstellten Support-Datei eigentlich sehen können.

Ich hab mal im Wireshark mitgeloggt: 0,1s nach dem POST Request durch ist, komm eine 302 Antwort, die auf /index.lua umleitet. Ich glaube nicht, dass in dieser kurzen Zeite irgendwelche Dienste angehalten wurden. Ich habe mal die Support-Datei während und unmittelbar nach dem Upload heruntergeladen, da konnte ich jetzt auf Anhieb keine Prozesse identifizeren, die angehalten wurden. Kannst Du mal konkrete Prozesse nennen, nach denen ich Ausschau halten sollte?

Im Anschluß sollte dann die Signatur des Images geprüft werden, das erzeugt ein paar Dateien in /var/tmp (fwsign.log, fw_ip, firmware_stream_result), die sollte man ebenfalls in den Support-Daten sehen (also deren Existenz, nicht den Inhalt).

Wenn die Signatur-Prüfung bestanden wird, kommt /var/install zum Einsatz - auch das würde man in den Support-Daten sehen, daß dort /var/tmp komplett aufgelistet ist.

Nichts dergleichen.

Eigentlich sollte jeder Fehler anhand des Zeitpunktes einzugrenzen sein ... insbesondere irritiert mich, daß die Reaktion beim AVM-Image und beim selbstsignierten dieselbe sein soll. Wenn das so ist, stirbt der Versuch des Uploads ja irgendwo vorher bereits und ich bin etwas verwundert, wo das bei der 06.31 sein soll. Bei der 06.50 hätte ich den Abbruch dann bei der Signatur-Prüfung erwartet.

Mir scheint, dass das Image einfach garnicht verarbeitet wird. Die Signatur vom Originalimage sollte ja gültig sein, die müsste also erstmal verifziert werden und danach das Image entpackt. Erst dann würde das Update abbrechen weil das Branding nicht passt. Aber das passiert doch nicht in 100ms..

Was liegt denn bei Dir in der anderen Partition für ein System? Oder hat die Box nur ein einziges und wurde mit 06.31 "produziert"?

Hat die 06.31 vielleicht "UpgradesManaged" gesetzt? Wobei dann bisher "Fehler 0" berichtet wurde ...

Die Alternativ Paritionen sind leer, es gibt nur die 6.31, linux_fs_start war nicht gesetzt.
UpgradesManaged war gesetzt, habe ich mit FBEditor auf no gesetzt, hat aber auch nichts gebracht..

 

[PeterPawn]

UpgradesManaged war gesetzt, habe ich mit FBEditor auf no gesetzt, hat aber auch nichts gebracht..

Heißt das, die Einstellung wurde nicht übernommen oder hat sich nichts geändert?

Wie bereits geschrieben, da wird als erstes dann "prepare_fwupgrade start UPNP" aufgerufen (sieht man bei startendem Update in der Prozessliste, wenn man die lange Ausgabe hat) und dieses Skript sieht so aus (hier aus der 06.50, dürfte sich aber wenig bis gar nicht von der 06.31 unterscheiden):

#! /bin/sh
. /etc/term.sh
PATH=/bin:/usr/bin:/sbin:/usr/sbin
term_usb()
{
#################################
## USB-HOST: das USB-Subsystem vor dem Runterfahren der Box (z.B. im Kontext eines Firmware-Updates) anhalten.
#################################
## Es wird nach dem Aufruf von /etc/hotplug/usb.pandu stop sofort zum Aufrufer zur.ckgekehrt,
## w.hrend im Hintergrund alle USB-Klienten ein "remove" gesendet bekommen, was dort dann das
## gro.e Aufr.umen ausl.st. Dieser Hintergrundproze. wartet bis zu 5 Sekunden auf
## das Beenden aller USB-Klienten und schie.t dann den OHCI-Treiber ab: Kein USB
## mehr vorhanden.
if [ -e /etc/hotplug/usb.pandu ] ; then
/etc/hotplug/usb.pandu stop
sleep 2
date > /dev/console
fi
}
## the parameter 'downgrade' is used just before /var/install is called with downgrade allowed
if [ "$1" = "downgrade" ]
then
## terminate multid to not write /var/flash/multid.leases after a downgrade with factorydefaults
## is done in /var/install
termavmforcedwait 5 multid
exit 0
fi
## Terminate any scheduled delayed reboot from firmwarecfg-CGI
local REBOOT_PID=`cat /var/run/delayed_reboot.pid`
rm /var/run/delayed_reboot.pid
if [ "$REBOOT_PID" != "" ] ; then
kill -9 $REBOOT_PID
fi
ps > /dev/console
date > /dev/console
if [ "$1" = "start" ] || [ "$1" = "start_from_internet" ] || [ "$1" = "start_tr069" ]
then
## kill everything except websrv,multid and firmwarecfg and sh
## to make room in RAM to store the firmware images before
## flashing them. if we download from the internet dsld is kept running also.
## NOTE that we have to keep the user modules for WLAN running!
## NOTE that voipd, upnpd, dsld and ctlmgr are terminated by
## firmwarecfg before the script is run, to have more free RAM (SL)
#################################
## Media-Subsystem vor dem Runterfahren der Box (z.B. im Kontext eines Firmware-Updates) anhalten.
#################################
if [ -e /etc/init.d/rc.media ] ; then
/etc/init.d/rc.media stop
sleep 2
date > /dev/console
fi
#################################
## Home Automation
#################################
if [ -x /usr/bin/aha ] ; then
/usr/bin/aha -s
fi
#################################
## EWETEL
#################################
if [ -x /bin/smartmeter ] ; then
/bin/smartmeter stop
fi
#################################
#################################
## Chrony stoppen
#################################
if [ -e /etc/init.d/rc.chrony ] ; then
/etc/init.d/rc.chrony stop
date > /dev/console
fi
if [ "$CONFIG_LLTD" = y ] ; then
lltdd -s
killall lltdd
fi
KEEP_USB=no
## due to use of term...forcedwait (may use kill -9) we have to disable the watchdog early
if [ -c /dev/watchdog ] ; then
echo disable watchdog >/dev/console
echo disable > /dev/watchdog
fi
if [ "`pidof touchdisplay`" != "" ] ; then
## Beim NLR wird der ctlmgr noch gebraucht
KEEP_CTLMGR=yes
else
KEEP_CTLMGR=no
if [ "$1" = "start" ] ; then
if [ "`pidof websrv`" = "" ] ; then
if netstat -l -n | grep -q "tcp.*\(0\.0\.0\.0\|::\):80 .*LISTEN" ; then
## active tcp listen on port 80 without websrv running
## --> keep ctlmgr running
KEEP_CTLMGR=yes
fi
fi
else
if [ "$1" = "start_from_internet" ] ; then
## one click update
KEEP_CTLMGR=yes
fi
fi
fi
if [ "$1" != "start" ] ; then
## UMTS-Stick wird beim Update via Internet u.U. noch gebraucht
KEEP_USB=yes
fi
## shutdown-list
## stage 1
## inetd restarts ftpd and smbd on demand, stop it first
PROCESSES="inetd capiotcp_server pbd faxd telefon dtrace printserv smbd nmbd"
## stage 2/3 - telefon & dect_manager have to stop before (at stage 1), configd at least.
## NOTICE: Once, if maild uses configd, it also must stop before configd.
PROCESSES_2="audiod pictured feedd playerd"
PROCESSES_3="configd"
## stage 4
## do not stop UPnP Deamon if running a UPnP-CGI
if [ "$2" != "UPNP" ] ; then
AVMDAEMONS="lltdd maild voipd usermand upnpd mediasrv avmlogd tr069discover contfiltd fritznasdb cableinfo"
else
AVMDAEMONS="lltdd maild voipd usermand mediasrv avmlogd tr069discover contfiltd fritznasdb cableinfo"
fi
if [ "$KEEP_CTLMGR" = "no" ] ; then
AVMDAEMONS="$AVMDAEMONS ctlmgr"
fi
if [ "$1" != "start" ] ; then
## we will download the update image from the internet so keep dsld running
echo "" >/dev/null
else
PROCESSES="$PROCESSES mailer"
AVMDAEMONS="$AVMDAEMONS dsld avmike"
fi
if [ "$KEEP_USB" = "no" ] ; then
term_usb
fi
ps > /dev/console
date > /dev/console
echo TERMINATING $PROCESSES > /dev/console
termforcedwait 5 $PROCESSES
date > /dev/console
echo TERMINATING $PROCESSES_2 > /dev/console
termforcedwait 5 $PROCESSES_2
date > /dev/console
echo TERMINATING $PROCESSES_3 > /dev/console
termforcedwait 5 $PROCESSES_3
date > /dev/console
echo TERMINATING $AVMDAEMONS > /dev/console
termavmforcedwait 5 $AVMDAEMONS
date > /dev/console
rm -rf /var/dtrace.txt
rm -rf /var/dtrace.tx2
termforcedwait 4 udhcpd dproxy ftpd
rmmod userman_mod
## Make room for update over internet on 7113
rmmod isdn_fbox_fon3
if [ "$1" = "start_tr069" ] ; then
echo "stopping wlan ..." >/dev/console
/etc/init.d/rc.net wlanstop
fi
killall -9 checkservices
date > /dev/console
rm -f /var/install
rm -f /var/tmp/*.image
exit 0
fi
if [ "$1" = "end" ]
then
## now kill everything else to avoid access to flash while flashing
/etc/init.d/rc.net wlanstop
if [ -c /dev/watchdog ] ; then
echo disable watchdog >/dev/console
echo disable > /dev/watchdog
fi
termforcedwait 5 mailer wpa_authenticator wstart
## do not stop UPnP Deamon if running a UPnP-CGI
if [ "$2" != "UPNP" ] ; then
termavmforcedwait 5 websrv upnpd usermand contfiltd dsld avmike multid ddnsd upnpdevd ctlmgr tr069discover
else
termavmforcedwait 5 websrv usermand contfiltd dsld avmike multid ddnsd upnpdevd ctlmgr tr069discover
fi
term_usb
exit 0
fi
echo "use: $0 [start|start_from_internet|start_tr069|end] [UPNP]"
exit 1

Wenn da sofort die Weiterleitung auf die "index.lua" kommt, dann paßt entweder eine Einstellung nicht (die "UpgradesManaged" wäre eben die erste Verdächtige an der Stelle, siehe die Box von @noob_noob) oder in der 06.31 ist das wirklich noch anders geregelt.

Die Textdatei im Anhang ist ein "diff" der Ausgabe des "strings"-Kommandos für "firmwarecfg", wobei die erste Version aus der 06.24-30308 und die zweite aus der 06.50-32615 stammt. Ich finde da nichts, was sich extrem unterscheiden würde (und nicht seine Ursache in der geänderten Behandlung von falsch oder nicht signierten Images und der generellen "Ablehnung" von Downgrades über das GUI - und damit indirekt über "firmwarecfg" - haben sollte) und daher würde ich eben auch bei der dazwischen liegenden 06.31 nicht unbedingt erwarten, daß AVM etwas aus- oder umgebaut hat, was dann in der 06.50 (das ist ja auch noch keine Version für eine Retail-Box) wieder rückgängig gemacht wurde - aber definitiv wissen tue ich das auch nicht.

EDIT: Hat die 06.31 bei Dir bereits die "erweiterten Support-Daten", wo dann der Inhalt der beiden TFFS-Partitionen in die Support-Daten ausgegeben wird?

 

[noob_noob]

UpgradesManaged war gesetzt, habe ich mit FBEditor auf no gesetzt, hat aber auch nichts gebracht..

checksumme hast du neu berechnet und am dateiende eingefügt? nach dem rückschreiben mal ne neue export datei gezogen, ob das wirklich auf no steht???

 

[skyse]

Vielleicht interessant:
Bei mir laufen jetzt 2 6490-Providerboxen, eine unter Kabeldeutschland/Vodafone und die andere unter Unitymedia.

Bei Kabeldeutschland/Vodafone läuft eine ehemalige Unitymedia Box (hatte vorher FW 6.22 -> debranded -> Update auf 6.62, new new)

und bei Unitymedia läuft eine ehemalige KDG-Box (hatte vorher FW 6.24 -> debranded -> Update auf 6.62, new new)

Läuft alles hervorragend. Übrigens ist die Provisionierungsseite von Vodafone ein echter Segen, wenn man zuerst mit Unitymedia rumgehampelt hat - total einfach und innerhalb von 3 Minuten online + SIP-Daten.

Die beiden Anschlüsse sind logischerweise an zwei Wohnsitzen, in verschiedenen Bundesländern.

 

[pilsfreund]

Checksumme habe ich neu berechnet und der Upload der Export-Datei wurde auch akzeptiert. Ohne korrekte Prüfsumme wird die Datei mit "Die angegebene Datei ist keine gültige Import-Datei." abgelehnt.
Tatsächlich wird die Änderung aber trotzdem nicht übernommen. Angeblich werden die Daten zwar importiert und die Box startet neu, aber nach dem Reboot ist UpgradesManaged wieder auf "yes". Das hatte ich bisher noch nicht überprüft, aber erklärt auch, warum sich durch das Setzen auf "no" nichts geändert hatte. Andere Felder in der Export-Datei, auch in der tr069cfg, kann ich ändern und die Änderungen überstehen auch einen Reboot (konkret mit FirstUseDate getestet). Aber das UpgradesManaged wird anscheinend beim Reboot zurück gesetzt. Kann also schon sein, dass deswegen das firmwarecfg das hochgeladene Image gleich verwirft und keine Prozesse angehalten bzw. Signaturen überprüft werden.

Den Inhalt der TFFS-Partitionen kann ich in der Support-Datei nicht finden.

 

[PeterPawn]

Die Variable könnte (ich hoffe, das ist deutlich genug, um den Konjunktiv auszudrücken) über TR-064 gesetzt werden: https://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/mgmsrvSCPD.pdf - Funktion SetUpgradeManagement.

Eigentlich sollte dort eine Änderung auch ohne Neustart wirksam werden.

Wie man das TR-064-Interface benutzen kann, ist in mehreren Threads hier im IPPF Thema, da steht dann auch irgendwo garantiert ein Link auf einen c't-Artikel, den es mal zum Thema "PowerShell und FRITZ!Box-TR-064" gab.

Wenn man geändert hat, kann man mit "GetInfo" gleich noch einmal abfragen, ob die Änderung übernommen wurde und dann vor dem nächsten Neustart einfach probieren, ein Pseudo-Image zu laden oder meinetwegen auch ein Update auszuführen.

 

[ncc-1701]

Den Inhalt der TFFS-Partitionen kann ich in der Support-Datei nicht finden.

konntest Du die Option "Erweiterte Supportdaten" im Web-IF http://fritz.box/?lp=support in FW 06.31 selektieren ?

nur dann erscheint in Support-Datei der Abschnitt:

"##### BEGIN SECTION TFFS_DUMP TFFS Dump"