Fritzbox 6490 Cable Firmware Update?

ich bin zuversichtlich, dass @PeterPawn eine Vermutung / Erklärung parat hat
Leider zuviele und daher ist das mehr "so könnte es sein" als handfeste Untersuchungen.

Ich hatte mich noch einmal etwas in die CVC-Datei von AVM vertieft - die ist ja definitiv in dieser Form von AVM signiert mit deren CVC-Key. Das ist immer etwas merkwürdig beim Formulieren, weil "CVC" m.W. für "code verification certificate" steht und gleichzeitig wohl als "Erweiterung" für diese Dateien verwendet wird - egal, es gibt ja neben dem Herstellerzertifikat noch ein weiteres, mit dem solche Updates dann signiert werden ... daher ist das (hoffentlich) von AVM, dieser Key wird ja nicht auch bei einem Provider liegen, damit der im Namen von AVM signieren kann.

Ich weiß ja nicht, wie lange das schon so geht - normalerweise sollte der "operator" ja nach der DOCSIS-Spezifikation nur die Möglichkeit des "co-signings" habe, um damit seinerseits das "OK" zur Benutzung im eigenen Netz zu erteilen (optional). Dann kann er aber nichts am Inhalt der Firmware ändern - wollen wir einfach mal annehmen, daß da auch in den frühen Jahren (das CVC-Zertifikat, mit dem das File von AVM signiert ist, stammt ja auch schon aus 2009, wie das alte auf der Box) von AVM kein Schlüssel an die KNB verteilt wurde - ich war da immer sehr skeptisch, ob die KNB nun ändern und selbst signieren können oder nicht und das freiwillige Verteilen des alten Keys für die CM-Zertifikate mit der Firmware war einer der Gründe dafür, daß da etwas nicht "nach Standard" laufen könnte.

Egal ... jedenfalls enthält das CVC-File für die 06.50 (mit lgi- und avm-Branding im Inneren) gar kein Programm zum Update des Zertifikats ... das paßt dann auch wieder dazu, daß eigentlich das CM während eines solchen Updates die einzige aktive Komponente des eDOCSIS-Gerätes sein sollte. Wenn das so ist, braucht es da ja auch kein Update-Programm und keine /var/docsiscertdefaults - letztlich auch kein ewnw_check_install. Und siehe da, es gibt sie tatsächlich nicht im enthaltenen Tarball - und auch keinen Aufruf von ewnw_check_install innerhalb der /var/install.

Damit dürften die Boxen bei den Providern auch nur dann ein Online-Update des Zertifikats versuchen, wenn das Update vom Provider auf einem anderen Weg angeschoben wurde und da bleibt ja eigentlich nur TR-069 übrig. In dem dort verteilten Image (auch das ist ja von AVM signiert, wenn auch auf die "herkömmliche" Art ohne die DOCSIS-PKI) sollte dann wieder das Update-Programm enthalten sein.

Da ich selbst noch kein Update beobachten oder mitschneiden konnte, bleibt mir ja nur das Ansehen des von AVM so großzügig verteilten Programms "cm_dl_cert", das sich ja merkwürdigerweise sogar in den Retail-Updates findet, obwohl mir die Phantasie fehlt, was es dort bringen soll. Die sollten ja alle neue Zertifikate schon ab Werk haben.

Eine Weile war ich der Ansicht, AVM würde tatsächlich die neuen Zertifikate ähnlich sichern, wie es vermutlich beim Finalisieren der Firmware erfolgt. Wer sich schon einmal den "ptestd" angesehen hat (der stammte wohl mal aus dieser Finalisierung und wurde dann für die interne Kommunikation zwischen ARM und x86 "mißbraucht", jedenfalls ist er ja in der Retail-Firmware nach dem Auspacken zu finden:
Code:
/proc/mtd
Finalize: error in call to fopen()
test_finalize.c
Finalize: error in call to malloc()
Finalize: error in reading /proc/mtd
urlader
Finalize: error: mtd_buffer too small
Finalize: error: mtd entry for 'urlader' not found
/var/ptestd/finalize.cfg
MAIN
HWRevision            overwrite
ProductID             overwrite
SerialNumber          overwrite
annex                 overwrite
usb_device_id         overwrite
usb_revision_id       overwrite
usb_manufacturer_name overwrite
MAC
maca                  overwrite
macb                  overwrite
macwlan               overwrite
macdsl                overwrite
usb_board_mac         overwrite
usb_rndis_mac         overwrite
WLAN
wlan_cal              once
TR069
tr069_serial          overwrite
tr069_passphrase      overwrite
GUIPASS
webgui_pass           overwrite
HWSUB
HWSubRevision         overwrite
MACWLAN2
macwlan2              overwrite
Finalize: WARNING: unknown group flags: %08x
Finalize: groups: %s
Finalize started
/usr/bin/set_config -e /proc/sys/urlader/environment -i
 -u /dev/
mtd1
mtd2
mtd3
mtd4
mtd5
mtd6
mtd7
mtd8
mtd9
Finalize: error: invalid mtd
Finalize: calling '%s'
Finalize: error in call to system() (executing set_config command)
Finalize: set_config return value: %d
Finalize finished
), der hat ja die oben stehenden Zeilen schon einmal gesehen. Vermutlich wird dort ja festgelegt, welche Daten über den ptestd von einem Steuerserver entgegengenommen und über den Aufruf von diesem /usr/bin/set_config am Ende im Bootloader landen, wo sie dann die "personality" der Box bilden. Zertifikat, Kalibrierungsdaten für WLAN und DECT und anderes wird an einer anderen Stelle geschrieben - aber eben wohl auch (bei neuen Boxen) im Rahmen der Finalisierung.

Da stellt sich dann die Frage, wofür wohl das Programm "burnimage" bei den Dateien ist, die nur für die Dauer des Updates auf der Box liegen - und das sowohl im CVC-Image als auch in den Retail-Versionen. Aber das wird wohl wirklich nirgendwo aufgerufen und damit habe ich die Idee, daß da tatsächlich der Bootloader permanent geändert wird, eigentlich wieder aufgegeben.

