Fritzbox 6490 Cable Firmware Update?

@PeterPawn : wilhelmtell, doch da ist nen tffs geprockel notwendig weil provider additive box. du hast doch von mir sogar die provider additve.tar meiner box und nen dump meiner 6.24 haben wollen da du sie noch nicht in deiner sammlung hattest ...
@Flole : ich hab das son kandidaten mit old/old, ne flash klammer und nen docsis modem hab ich auch ... hilfe ? :p gern per pm wenn du dazu nicht öffentlich in die tasten hauen willst...
 
Zuletzt bearbeitet:
Die Box ist tatsächlich noch gestartet, aber da war ein old/old. Ich fange jetzt einfach mal wild mit einer Vermutung an: Eventuell ist ein Bankwechsel dafür verantwortlich, auf der alten Bank war eine alte Firmware, die ist irgendwie in das recovered gesprungen (oder der certgen hat gemerkt das cert und die nun neue "leere" Mac nicht passen, keine Ahnung ob das sein kann) und schon waren sie weg bzw. old/old.
 
@PeterPawn

Ich kannte das Problem vor dem Kauf, das die Cableboxen nicht laufen weil es meistens Mietboxen sind. Etliche Freunde von mir sind reingefallen. Deshalb war es mir sehr wichtig das die Box nicht im Gleichen Netz lief aber auch gekauft worden ist.

Das mit guten Menschen meinte ich ehrliche die sich bemühen nach den Gesetzen zu Orientieren.
 