Dann stellt sich aber eine entscheidende Frage ... in der Firmware 06.50 (lgi+avm) sieht die Initialisierung so aus:
Code:
[...]
if [ -n "${mtd_nvram}" ] && [COLOR="#FF0000"][ -n "${Recover_was_here}" ][/COLOR] ; then
del_mtd_nvram=${mtd_nvram#mtd}
del_mtd_nvram=${del_mtd_nvram%:*}
## erase nvram (formatting) due to preceding recover
nvram_erasestring="mtd ${del_mtd_nvram} erase all"
echo "[config-space/Recover] nvram erasing start ... (${nvram_erasestring})" > /dev/console
echo "${nvram_erasestring}" > /proc/mtd
echo "[config-space/Recover] nvram erasing ... done." > /dev/console
fi
Den entscheidenden Teil habe ich mal hervorgehoben. Diese Variable wird aus einem Zusatz zu "firmware_info" im Urlader-Environment gebildet, dort hinterlegen Recovery-Programm und Factory-Reset eine Zeichenkette "recovered=n", wobei das Recovery-Programm n=2 setzt und
Code:
# [COLOR="#0000FF"]grep recovered setfactorydefaults[/COLOR]
## firmware_info setzen (damit wir nach dem reboot das nachholen k�nnen) [factorydef: recovered=3]
## take care on preventing multiple entrys ',recovered=*'
fw_info=`echo ${fw_info} | sed -e "s/,recovered=[0-9]\+//g"`
[COLOR="#FF0000"]echo "$fw_info,recovered=3" >$CONFIG_ENVIRONMENT_PATH/environment[/COLOR]
bei Werksreset wird eine 3 verwendet. Was da genau steht, interessiert den oben gezeigten Code aber gar nicht, der nimmt alles, was nicht leer ist als Startschuß und löscht die betreffende Partition über den MTD-Treiber. Da beim Online-Update aber die neuen Zertifikate dort abgelegt werden (das darf man aus den Zeichenketten im Update-Programm sicherlich schließen), sind die - zumindest in der Theorie - nach einem Werksreset ebenfalls wieder verschwunden. Damit müßte z.B. irgendeine ältere 6490 (noch mit einer MAC-Adresse, die mit 34 beginnt) eigentlich bei jedem Factory-Reset auch wieder ihre neuen Zertifikate verlieren - erst ab der Retail-Firmware ist da die Sperre gegen komplettes Löschen auch aktiv.

Das sollten gerade diejenigen im Auge behalten, die eine 06.50 (die kdg-Version muß allerdings nicht genauso aussehen) und eine Retail-Version auf der Box und die neuen Zertifikate nicht ab Werk installiert haben. Wenn so jemand auf der Box ein Zurücksetzen auf Werkseinstellungen in Auftrag gibt und im Anschluß startet die 06.50, dann müßten - immer noch in der Theorie - die Zertifikate hinterher weg sein. Vielleicht hat ja jemand eine solche Box (eine ältere vom Provider (s.o.), die aber auf 06.50 aktualisiert wurde, als sie noch im Vertrag war und nun im Besitz des Kunden ist, wenn er die 160 EUR an seinen Provider gezahlt hat) und traut sich dieses Experiment mal zu? Die Zertifikate kann man ja vorher einfach sichern lassen, auch das kann ein Skript auf /var/media/ftp übernehmen, wenn es von /var/post_install aufgerufen wird. Es sollte natürlich jemand sein, der sich dann auch zu helfen weiß ...

Wenn diese Theorie aber stimmen sollte, dann könnte so eine Box eigentlich hinterher gar nicht anders, als über "docsis_init_once" (da wird dann auch die NvramDb wieder initialisiert) ein neues Zertifikat zu generieren und das mit dem alten Schlüssel zu signieren - das "cmcertgen" ist ja vorhanden, wenn auch in einer moderneren Version mit verschlüsselter Datei für den privaten Herstellerschlüssel (der natürlich auch vorhanden ist). Dann meldet sich diese Box aber wieder mit einem alten Zertifikat (hier geht es ja um das AVM-Zertifikat in der Kette und nicht darum, daß das CM-Zertifikat "frisch" ist) und wenn der alte Key am CMTS gesperrt ist, würde so eine Box (auch wenn sie sich im Bestand des Providers befindet) ja nicht mehr "reinkommen" und das nach jedem Zurücksetzen auf Werkseinstellungen.

Da das auch der Benutzer auslösen kann (und ein Angreifer im LAN erst recht), sehe ich gerade nicht so richtig, wie der Provider das alte Zertifikat überhaupt dauerhaft sperren kann, solange er Boxen an diesem CMTS hat, die ihrerseits die Daten nur im Nvram haben und gleichzeitig noch die 06.50 (zumindest eben die lgi+avm, kdg könnte anders aussehen, vielleicht findet sich ja jemand mit einer 06.50 von KDG) als Firmware-Version verwenden. Wenn solche Geräte dann gar nicht erst soweit kämen, daß der Provider sie über den ACS erneut aktualisieren kann (notfalls mit der schon einmal installierten Version) und das geht eben erst nach der Provisionierung, dann müssen die wohl erst noch auf die nächste Provider-Firmware aktualisiert werden (und zwar alle), bevor das alte Zertifikat (und damit der Schlüssel) jemals gesperrt werden kann.

Wenn das tatsächlich stimmen sollte, kann ich mir auch die zurückhaltende Reaktion von AVM ggü. heise.de erklären ... ansonsten wäre das ja irgendwo (Ruf-)Selbstmord, wenn man genau weiß, daß da etwas die Runde machen wird (weil heise.de anfragt) und man steckt trotzdem den Kopf in den Sand.

Soweit ich weiß, ist bei den beiden großen Providern immer noch die 06.50 in Benutzung ... und dann gilt das natürlich nur für die Boxen, die keine Zertifikate (weder alt noch neu) ab Werk haben. Aber das dürfte auch eine erkleckliche Anzahl sein - vermutlich alle diejenigen, deren MAC-Adresse mit 34 beginnt und noch einige aus der C8:0E:14-Reihe ... und von einer Nachfolge-Version für die 06.50 bei den Providern hat man m.E. bisher auch noch nichts gesehen. Da werden die wohl schwer am Testen sein - dann noch den Rollout dazugerechnet und dann wird der AVM-Service wohl doch noch eine Weile laufen müssen. Was aber viel schlimmer ist an dieser Stelle ... wenn AVM nicht zulassen will, daß eine solche Box nach dem Factory-Reset gar nicht mehr funktioniert und dem Provider die Möglichkeit geben will, über den ACS Firmware und Zertifikate zu erneuern, dann muß man an der Stelle auch ein zweites Zertifikat für eine Box ausstellen, die bereits ein anderes erhalten hatte.

Da es für AVM eigentlich keine Möglichkeit gibt (ich kann mir jedenfalls keine vorstellen), ein tatsächlich ausgeführtes Werksreset der alten Box festzustellen, könnte wohl ein Angreifer auch hingehen und an einem geeigneten CMTS mit einer Box desselben Modells und derselben Firmware die Box des Nachbarn klonen (hinsichtlich der CM-MAC, jedoch nicht so, daß er damit den Nachbarn "abhören" könnte, weil das zwei getrennte private Schlüssel sind oder zumindest sein sollten) ... und auch wenn ich das nicht für eine wirkliche Gefahr für den Kunden halte, ist das schon ein erhebliches Problem.

Solange CM-MAC und WLAN-MAC einer FRITZ!Box in einem berechenbaren Verhältnis zueinander stehen (ich kenne nur zwei Zählweisen, hatten wir glaube ich auch schon als Thema - ich hoffe, es gibt mehr), kann der Nachbar nämlich auch die CM-MAC (die er sonst nicht unbedingt kennt - wobei das auf dem RF-Interface auch irgendwo zu finden sein müßte, die CM-MAC ist ja nicht geheim - aber es geht ja auch per Berechnung) zumindest erraten (m.E. mit 50:50-Chance).

Ich halte trotzdem die akute(!) Gefahr des unbemerkten(!) Identitätsmißbrauchs (was Kosten und Ärger bei Gesetzesverstößen nach sich ziehen könnte) für etwas übertrieben ... an demselben CMTS dürfte es (ich müßte auch erst in MULPI nachlesen, also rate ich) gar nicht funktionieren mit zwei identischen MAC-Adressen, wenn die auch zur Adressierung verwendet werden und nicht nur zur Authentifizierung und auch das CMTS sollte eigentlich bemerken, wenn da zweimal dieselbe CM-MAC existiert.

Die Telefonie ist ohnehin nicht so ganz einfach ebenfalls zu klonen, dafür bräuchte man schon die SIP-Credentials aus der Box des Angegriffenen und die wird der wohl kaum freiwillig abliefern. Soweit ich das aus meiner Zeit als KDG-Kunde kenne, wird bei der automatischen Konfiguration der Telefonie über SNMP (PACM) aber auch beim Provider ein neuer Datensatz mit neuen Credentials erzeugt, damit sollte der Angegriffene recht schnell mit der Telefonie offline sein (seine Credentials stimmen ja nicht mehr) und sich beim Provider beschweren. Wenn der dann den Klon nicht findet, ist er selbst schuld - zumindest sollte meines Erachtens feststellbar sein, daß/ob der Klon über ein anderes CMTS arbeitet und damit ist es dann eben nicht der Kunde mit seinem (ja doch an einen Ort gebundenen) Anschluß. Das mit dem Generieren neuer Credentials wäre jedenfalls "best practice", denn auf diesem Wege wären auch irgendwie ausgespähte Credential ja durch ein Werksreset (wenn es der Support macht, dann aber bitte nur mit Zustimmung des Kunden) und die sich anschließende automatische Konfiguration problemlos zu invalidieren.

Auch bei der Suche eines Anschlußinhabers wegen irgendwelcher Ermittlungen sollte es nicht wirklich problematisch sein ... solange der Angegriffene sein Modem nicht immer beim Verlassen des Hauses ausschaltet, sollte es zu jedem Zeitpunkt zwei IP-Adressen für den angeblichen Kunden geben (an unterschiedlichen CMTS, das sollte man schon an der IP-Adresse erkennen) und da das eigentlich nicht sein kann, dürfte eine "blindwütige Ermittlung" auch nicht stattfinden bzw. müßte schnell aufzuklären sein. Immer unter der Voraussetzung natürlich, daß der Provider die Daten in der VDS auch doppelt hat (und seinerseits sorgfältig prüft bei einer Abfrage) - aber da er ja gar nicht weiß, welches der richtige Kunde ist (sonst würde er den anderen nicht reinlassen), wüßte ich gerne, wieso das nicht so sein sollte.

Es gibt also (wieder vermutlich, das sind ja nur theoretische Überlegungen, die gerne jemand widerlegen kann und ich werde es nicht ausprobieren) eine Gefahr des Klonens einer CM-MAC und eines passenden Zertifikats - was schon besch***en genug ist. Aber auch heise.de schrieb ja zurecht von "schlimmstenfalls" und dieser "worst case" braucht schon einige Faktoren, die da zusammenkommen müssen, damit ein Schaden eintreten kann - und am Ende braucht es auch noch einen Provider, der m.E. seine Hausaufgaben nicht richtig macht, wie die Prüfung auf doppelte aktive CM mit derselben MAC, ein Münchener Kunde an einem CMTS in Berlin, usw. - man denke sich selbst eine Plausibilitätskontrolle aus. Aber dafür haben die Provider ja hoffentlich eine "fraud detection"-Abteilung, die sich mit solchen Sachen befaßt und dann geht es nun eben nicht mehr nur um die Telefonie.

Wenn das vorstehend Geschriebene in dem Punkt mit der Notwendigkeit des Fortbestehens des AVM-Services noch für eine ganze Weile stimmen sollte, dann dürfte es auch noch eine Weile möglich sein, seine eigene alte Box mit neuen Zertifikaten zu versehen, so man denn nur an einem passenden CMTS hängt. Meine These wäre es, daß das bei @Kirandia der Fall ist und vielleicht auch noch bei den ganzen Bekannten in der Nachbarschaft (sollte dasselbe CMTS sein). Bei anderen gab und gibt es vielleicht keine alten Boxen im Kabelsegment und dann könnte tatsächlich auch die Absenderadresse so eines Update-Requests wieder eine Rolle spielen, denn eine Adresse sollte sich meines Wissens eindeutig einem CMTS zuordnen lassen (sonst bräuchten die KNB wohl sehr große Routingtabellen, denn der letzte Hop vorm Kunden müßte das CMTS sein) und der Provider könnte die Adresse bei AVM selektiv sperren, wenn der Request von einem CMTS ohne alte Clients stammt. Oder sogar AVM könnte mit einer passenden Firewall (schon iptables mit ipset macht das richtig gut, selbst bei langen Black- oder White-Listen) dafür sorgen, wenn sie denn die Adressen vom Provider kriegen.

Wenn dann aber an so einem "freigegebenen" Anschluß die eine Box neue Zertifikate kriegt und die andere nicht, dann würde ich wieder auf die "Anmeldung" der Boxen im Bestand des KNB bei AVM für das Update zurückkommen wollen. Ich kann die Quelle, von der ich das gehört habe, nicht zitieren und nicht meinerseits überprüfen - vorstellen kann ich es mir ohne weiteres und plausibel wäre es (als ergänzende Maßnahme) auch noch. Allerdings habe ich noch nicht so viele Lösungen von AVM gesehen, wo es mehr als die unbedingt erforderlichen "lines of defense" gab. So eine Liste würde auch erst beim Request greifen, da wäre der 3way-Handshake für die TLS-Session dann schon erfolgt.

Mir ist es jedoch über einen Telekom-Anschluß nicht einmal gelungen, ein erstes SYN/ACK vom AVM-Server zu erhalten und auch kein ICMP-Paket zur Ablehnung, erst recht keinen TCP-Handshake oder gar eine TLS-Connection ... und erst dann käme der Request, der wegen falscher CM-MAC abgelehnt wird. Da ich noch kein (erfolgreiches) Update erlebt habe und selbst nur an einem Telekom-Anschluß mit dem Ergebnis "timeout" nach Senden des ersten SYN leben muß, weiß ich nicht, wie es "richtig" läuft und vielleicht ist es ja wirklich eine Kombination mehrerer Maßnahmen ... nötig wäre es jedenfalls.

Solange also niemand mit einem Anschluß, an dem schon früher das Update funktioniert hat, einen solchen Fehlversuch mal zum besten gibt oder gar mitschneidet (geht nur um die Pakete an sich, der Inhalt kann ruhig verschlüsselt bleiben, wir wollen das ja nur verstehen und nicht nachbauen - jedenfalls ist das nicht mein erklärtes Ziel), solange bleibt das alles vage und ein wenig Stochern im Nebel. Aber bei der Notwendigkeit mehrfacher Zertifizierungen für dieselbe CM-MAC nach Werksreset bin ich mir ziemlich sicher (und habe es mehrfach hin und her geprüft, was da passieren müßte) - ich glaube nicht, daß das Online-Update die Finalisierung ändert.
 
Zuletzt bearbeitet:
Ich möchte noch paar Fakten hinzufügen die eine gewisse Hilfe für diesen Diskus haben könnten:

1. Ich wohne in BW die IP-Adressen bekomme ich von Heilbronn zugewiesen.
2. Die CM-MAC des Routers fängt mit 34 an (falls es schon in diesem Thread erwähnt wurde, dann habe ich es übersehen).
3. Die FB stamm ursprünglich von VF, das Firmware drauf war die Version 06.26 zu dem Zeitpunkt wo ich es kaufte.
4. Ich weiß es nicht ob das Verhalten bei anderen bei denen das Update fehl schlug auch gab und zwar: Nachdem das Fehlermeldung-Fenster mit dem Fehler 106 erschien, hatte ich unten ein Zusätzliches Button "Detei auswählen" (o.ä.) damit konnte ich auch die Firmwaredatei auswählen und das Update wiederholen, man konnte auch eine steigende %-Anzeige am unteren Leiste sehen, das heißt die Datei wurde auch hochgeladen, das Endergebnis war aber leider auch negativ.
 
Solange also niemand mit einem Anschluß, an dem schon früher das Update funktioniert hat, einen solchen Fehlversuch mal zum besten gibt oder gar mitschneidet (geht nur um die Pakete an sich, der Inhalt kann ruhig verschlüsselt bleiben, wir wollen das ja nur verstehen und nicht nachbauen - jedenfalls ist das nicht mein erklärtes Ziel), solange bleibt das alles vage und ein wenig Stochern im Nebel. Aber bei der Notwendigkeit mehrfacher Zertifizierungen für dieselbe CM-MAC nach Werksreset bin ich mir ziemlich sicher (und habe es mehrfach hin und her geprüft, was da passieren müßte) - ich glaube nicht, daß das Online-Update die Finalisierung ändert.

Ich denke ich habe so eine Box (prefix 34, vormals kdg, eigener update auf 6.26->6.50, keine zertifikate im urlader), und wuerde das aus Interesse gerne testen. Allderdings setze ich damit den Familienfrieden aufs Spiel ("WLAN ging doch jetzt, warum fummelst du schon wieder daran herum??"), zumal es hier kein einfacher update ist der in ein paar Minuten erledigt ist (wo man zur Not die "Schuld" auf den Provider schieben kann).
Was ich aber anbieten kann sind ein paar tools (tcpdump, strace, ..) um mal mitzuschneiden was cm_dl_cert denn (im fehler/erfolgsfall) so tut. Ich habe sie mal in mein repository hochgeladen.
 
Hallo,
also das Zertifikatsupdate hat auch bei mir funktioniert. Nachdem meine Box Anfang August "gesperrt" worden ist habe ich mit eine zweite wo die neuen Zertifikate drin waren gekauft und diese verwendet und die "alte" ab in den Schrank.
Nun habe ich die alte aus dem Schrank geholt und wie von[SIZE=2pt] Kirandia[/SIZE] beschrieben die 6.61 geflasht. Kurz mal Mutti besuchen und dort hinter dem Kabelmoden über LAN das Update laufen lassen und sehe da....
FW 6.63
und new/new
Die Box ist eine alte KDG Providerbox und meine Mutter hat auch Kabelinternet bei KGD. Scheinbar ist es also nicht auf UM beschränkt.
 
Gibt's eigentlich eine Erklärung dafür, warum die mtd.img unterschiedliche Größen hat?
Ich habe nochmals nach Post 1047 (die Langfassung) die Datei erstellt und danach noch einmal mit tffs_add_file.

Die step-by-step Variante erzeugt bei mir eine mtd.img mit einer Größe von 29040k.
tffs_add_file erzeugt eine mtd.img mit einer Größe von 262144k.

Bei beiden dauert es rund 20 Minuten, bis die .img erstellt wird.

Beide Dateien wurden auf dem gleichen System erstellt.
Wobei das script ja vermutlich nametable, environment und counter aus den erw. Support-Daten holt und die step-by-step Variante die Daten verwendet, die per EVA geholt wurden und die nametable aus dem repo.
Ansonsten dienen als Basis ja nur die erw. Supportdaten.
 
4. Ich weiß es nicht ob das Verhalten bei anderen bei denen das Update fehl schlug auch gab und zwar: Nachdem das Fehlermeldung-Fenster mit dem Fehler 106 erschien, hatte ich unten ein Zusätzliches Button "Detei auswählen" (o.ä.) damit konnte ich auch die Firmwaredatei auswählen und das Update wiederholen, man konnte auch eine steigende %-Anzeige am unteren Leiste sehen, das heißt die Datei wurde auch hochgeladen, das Endergebnis war aber leider auch negativ.

@ Aux

Punkt 4 war bei mir genauso, als ich die Boxen (KDG und UM), die alle zufälligerweise die 06.24 drauf hatten als ich sie manuell per Entwicklertools auch auf die 06.61 geflasht habe. Ob man beim manuellen Flashvorgang nun nachträglich auf den später zusätzlich angezeigten Button "Datei auswählen" klickte oder nicht war unerheblich. Die Fehlermeldung (106) wurde da ja schon angezeigt nach ca. 7-8 Minuten. Die Firmware war jedoch zu dem Zeitpunkt m.W. nach schon auf die passive Bootpartition geflasht worden.
Nach umswitchen per SETVER linux_fs_start 0/1 und hochbooten der Box war dann auch wirklich die 06.61 in dem GUI zu sehen. Jedoch nach dem check war dann leider (old/old) neben "certificate" im Script zu sehen. Diese Problematik daraus hatte ja jeder, egal ob er bei VF/KDG oder bei UM oder sonst einem anderen KNB provisioniert ist. Nur eben danach beim Online-Update auf die Nachfolge-Firmware 06.62 bzw. jetzt auf die z.Zt. aktuellste 06.63 gab es eben diese Unterschiede, daß eben bei den meisten auch nach dem Online-Update die "alten" Zertifikate nicht erneuert/ersetzt wurden auf die "neuen" wie es eben bei mir der Fall war. Ebenso hatten die meisten auch wieder am Ende des Online-Updatevorganges diese (106)-Fehlermeldung angezeigt bekommen, was bei mir nie der Fall war. (daraus habe ich dann immer gefolgert: keine Fehlermeldung angezeigt worden, ergo -----> neue Zertifikate in der Box, was sich ja dann immer bestätigt hatte) ;)
Ich habe den Post #1115 von lockex10 gelesen und bin ehrlich gesagt froh, dass endlich auch mal jemand anderes außer mir selbst das jetzt zusätzlich bestätigen kann, dass es also wirklich funzt auf die gerade aktuell releaste AVM-FW und (new/new)-Zertifikate dann in der Box sind. Noch dazu, dass es diesmal jemand ist der bei VF/KDG provisioniert ist, und somit eben nicht in NRW, Hessen oder Baden-Württemberg seinen Kabelanschluss hat. :p
Aber auch hier lese ich aus seinem Posting heraus, dass auch er seine Box an einem reinen Kabelmodem dranhängen hatte per LAN1. Also entweder ist das wirklich nun reiner Zufall, oder an der Update-Methode ist wirklich mehr dran als man sich das selber vorstellen bzw. eingestehen kann/muss. :confused:
 
Gibt's eigentlich eine Erklärung dafür, warum die mtd.img unterschiedliche Größen hat?
Beim Zerlegen bleiben nur die "aktiven" Inhalte in den einzelnen Dateien übrig, daher erhält man beim Zusammenbau wieder ein Image, das "bereinigt" ist um alte (inzwischen ungültige, weil durch neuere Daten ersetzte) Einträge ... das TFFS schreibt so lange neue Einträge hinter die vorhandenen, bis ein bestimmter Füllstand erreicht ist oder man per Kommando ein "cleanup" ausführen läßt - dann fliegen ungenutze Bereiche raus.

Da bei "tffs_add_file" nur Einträge hinzugefügt werden (das steht explizit irgendwo in der Datei, daß kein solches "cleanup" gemacht wird), ist dort das Ergebnis in der Regel größer und weil mir das als mögliches Problem geläufig war, gibt es irgendwo die Warnung, daß der freie Platz im TFFS endlich ist. Mir ist auch kein Weg geläufig, wie man von außen eine Box zum Cleanup im TFFS verleiten könnte - nur ein leeres TFFS ist halt automatisch "clean" (mal abgesehen von Environment und Countern).

Wobei mir 20 Minuten für "tffs_add_file" aber extrem viel erscheinen - das kann allerdings auch daran liegen, wieviele Einträge der TFFS-Dump in den Support-Daten tatsächlich hat. Da es keinen anderen Weg gibt, als sich vom ersten bis zum letzten Eintrag "durchzuhangeln", ist das Suchen des letzten Eintrags (bei der Gelegenheit werden ältere Einträge für hinzuzufügende/zu ersetzende Dateien auch gleich ungültig gemacht) der wirklich zeitaufwändige Teil dieses Skripts. Nun mag es bei mir desöfteren mal ein solches "cleanup" geben (bei AVM deutlich seltener, es soll ja auch der Flash-Speicher geschont werden), aber 20 Minuten sind schon extrem viel in meinen Augen. Wenn das bei mir auch so wäre, hätte ich wohl schon lange nach Optimierungen gesucht - bisher war Ausführungsgeschwindigkeit kein wirkliches Thema, auch wenn ich schon mal ein paar Dateizugriffe versucht habe zusammenzufassen.