Zuletzt bearbeitet:
Ich merke, ich muss noch viel lernen. :(

Das hab ich nur gemacht weil sie trotz entbranden und firmware update sich nicht verbinden wollte.:(

Deshalb konnte ich mir ein bisschen Linux an eignen.:)
 
@noob_noob:
Sorry ... eine "provider"-Variable kann ich auch problemlos über ein FTP-Kommando löschen oder ändern, dazu brauche ich gar kein TFFS-Image.

Ebenso steht in der Anleitung, der @Nob88 nach seinen eigenen Worten gefolgt ist (der Link von ihm steht in #2149), überhaupt nichts davon, daß man sich irgendwie sein eigenes TFFS-Image bauen müßte ... insofern stimmt auch #2201 eben nicht, wenn es um die Beschreibung geht - da ist das Schreiben eines TFFS-Images gar kein Thema.

Ja, ich war hier am Ende dann wahrscheinlich auf dem Holzweg, was die Frage angeht, woher die Box ihr Zertifikat hat und vielleicht ist das nicht mal tatsächlich gelöscht worden ... was soll ich zu meiner Entschuldigung vorbringen?

Ich ziehe ganz tief meinen Hut vor jedem, der anhand der tatsächlich berichteten Fakten (in diesem Thread und nicht etwa durch irgendwelche zusätzlichen Informationen) erkennen konnte, daß @Nob88 entgegen seiner eigenen Schilderung, welcher Anleitung er gefolgt ist, etwas vollkommen anderes gemacht hat und daß er dabei auch das TFFS neu beschreiben wollte. In der Version der Anleitung von @qwertz.asdfgh, die ich kenne, steht der ganze Teil hinsichtlich des Erstellens eines TFFS-Images noch unter "ToDo".

Mit den inzwischen nachgeschobenen Informationen wäre ich sicherlich auch nicht auf die Idee gekommen, daß hier mit dem Zertifikat etwas nicht stimmen könnte - daß bei der Schilderung auch so einiges nicht wirklich logisch klang, war aber schon vorher klar (siehe Link).

PS: Na ja, was soll man zu der Zertifikat-Geschichte und der Frage, wie das am Ende verschwunden ist, jetzt denken? Wenn man sich das in seiner Gesamtheit verdeutlicht, hätte @Nob88 tatsächlich fast keinen Fehler ausgelassen, den man in so einer Situation machen kann ... aber auch das kriegt man (wenn man wirklich will) ja noch heraus, denn für einen "automatischen" Wechsel des Systems müßte in den gesicherten TFFS-Einstellungen ja zumindest "linux_fs_start" auf "1" gesetzt sein, damit dessen Fehlen dann auch noch ein anderes System aktiviert, das dann gleich noch das Zertifikat entsorgt, indem es die Partition formatiert.

Ob beim Start des CM tatsächlich die MAC-Adresse aus dem Zertifikat geprüft wird oder ob die alte CM-MAC irgendwo in der NvramDb von Intel steht und verglichen wird (wobei das im Intel-Code ja schon wieder komisch wäre, denn das Generieren "on-thy-fly" ist ja eine AVM-Spezialität), müßte man halt mal recherchieren ... andererseits ist das Problem mir eigentlich so egal, daß ich jedem gerne bei der Suche helfe, wenn er etwas nicht versteht, mich aber nicht selbst daran machen würde.
 
Zuletzt bearbeitet:
@PeterPawn

Ich weiß das du das nicht böse meinst, du hast recht ich kann dich voll und gaznz verstehen und bin deiner Meinung.

Macht es nicht Sinn, eine Legale zertifizierte Restaurierungsstation für solche Cableboxen zu eröffnen?

Ich meine, die Leute kaufen solche Mietboxen bekommen sie nicht zum laufen und verkaufen sie praktisch weiter und so drehen sich die Boxen um den Kreis oder werden entsorgt und belasten die Umwelt.
 
Zuletzt bearbeitet:
Hab' doch mal schnell nachgesehen ... es sieht in alter Firmware tatsächlich so aus, als würde in "usr/sbin/docsis_init_once" innerhalb einer Funktion, die wohl "check_avm_ProdDbValues" heißt, eine Prüfung der CM-MAC erfolgen und wenn die nicht paßt zur neu gewünschten, wird wohl wirklich "/bin/cmcertgen" direkt hinterhergeschoben. Dann müßte die Box ja jetzt ein altes Zertifikat für die allererste AVM-OUI (00:04:0e, iirc) haben.

Ein weiterer Grund, warum man sich vor Änderungen an irgendeiner Box erst einmal vergewissern sollte, welches System da gerade in welcher Partition installiert ist - sofern man das Gerät ansonsten noch nicht kennt. Wie man die Inhalte der Partitionen auslesen könnte, habe ich irgendwo in einem Skript (unterhalb von "autoupdate") und dann kriegt man auch ohne sie zu starten heraus, welche Version es jeweils ist (spätestens die "/etc/version" gibt darüber Auskunft).

Was ich dann aber trotzdem nicht verstehe (außer es gab tatsächlich noch zusätzlich ein Formatieren des JFFS2 - woher wäre das dann gekommen) ... wieso sollte "cmcertgen" die Dateien im Download-Verzeichnis unter "nvram" überschreiben? Ich habe zwar kein altes System mehr zur Kontrolle ... aber sollte das "cmcertgen" nicht eigentlich die Dateien direkt in "/nvram/1/security" ablegen und den Inhalt von "/nvram/1/security/download" unangetastet lassen?

PS: So, auch noch mal angesehen ... ja, sowohl "usr/sbin/docsis_init_once" als auch "bin/cmcertgen" greifen nicht auf den "download"-Ordner zu. Damit könnten (wenn nicht doch noch jemandem ein Grund einfällt, warum die Partition neu formatiert wurde) die neuen Dateien tatsächlich noch dort liegen und die "new/new"-Geschichte scheitert nur daran, daß unter "security" am Ende "regular files" für das selbstsignierte Zertifikat liegen und keine Symlinks. Das "bin/docsiscertdefaults" macht jedenfalls mal genau gar nichts (legt also auch keine Symlinks an), wenn die Zertifikate nicht im Bootloader stehen.

PPS: Das heißt also - noch mal ganz deutlich im Klartext - daß es hier tatsächlich noch eine (geringe) Chance gibt ... allerdings braucht man dazu einen Shell-Zugang und es versteht sich von selbst, daß man dann zuvor erst mal das TFFS-Disaster beheben muß.
 
@PeterPawn

Linux und teamviewer sind bereit du kannst von mir aus starten aber nicht mehr heute. GN8
 
Den Shell Zugang gibt es schon lange, aber die Daten sind leider aus irgendeinem Grund weg gewesen. Das ist aber momentan gar nicht das größte Problem, denn es gibt schon Probleme überhaupt einen Sync zu bekommen. Ich hab da ganz stark die Kalibrierungsdaten im Verdacht, oder aber der Anschluss ist völlig verpegelt. Die CMTS hat sich schon mal als Arris identifiziert, aber dennoch gibt es massive Probleme beim Sync (die Zertifikate werden da ja noch gar nicht gecheckt). Wenn der Versuch an einer Leitung wo schon eine 6490 erfolgreich dran hängt auch fehlschlägt dann gibt es nur noch 2 Möglichkeiten die für mich in Betracht kommen:
1. Die Kalibrierungsdaten sind weg und das ist ein Problem für die Box. Da diese ganze Bastelei allerdings erst durch das nicht zustandekommen einer Verbindung gekommen ist würde ich schon fast vermuten das dies nicht der Auslöser ist. Könntest du vielleicht was zu den Kalibrierungsdaten sagen? Also ob die normalerweise im TFFS liegen oder ob die in einer "learning-phase" basierend auf den Anschluss erstellt werden?
2. Die Box bzw. das Modem in ihr hat einen Hardware Defekt
 
Was meinst Du denn nun genau? Die Daten aus der DOCSIS-Kalibrierung beim Finalisieren? Die liegen im Bootloader und sollten auch ganz normal wiederhergestellt werden (beim Starten des ARM-Cores), wenn die in "/nvram/1/..." nicht übereinstimmen mit den finalisierten Daten. Damit hat das TFFS also gar nichts zu tun und diese Art der Speicherung für die Kalibrierungsdaten gilt auch schon für Boxen, die kein Zertifikat bei der Finalisierung erhalten haben - ist also für alle 6490 dieselbe (afaik).

Wobei sich ja auch die Frage stellt, warum man mit einer Box, die kein gültiges Zertifikat hat und auch keines kriegen kann (wenn das JFFS2 schon leer war), überhaupt noch Verbindung zum CMTS aufnehmen sollte.
 
Ja genau die Daten meinte ich. Zumindest das 1 Verzeichnis war da, reingeschaut hatte ich jetzt nicht aber das wird dann wohl auch schon stimmen.

Ich hatte mir daraus Informationen erhofft warum die Box vor den ganzen Änderungen ebenfalls keinen sync Zustande bekommen hat, also ob da möglicherweise doch schon was kaputt war. Gewissermaßen hat das ja auch funktioniert, wenn die Meldung nun auch an nem anderen Anschluss auftaucht ist wohl klar das es einen Defekt im Modem gibt.
 
@Nob88
Wenn der Bootloader der Box erreichbar ist und Du erweiterte Supportdaten erstellt hast, kannst Du das MTD3 /4 selbst wieder erstellen lassen (hab ich auch erst mit Unterstützung von hier erledigt).
Ob die Box ohne die Provideradditiv läuft?

PeterPawn/YourFritz findest Du die nötigen Werkzeuge
 
  • Like
Reaktionen: Priority
@PeterPawn

Ich hab eben mal ein Pull Request für dein eva_get_environment eingereicht das checkt ob eine "dash" verwendet wird und dann einen Fehler ausgibt. Letzendlich war das (in Kombination mit dem ignorieren von Fehlern) einer der fatalen Fehler die Nob88's TFFS geleert haben. Auch ist die ansonsten kommende Fehlermeldung nicht gerade eindeutig im Bezug auf das Problem, ich denke ein bisschen präzisierung kann da nicht schaden. Vielleicht übernimmst du das ja so (oder greifst die Idee anders wieder auf), würde mich sehr freuen. Getestet habe ichs mit busybox, bash und dash.
 
wilhelmtell, doch da ist nen tffs geprockel notwendig weil provider additive box.

Mal eine klitzekleine Frage am Rande in diese kleine illustre Runde hier... ;)

Mal angenommen (rein hypothetisch) man hätte eine (ältere) Cable-Box von AVM (beispielsweise eine 6490, noch ohne das neue CM-Zertifikat im Bootloader) die
  1. ehemals von einem Provider (nehmen wir hier als Beispiel mal den Anbieter wilhelm.tel) stammt,
  2. natürlich legal erworben wurde,
  3. glücklicherweise (irgendwann einmal) bereits das neue Download-Zertifikat erhalten hatte und
  4. ein sogenanntes Provider-Additive enthält, bestehend aus der dazugehörigen Bootloadervariable und der provider.tar im TFFS
(dass dieses hypothetische Beispiel vermutlich der 6490 von @Nob88 sehr nahe kommt ist jetzt wohl einfach mal Zufall :D).

Nun möchte man vielleicht nach dem bekannten De-Brandingprozess (mit installierter aktueller Retail-Firmware) auch noch das Provider-Additive (hier in diesem Beispiel wäre es das von wilhelm.tel) entfernen und da man eine unveränderte Retail-Firmware verwendet ist auch kein Konsolenzugriff möglich (zumindest vermutlich keiner der einfach zu erlangen wäre) um die provider.tar zu löschen.

Die Bootloadervariable kann man ja noch über EVA entfernen aber mangels Recoverytool von AVM ist damit das Provider-Additive ja noch nicht entfernt, auch die Werkseinstellungen zu laden löscht meines Wissens nach nicht das Provider-Additive.
Klar, nun könnte man sich ja das TFFS-Image neu erstellen und dieses in mtd3+4 per EVA hochladen. Das hatte, wenn ich das mittlerweile richtig verstanden habe, wohl auch @Nob88 versucht dabei aber dummerweise wohl einen schwerwiegenden Fehler beim Erstellen des TFFS-Images gemacht (vermutlich die Dash/Bash-Problematik und Fehlermeldungen nicht beachtet) weshalb das mutmaßlich "nach hinten" losgegangen ist.

Und nun kommt (endlich) meine kleine Frage dazu:
Würde es stattdessen vielleicht schon reichen per EVA die Bootloadervariable "firmware_info" auf "recovered=2" zu setzen? Wird dabei beim Reboot das TFFS von der Box nicht auch schon neu erstellt und die provider.tar dabei gelöscht (im Gegensatz zu "recovered=3")?
 
@Flole:
Gegenvorschlag ... da es sicherlich auch hier wieder an der fehlenden "-u"-Option für das "read"-Kommando scheitert, würde ich den Test eher genauso machen, wie er in "eva_to_memory" schon implementiert ist.

Das ist zwar genauso wenig aussagekräftig, aber es testet auf das eigentliche Problem (zumindest für "eva_to_memory" und auch für das "eva_get_environment" würde ich ähnliches annehmen, da das ja am Ende genauso ein FTP-Client in Shell ist) und schlägt auch bei anderen denkbaren Shell-Versionen (wer weiß, was da noch so kommt) an, wenn die keinen anderen File-Handle für ein "read" verwenden können.

Ansonsten sitze ich ohnehin gerade (nicht im Moment, aber zumindest mit einem passenden Workspace für mein Visual Studio als "most recent file") an einem Refactoring des gesamten Themas ... von TFFS zerlegen bis AVM-Image lesen und entpacken und mit EVA per FTP kommunizieren.

Ich selbst werde da also nichts mehr an Änderungsaufwand hineinstecken in die alten Skript-Dateien (die ja ohnehin nur die Prinzipien verdeutlichen sollten), aber wenn Du in die anderen Skript-Dateien den Check aus "eva_to_memory" noch einbauen möchtest (store_tffs und switch_system müßten dann genauso betroffen sein), dann drücke ich auch auf "pull". Es macht aber keinen Sinn, da zwei verschiedene Ansätze für den Test zu verwenden ... vermutlich kanntest Du die Stelle in "eva_to_memory" nicht. Sollte die nicht funktionieren, diskutiere ich gerne notwendige Änderungen ... aber der Test sollte eben sein: "Geht es mit der aktuellen Shell?" und nicht "Geht es mit der aktuellen Shell nicht, weil sie "dash" heißt?" - denn wenn da jemand die "dash" unter "perwoll" gespeichert hat und "/bin/sh" zeigt dorthin, geht es immer noch nicht.
 
denn wenn da jemand die "dash" unter "perwoll" gespeichert hat und "/bin/sh" zeigt dorthin, geht es immer noch nicht.
Okay, ich werde "perwoll" in die Liste der unerwünschten Shells aufnehmen ;) :D