Wahrscheinlich wäre das auch alles kein Thema, wenn ich nicht versucht hätte, beim "tffs_add_file" (und bei den yf-Funktionen) auf POSIX-Kompatibilität zu achten und keine überlangen Shell-Variablen zu verwenden. Wenn dann bei POSIX nicht mal ein vernünftiges "substring" möglich ist (ohne awk oder ähnliches) und ich auf "sed" für jede dieser Operationen zurückgreifen muß, dann ist das eben auch extrem langsam. Eine Shell, die mit Zeichenketten von 768K (384 KB TFFS bei zwei Zeichen pro Byte in hex auf einer 7490, bei 512 KB TFFS eben noch mehr) umgehen kann und dort per "${x:n:m}" Teilzeichenketten bereitstellen kann, macht das gleich wieder schneller, weil man mit einem einzelnen Lesezugriff alles in eine Variable lesen könnte und dann dort auseinandernehmen.

Wer sich langweilt, kann ja den Skript-Ablauf in ein C-Programm (oder irgendetwas anderes Sinnvolles, fast alles dürfte schneller sein - braucht dann aber wieder passende Tools und mein Skript soll erklärtermaßen auch auf originaler AVM-Firmware laufen) gießen ... ich habe mir diese blöde "dash" auch nicht ausgedacht und hier tatsächlich (weil viele angeblich Ubuntu oder ein anderes Debian-System benutzen sollen) mal versucht, bei POSIX zu bleiben - das macht es nicht gerade schneller, wenn man ständig Umwege gehen muß. Das fängt schon beim "base64" an und die Shell ist nicht gerade dafür prädestiniert, byteorientierte Operationen auf Dateien und Variablen auszuführen, dazu gibt es normalerweise passende Tools und Filter - nur fehlt eben auf einer AVM-Firmware bereits "awk", von anderen Sachen ganz zu schweigen. Wenn ich das auf der Box dann mit Lua machen würde (die konkrete Sprache ist mir ohnehin Bummi), fehlt das wieder auf anderen Rechnern - ich habe aber keine Lust, für jede Plattform eine eigene Lösung zu schaffen.

Diese ganzen Tools sollen eigentlich (mit Ausnahme von "modfs") auch eher nur zeigen, wie es funktioniert ... das habe ich aber auch oft genug betont und wenn jemand die Arbeitsschritte seinerseits in "schneller" implementieren will, dann nur zu ...
 
Die Box ist eine alte KDG Providerbox und meine Mutter hat auch Kabelinternet bei KGD. Scheinbar ist es also nicht auf UM beschränkt.

@ lockex10

Hi,
könntest du vllt. nur mal den 1. Code der Seriennummer und das gleiche für die CM MAC-Adresse von dein er VF/KD-Providerbox hier posten? Also wie gesagt nicht den kompletten Code.
Als Beispiel wie ich das gerne sehen würde:

z.B: Seriennummer F165
z.B. CM MAC: 34

Nur mal rein Interessehalber, weil ich hier eine VF-Homebox3 habe die sich nicht online updaten lies. Vllt. besteht ja doch auch ein Zusammenhang was das Herstellungsdatum der Box sowie der 1. Code des MAC-Adresse betrifft.
 
@kirandia:
box ist seit heute unterwegs. vlt hat peter oder fesc ja och nen tipp für strace oder tcpdump mitschnitte dabei...
 
Nabend @Kirandia

Ich hab eine 6490

Mit Seriennummer: F223
und CM Mac: C8

welche nach dem Update von 6.23 (KDG) auf 6.62 sich zwar per IP Client an einem DSL Anschluss auf 6.63 Updaten lies aber immernoch old/old Zertifikate hat.

Bei einer 6490 welche ich geupdatete habe, wurden die Zertifikate geupdatet (war eine KDG mit 6.26)

Ich habe etwas den Überblick verloren, wie so einige, wollte mich aber gerne langsam näher mit der Materie FritzBox vertraut machen.

Falls ich mit dieser Box (6.63 ehemals KDG mit old/old) bei etwas behilflich sein kann - bin ich gerne bereit die nötigen Daten zu liefern.
 
Zuletzt bearbeitet:
2. Die CM-MAC des Routers fängt mit 34 an (falls es schon in diesem Thread erwähnt wurde, dann habe ich es übersehen).

@ Aux

Tja das gleiche habe ich heute auch mit einer VF-Box gehabt. Da fängt die CM MAC ebenfalls mit 34 an und die Seriennummer beginnt mit F162. Lt. deinem hier geposteten FritzBox Herstellungsdatum-Link wurde sie somit am 14.04.2015 hergestellt.
Kannst ja mal vergleichen mit deiner Box die beim Online-Update in die Fehlermeldung (106) reinrennt und sich somit die neuen Zertifikate nicht holt.
Ist jetzt bei mir die 1. Box die genau das gleiche Problem aufweist. Mich wundert das echt, nachdem es bei 4 KDG-Boxen und 2 UM-Boxen ohne Fehler geklappt hat.
Die Box habe ich heute von einem Forum-Mitglied zugeschickt bekommen (es war aber nicht noob_noob) der hat ja eine Wilhelm Tell-Providerbox. Die Box hatte auf der 0 die 06.61 und auf der 1 die 06.63. Aktiv war die 0 und somit hab ich dann auch wieder versucht online per Lan1-Methode der Box das 06.63-Update einzuspielen damit sie die bestehende 06.63 mit den alten Zertifikaten überschreibt/ersetzt und das gleiche was die alten Zertifikate betrifft. Aber.... nichts wars mit Erfolg.
Jetzt bin ich natürlich total konfus. Das einzige was ich bemerkt habe ich dass seit ca. 3 Wochen an meinem UM-Anschluss nicht mehr die zugewiesene IP habe, die ich noch davor hatte und das seit ich meine eigene Box erfolgreich bei UM hab provisionieren lassen. Hat UM da etwas evtl. etwas geändert ? :confused: Vorher hatte ich immer im Wechsel, entweder die 109.XX.XXX.XX oder die 149.XX.XXX.XX. Seit eben ca. 3 Wochen jetzt die 37.XX.XX.XX. Kann das ein Grund sein oder doch eher unerheblich, weiss es halt nicht.

- - - Aktualisiert - - -

Falls ich mit dieser Box (6.63 ehemals KDG mit old/old) bei etwas behilflich sein kann - bin ich gerne bereit die nötigen Daten zu liefern.

@ stoney0815

Hi,

na da hast du mich grad hier online im Forum beim posten erwischt. Hast ja den Post unter dir #1122 bestimmt auch gelesen. Klar kann sowohl ich als auch jeder andere hier Hilfe oder Tips, bzw. wie du schreibst "die nötigen Daten zu liefern" gebrauchen. Dieses unterschiedliche OnlineUpdate-Phänomen wirbelt hier alles durcheinander was Vermutungen, Thesen, Meinungen, Erfahrungen usw. rund um die Zertifikate betrifft.

- - - Aktualisiert - - -

@kirandia:
box ist seit heute unterwegs. vlt hat peter oder fesc ja och nen tipp für strace oder tcpdump mitschnitte dabei...


@ noob_noob

Na toll, freue ich mich ja glatt drauf. :D Mal sehen was deine Box macht wenn ich ihr die LAN1-Methode spendiere.
Seit heute weiss ich echt nicht mehr was Sache ist. Deshalb kann ich dir keine Garantie geben ob das mit den Zertifikaten jetzt noch geht. Hab keinen blassen Dunst warum es heute zum. 1. mal ----> siehe diesen Post #1122 nicht geklappt hat.
Meine UM-Box mit jeweils 06.62 und 06.63 und (new/new)-Zertifikaten kann ich nur mit demjenigen tauschen, mit dessen Box es hinhaut mit den neuen Zertifikate. Irgendwo auch verständlich, oder ? ;). Brauche ja eine nicht UM-Box für meinen Kumpel die sich eben auch bei UM provisionieren lässt und eben die neuen Zertifikate enthält in der FW, nicht dass UM irgendwann auch bei uns in Baden-Würtemberg diese Boxen dann seitens der zuständigen CMTS aussperrt oder erst gar nicht mehr provisioniert falls noch (old/old)-Zertifikate vorhanden sind.
Ich geb jedem Bescheid, entweder hier im Forum oder per PN. Mehr kann ich nicht machen. Somit stehen drei Boxen gegen eine zum Tausch. Würde sie jedem von euch dreien gönnen, aber geht halt leider nicht. Sollten alle Boxen sich absofort nicht mehr mit den neuen Zertifikaten updaten lassen, soll ich sie mit keinem von euch dreien tauschen. Lt. der Ansage von meinem Kumpel, schliesslich ist die UM-Box sein Eigentum. Ich mache das nur für ihn hier, weil er eben für sowas keine Lust, Zeit und den Kopf dazu hat. :cool:
 