Spaß beiseite: Das aus eva_to_memory kannte ich tatsächlich nicht und ich war einfach davon ausgegangen das du dort keine Lösung gesucht oder gefunden hast. Ich werde das dann mal einbauen. Mit Netcat gab/gibt es übrigens teilweise ähnliche Probleme, ich glaube die "-d" Option war dort problematisch, bin mir aber nicht mehr sicher (traditional und bsd waren da glaub ich die 2 varianten, eine war inkompatibel).

EDIT: Wäre fertig, eva_switch_system ist auch betroffen gewesen.
 
Zuletzt bearbeitet:
Wenn sich ein CM ggü der Gegenstelle mit einem gültigen Zertifikat legitimiert... was passiert denn, wenn dieses abgelaufen ist? (Oder sind die alle ~50 Jahre gültig?) Kommt jedes CM mit einem "Ablaufdatum"?
 
Wenn es abgelaufen ist dann wird das CM mit dem Fehler "Permanent authorization failure" zurückgewiesen und das Modem kann nicht mehr benutzt werden. Die "übliche" Gültigkeit scheinen 20 Jahre zu sein, bei verschiedenen Herstellern (Arris, Motorola, AVM) ist dieses Datum jedenfalls so zu finden. Dies ist natürlich immer ab Herstellungsdatum zu sehen.
 
  • Like