Zumindest restaurieren die letzten berichteten Ergebnisse dann ein Stück meines Vertrauens in die Leute bei AVM ... das klingt ja immer mehr nach einer Kombination mehrerer Faktoren und wenn die nicht alle passen, gibt es auch (wie ich es schon länger immer wieder behaupte hier im Thema) kein neues Zertifikat.

Das Thema ist sensibel genug, damit man sich da ausreichende Gedanken um eine korrekte Absicherung (im Rahmen des Machbaren und schon das begrenzt die Möglichkeiten erheblich) machen dürfte und wenn man erst einmal so richtig "ins Klo gegriffen" hat, wie es bei AVM mit dem privaten Schlüssel in der Firmware der Fall war, dann würde ich mal eine sehr intensive Beschäftigung mit der Frage, wie man es besser macht und das Ganze wieder "glattzieht", unterstellen wollen ... ansonsten wäre das alte Sprichwort, daß man aus Fehlern lernen könne, an AVM vorbeigegangen.

Und auch als Einäugiger unter den Blinden (bei regelmäßigen Updates der Firmware) darf man eben das Vertrauen der Kunden nicht völlig verspielen ... wenden die sich am Ende ab und landen auch beim "Smart Home" bei anderen Lösungen, wird es noch viel enger. Wenn man sich nur mal überlegt, wieviel AVM wohl mit neuen Routern umsetzen kann (1 Router pro "Durchschnittshaushalt", ca. 130-250 EUR Straßenpreis, je nach Modell) und auf der anderen Seite mit SmartHome-Zubehör (45-50 EUR pro DECT!200, die 210 und den 300 (HKR) gibt es ja wohl noch nicht), wo man ja in aller Regel nicht nur ein Gerät braucht, dann würde ich mal vermuten, daß ein nicht unerheblicher Teil des Umsatzes inzwischen gar nicht mehr mit FRITZ!Boxen (mal den ganzen anderen FRITZ!-Kram außen vorgelassen, das dürfte nun wieder weniger machen als bei den Boxen) gemacht wird, sondern mit anderer Technik und wenn der Kunde keine FRITZ!Box mehr will, kann er mit dem Rest auch nichts mehr anfangen. Wenn also das Vertrauen in die Sicherheit der FRITZ!Boxen leidet und das zu weniger Umsatz bei den Boxen führt, dürfte sich eine solche Einbuße nicht nur auf die Boxen selbst beschränken und das ist vermutlich wesentlich schmerzlicher.

Ich bin ohnehin überrascht, warum man bei AVM (trotz der bekannten Probleme mit dem "cmcertgen", auch wenn das natürlich in der Retail-Firmware gar nicht mehr vorhanden ist - und ja auch nicht gebraucht wird) nicht erst einmal die Probleme mit dem Zertifikat mit Hochdruck ausgeräumt hat, bevor man sich an die Retail-Version machte. Die Provider mußten ohnehin selbst jede Menge zusätzliche Vorkehrungen in ihren Netzen für den 01.08. treffen - dabei von AVM noch einmal aus- und nachdrücklich auf die Probleme und die Notwendigkeit des (zeitnahen) Updates aller alten Geräte hingewiesen (und rechtzeitig eine Version auf die Provider losgelassen, die nicht bei jedem Werksreset löscht - so sich das als Vermutung bestätigt) und die Provider hätten vermutlich auch gerne auf die nun eingetretene Aufmerksamkeit verzichtet. Wenn es von AVM keine passenden Boxen zum 01.08. gegeben hätte (und man das vorher angesagt hätte), dann hätten die Provider auch wieder mehr Zeit für die Updates gehabt - denn so viele andere denkbare DOCSIS-Geräte gab (und gibt) es nicht, daß dann die Kunden ab dem 01.08. scharenweise zu eigenen Geräten hätten greifen können.

Aber es war wohl so etwas wie "Goldgräberstimmung" ... es gab keine Konkurrenz-Produkte (jedenfalls nicht nennenswert und das ist wohl bis heute so) und auch jetzt noch sehe ich einen gewissen Widerspruch zwischen dem Ladenpreis einer 6490 (180 EUR im Versandhandel) und der Summe, die m.W. KDG/VF für eine nicht zurückgegebene HomeBox3 verlangt (160 EUR, wenn es sich nicht geändert hat). Das setzte natürlich auch die Provider einem erheblichen Zeitdruck aus, wenn die eigenen Kunden ab dem 01.08. sofort auch wirklich ("in Massen" wäre vermutlich übertrieben, aber am Beginn schon ein wenig "in Scharen", zumindest genug, damit das von Hand nicht mehr zu regeln war) mit eigenen Endgeräten, die der Schnittstellenbeschreibung entsprechen, anrücken konnten. Hätte man noch von August bis Oktober wirklich alle Energie in die Updates stecken können, wäre das Thema vielleicht bereits erledigt.

Oder man hätte sich ja auch theoretisch einfach ein weiteres Herstellerzertifikat ausstellen lassen (die Preise kann man bei Excentis nachlesen) und dann die Retail-Modelle mit diesem Schlüssel signieren können. Dann wäre es für den Provider wesentlich leichter gewesen, die Retail-Boxen von den eigenen oder denen anderer Provider zu unterscheiden und die Kunden, welche zuerst ab dem 01.08. mit einer Provider-Box provisioniert wurden und dann im Nachgang wieder rausflogen, hätte es erst einmal nicht gegeben bzw. die Erklärung "Ist die falsche Artikelnummer ..." hätte einen realen Hintergrund gehabt (abseits des Aufklebers der Box). Letzten Endes ist es ja dadurch erst so richtig "aufgeflogen", daß es halt unterschiedliche Zertifikate gibt ... ich glaubte Anfang August ja auch noch daran (irgendwo hier am Anfang), daß man die Retail-Boxen am Zertifikat erkennen könne (da hatte ich noch keine Retail-Box gesehen).
 
Zuletzt bearbeitet:
Moin,

ich verfolge seit einigen Tage sporadisch diesen Thread.

Ich habe als Kunde von UM vor zwei Wochen eine eigene 6490 (2000 2778, Seriennumer H305, CM-MAC C8 ) in Betrieb genommen. Automatisches Update von 6.62 auf 6.63 lief direkt am UM-Anschluss problemlos.
Hier steht noch die weisse Original-UM-6490 (2000 2689) mit Seriennummer H093, CM-MAC C8 und OS 6.50 (lgi).

Bevor diese zurück an UM geht möchte ich mir vorer noch eine weitere 6490 als Cold-Stadby-Gerät mit aktuellem OS vorbereiten. Dazu habe ich mir bei den Ebay-Kleinanzeigen für kleines Geld eine 6490 von Kabel Deutschland (kdg) gekauft. Ich erwarte sie in den nächsten Tagen per Post.

An die Protagonisten dieses Threads: gibt es irgendetwas, was ich aus den bereits vorhanden Boxen (bzw. aus der zukünftigen 3. Box) auslesen soll, um so die Arbeit in diesem Thread unterstützen zu können.
 
Also hier die Daten meiner Box:
Seriennummer F281 (Herstelldatum 06.07.2015)
CM MAC: C8:0E
 
irgendwas macht um (zumindest bei mir)...gestern nacht wurde meine 6.62 box offline und wieder online genommen, dem voraus ging laut log:

Automatische Einrichtung und Updates für dieses Gerät durch den Dienstanbieter nicht möglich: Verbindung zum Autokonfigurationsserver fehlgeschlagen.

und seit dem Neustart regelmässig:

Automatische Einrichtung und Updates für dieses Gerät durch den Dienstanbieter nicht möglich: Timeout


wo konnte man das nochmal dis und enablen dass der Dienstanbieter Änderungen machen darf/kann, irgendwo konnte man das doch einstellen wenn ich mich richtig erinnere.
ich würd das gern mal ausprobieren ob dies hinkriegen die certs zu erneuern bzw es denen gestatten dies zu tun.

bisher steht immer noch auf old/old habs grad gechecked.

danke schonmal für die hilfe
 
gibt es irgendetwas, was ich aus den bereits vorhanden Boxen (bzw. aus der zukünftigen 3. Box) auslesen soll, um so die Arbeit in diesem Thread unterstützen zu können.
Ich nehme zu jeder Zeit gerne extrahierte Firmware entgegen ... meine "Sammlung" existiert auch nicht nur aus reiner Begeisterung für's Archivieren von Dateien an sich. Es gibt immer mal wieder die Notwendigkeit, den Zeitpunkt einer Änderung irgendwie genauer einzugrenzen und da kann ein Blick in ältere Versionen hilfreich sein - auch kann man dann genauere Aussagen zum Verhalten der Firmware treffen (weiter oben ist z.B. das Verhalten der kdg-06.50 nur extrapoliert, wenn es ums Factory-Reset geht).

Ich würde trotzdem (im Moment noch) keine "Liste" veröffentlichen wollen, welche Versionen ich nun genau habe ... das "Abstreichen" einer Wunschliste würde auch zusätzliche Arbeit machen. Wer sich dazu in der Lage sieht, die Firmware aus einer 6490 auszulesen, bevor er sie mit einer anderen Firmware überschreiben läßt, der kann dazu gerne das (etwas ggü. der in irgendeinem Thread hier bereits veröffentlichten Version geänderte, nun wird auch ein fehlendes System im alternativen Satz richtig behandelt, wie es bei einer fabrikneuen Box ohne bisheriges Update auftritt) Skript verwenden, ich habe es mal ins Repository eingecheckt: https://github.com/PeterPawn/YourFritz/blob/master/autoupdate/save_system.sh

Kopiert man dieses Skript (und ein weiteres, komme ich gleich drauf ... ehe jemand jetzt hier schon loslegt) auf seine Box in die Wurzel des NAS-Speichers, wird es bei einem Neustart (unter der Voraussetzung, daß man die Änderungen im TFFS - wie hier weiter vorne im Thread beschrieben - ausgeführt hat) ausgeführt. Es sichert den kompletten Inhalt der Box (alle eMMC- und alle MTD-Partitionen, aber natürlich nicht die ~1.4 GB des NAS-Speichers) unterhalb von /var/media/ftp (das ist die Wurzel des NAS-Speichers) in jeweils einem "ATOM"- und einem "ARM"-Unterverzeichnis.

Eigentlich ist es dafür gedacht, sowohl auf dem ARM- als auch auf dem x86-Core ausgeführt zu werden ... das funktioniert aber beim Aufruf über die "provideradditive.tar"-Lücke nicht automatisch, weil der Node 29 nur auf dem ARM-Core verarbeitet wird und daher nur dort die /var/post_install auch ersetzt wird. Daher gibt es noch ein weiteres Skript (https://github.com/PeterPawn/YourFritz/blob/master/autoupdate/dump_firmware), das man unter dem Namen "run_update" auf dem NAS-Speicher ablegen muß, wenn man es (ohne Änderungen an weiteren Dateien) ausführen lassen will. Dieses Skript startet das Auslesen der Firmware nacheinander für den ARM- und den ATOM-Teil und erstellt hinterher (daher auch das "nacheinander", weil das Ende des Kopierens auf dem x86-Core sicher festzustellen mehr Aufwand erfordert) aus den beiden Verzeichnissen noch ein gemeinsames tar-File (saved_firmware.tar), das man nach dem Restart über die NAS-Funktionen auf ein anderes System laden kann.

Das Auslesen wird von bestimmten LED-Anzeigen begleitet ... da der gesamte Vorgang einige Zeit in Anspruch nimmt. Während das ARM-System gesichert wird, blinkt die Info-LED grün, während der Sicherung des x86-Systems die WLAN-LED. Das anschließende Packen als Tarball wird mit einer schnell rot blinkenden Info-LED signalisiert. Also nicht ungeduldig werden, das Dateisystem hat jeweils 64 MB und der Kernel 8 MB ... dazu kommen die SPI-Partitionen. Das macht pro System knapp 150 MB beim Sichern und dann eben 300 MB beim Packen. Da das Packen auch noch auf dem ARM-Core läuft und über NFS auf den NAS-Speicher zugreift, dauert auch das Packen der 300 MB ohne Kompression etwas.

So eine Sicherungsdatei ist - nur nebenbei - eigentlich nie falsch ... wer weiß schon, wann er sie mal brauchen könnte, weil er selbst Mist gebaut hat und seine Box gar nicht mehr starten will. Wer dann von einem Profi Hilfe in Form eines Hardware-Zugriffs (über die (E)JTAG-Schnittstelle auf dem PCB) überhaupt nur theoretisch in Anspruch nehmen will (ich habe auch keine weiteren Infos für JTAG beim Puma6, ehe jemand fragt), der braucht den Dump seines Bootloaders ... der ist auch schon der einzige "konstante" Inhalt in so einer FRITZ!Box (ein denkbares Update des Bootloaders durch AVM lassen wir mal außen vor - spielt bei den Überlegungen keine Rolle).

Damit sind wir dann auch beim Inhalt des Dumps ... nur die Dateien, die mit "kernel" oder "filesystem" beginnen, bilden das FRITZ!OS. Alle anderen Dateien (die beginnen mit "mtd") enthalten den SPI-Flash-Inhalt und die sollte man niemand anderem überlassen.

Wer mir also Firmware-Dumps zukommen lassen will, der packt entweder noch einmal selbst die Dateien in "ARM" und "ATOM" und läßt die "mtd*"-Dateien weg oder er packt das "saved_firmware.tar" um (das geht notfalls auch mit 7-zip unter Windows).

Das Resultat ist dann in der Regel immer noch zu groß, um als Anhang einer E-Mail gesendet zu werden ... da bieten sich dann 1-Click-Hoster an. Wer die Datei vorher verschlüsseln will, findet meinen GPG-Key ebenfalls im GitHub-Repo. Ich bedanke mich hier schon mal für jedes Firmware-Angebot, was mich aufgrund dieses Beitrags erreicht ... und würde das dann gerne bei jeder einzelnen Mail vermeiden wollen. Wer gleich noch dazuschreibt, welche Firmware-Versionen sich in seinem Angebot verbergen, der nimmt mir wieder die Arbeit ab, das selbst feststellen zu müssen nach einem Download.

Wenn ich nicht auf jede Mail reagieren muß, erhält auch der Einsender kein Feedback, ob ich die Firmware nun schon hatte oder nicht - damit wird keiner bevorzugt oder benachteiligt und muß sich im Nachhinein ärgern, daß er sich die Arbeit umsonst machte. In nicht allzu ferner Zukunft (nach dem nächsten Update der Provider-Firmware, wo sich dann ohnehin die Frage stellt, ob AVM endlich gegen die "provideradditive.tar"-Lücke auch etwas unternimmt) werde ich eine Liste der Firmware-Versionen ins Repo stellen, damit man vorher nachsehen kann, ob ich die betreffende Firmware bereits habe. Wer ohnehin die eigene Box aus diesem Wege sichert, hat nicht allzuviel zusätzlichen Aufwand (Umpacken des Tarballs, Komprimieren (macht hier dann auch Sinn, mache ich auf der Box nur nicht, weil der ARM-Core dafür ewig brauchen würde), Upload zu einem Hoster und eine E-Mail an mich, am besten an das admin-Postfach in der yourfritz.de-Domain) und wenn man mal davon ausgeht, daß er sich damit für geleistete Vorarbeiten bedanken will, ist auch eine ggf. umsonst erbrachte Arbeit an dieser Stelle (weil ich die Version bereits habe) hoffentlich zu verschmerzen.

Einige Versionen zähle ich aber mal auf, die habe ich ggf. sogar mehrfach, da wäre die Arbeit definitiv umsonst:

  • 141.06.08 vom 17.07.2014 - project: 28417
  • 141.06.10 vom 04.09.2014 - project: 28654
  • 141.06.22 vom 30.01.2015 - project: 29874
  • 141.06.24 vom 20.04.2015 - project: 30308
  • 141.06.50 vom 02.03.2016 - project: 32615 - Brandings: lgi+avm
Erst Versionen nach der 06.24 haben dann die unterschiedlichen Brandings (1x lgi+avm, 1x nur kdg), ob es die 06.26 bei KDG jemals offiziell gab, weiß ich gar nicht.

Eines habe ich noch vergessen ... das Kopieren vom NAS sollte man vor einem Update machen - muß man aus irgendeinem Grund das System auf Werkseinstellungen zurücksetzen, wird (ohne Gegenmaßnahmen) dabei auch der NAS-Inhalt in der eMMC-Partition gelöscht und ich kann aus eigener Erfahrung berichten, daß das immer genau zum falschen Zeitpunkt notwendig wird, wenn man noch ganz, ganz wichtige Daten im eingebauten Speicher liegen hatte.

Ich weiß ohnehin nicht mehr so genau, ob die Anleitung von @tetzlav auch noch erwähnt, daß man nach dem erfolgreichen Update auf eine neuere Firmware-Version über die Änderung der /var/post_install auch unbedingt daran denken sollte, die Datei "newfirmware.image" vom NAS-Speicher zu löschen - sonst macht die Box bei jedem Neustart auch ein neues Update und überschreibt ggf. ältere Versionen, die man gerne aufheben möchte.

Alternativ kann man natürlich auch das "run_update"-Skript löschen oder die "provideradditive.tar" wieder entfernen ... aber bitte nicht vergessen, daß ein Zurücksetzen auf Werkseinstellungen das gar nicht kann - das entfernt höchstens die Dateien im NAS-Speicher. Das verhindert zwar auch ein wiederholtes Update, aber nicht jeder setzt vielleicht seine Box nach dem Update zurück. Wer nur das "run_update"-Skript länger als nötig im NAS-Speicher liegen läßt (und die "newfirmware.image" löscht), kann auch eine unangenehme Überraschung erleben ... gibt es bei AVM dann die nächste Firmware und die Box findet die bei einem Neustart, wird auch die einfach installiert und überschreibt die inaktiven Partitionen.

EDIT: Ach ja ... falls jemand der Meinung ist, ich würde einfach blind hingehen und irgendwelche tar-Files aus unbekannter Quelle unbesehen entpacken: Das ist definitiv nicht so. Ich habe einen passenden Filter, der nur die "regular files" aus so einem Tarball zieht. Es gab auch tatsächlich schon Einsender, die es nicht wirklich gut mit mir meinten.

- - - Aktualisiert - - -

Auch noch vergessen, obwohl es sich sicherlich von selbst versteht: Die Firmware-Updates von AVM für die Retail-Boxen (ab 141.06.61) stehen natürlich nicht in der Liste, sind aber trotzdem bereits vorhanden. Der Unterschied zu einer Provider-Firmware würde auch nicht nur darin bestehen, daß die Retail-Version nur ein "avm"-Branding hat. Wer also auf seiner Provider-Box nach einem (providerseitigen) Update eine 06.6x finden sollte ... die hat vermutlich mit der Retail-Version nicht viel gemein und daher gilt das dann natürlich nicht für eine solche Firmware.
 
Zuletzt bearbeitet:
Bei der KDG gab es definitv auch eine 6.26 Firmware, ich habe so eine glaube auch noch zuhause rumliegen. Ich werde am Wochenende mal hinsetzen und die Firmware auslesen und dir zukommen lassen, wenn das ok für dich ist. ;)
 