Reaktionen: aspseka
@PeterPawn Ist dir eigentlich schonmal aufgefallen, das es von jeder Box 2 Aufkleber gibt (und man sogar beide bekommt, einer auf der Box und dann gibt es noch einmal den exakt gleichen)? Gilt zumindest für freie und Vodafone Boxen, also aus einer zwei machen wäre zumindest schonmal ohne große (technische) Probleme möglich, ich hab nur keine Ahnung wie gut die dann noch kleben wenn man die einmal gelöst hat. Auffällig ist das ganze auch nicht wenn man bedenkt das es ja ein original Aufkleber ist. Irgendwie sind die Hürden wenn man das also tun will doch erschreckend gering, das ein zweiter Aufkleber schon mitgeliefert wird ist irgendwie naja......

Das ist mir übrigens aufgefallen weil ich hier 2 mal die 2. Aufkleber liegen habe, und als ich das heute gesehen hab stellte ich fest das die doch so ziemlich das Format haben was bei der Ebay Box fehlt, einmal schnell damit zur Box bzw. den Boxen gegangen verglichen und es sind tatsächlich dieselben. Witzigerweise sind die Aufkleber von freier und Providerbox etwas anders, also die Anordnung auf diesen. Kann aber auch einfach mit dem unterschiedlichen Produktionsdatum zusammenhängen und das bei der neuen die SSID, Standard-PW etc. draufsteht.
 
Hat schon mal jemand die Labor auf die 6490 installiert?
Kommt man da notfalls auch wieder zurück zur offiziellen 6.87?
Hab eine Retail 6490.
 

Zurzeit aktive Besucher

Statistik des Forums

Themen
246,171
Beiträge
2,247,421
Mitglieder
373,714
Neuestes Mitglied
Panicmaker
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.