wo konnte man das nochmal dis und enablen dass der Dienstanbieter Änderungen machen darf/kann, irgendwo konnte man das doch einstellen wenn ich mich richtig erinnere.

@ Daniel Ventura

das kannst du unter: Internet ---> Zugangsdaten ---> Anbieter Dienste
Gibts es 4 Menüpunlte die man anklicken kann und Häkchen rein oder rausmachen kann.

Ich nehme an du hast nicht Ansicht: Erweitert unten links aktiviert. Bei dir ist bestimmt noch auf Standart gestellt. Deshalb wird dir diese Option da noch gar nicht angezeigt. :cool:
 
Ich weiß ohnehin nicht mehr so genau, ob die Anleitung von @tetzlav auch noch erwähnt, daß man nach dem erfolgreichen Update auf eine neuere Firmware-Version über die Änderung der /var/post_install auch unbedingt daran denken sollte, die Datei "newfirmware.image" vom NAS-Speicher zu löschen - sonst macht die Box bei jedem Neustart auch ein neues Update und überschreibt ggf. ältere Versionen, die man gerne aufheben möchte.

Vielen Dank @PeterPawn für den Hinweis. Ich wollte dich eigentl. dazu nochmal Fragen: Wäre es nicht möglich die Datei newfirmware.image nach dem update zu löschen/umzubenennen? Ich hatte es damals beim ersten Mal vor dem reboot gerade noch rechtzeitig bemerkt dass die Datei da ja immer noch rumliegt. Ich werde in meinem Listing nochmal explizit darauf hinweisen...
 
@tetzlav:
Da muß ich noch einmal gründlich drüber nachdenken ... so ein zusätzliches "rm" oder "mv" könnte sich ja jeder selbst einbauen.

Ich hatte ja geschrieben, daß ich das in sehr ähnlicher Form schon länger verwende ... da wurde die Firmware wirklich umbenannt, damit die als Archiv herumlag und bei Problemen einfach wieder auf eine frühere Version gewechselt werden konnte. Auch war da noch die Abfrage einer Variablen (kernel_args) eingebaut, die beim Update zurückgesetzt wurde und das eigentlich erst richtig "scharfschalten" sollte, wenn ein Update auszuführen war. Die läßt sich leicht über /proc/sys/urlader/environment setzen und über den Bootloader, wenn es Problem gibt und man auf die vorhergehende Version zurück will, weil die Box irgendwo hängenbleibt bei der Initialisierung des GUI/NAS.

Ich habe das ja für's Repo etwas abgespeckt, damit die Benutzung nicht so kompliziert ist - wenn mir nichts einfallen sollte, was dagegen spricht, könnte man sicherlich zumindest nach der Installation umbenennen (bisher machte ich das mit der Timestamp bei der Installation, sollte aber auch ohne gesetzte Zeit - das gab es bei mir nicht - nur selten Konflikte geben) und das im Repo darauf ändern. Sind halt nur mehrere denkbare Ausgänge, aber nach /var/install mit 0 oder 1 sollte das passen. Bei mir übernimmt das normalerweise das (eigene) /var/install selbst mit dem Umbenennen, deshalb fehlt das auch "außen rum" bisher.
 

Zurzeit aktive Besucher

Statistik des Forums

Themen
246,149
Beiträge
2,246,980
Mitglieder
373,668
Neuestes Mitglied
Stripi
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.