[Sammlung] Installation von Inhouse-Versionen ab Version 07.08

"firmware-nocompile" kann ich nicht im YourFritz Repository nicht finden.
Oder ist es was anderes?
 
Guten Abend zusammen,
beim Weg über die Konsole ist zu beachten:
nicht "# mount -o bind /var/tmp/key /etc/avm_firmware_public_key3",
sondern
"# mount -o bind /var/tmp/key /etc/avm_firmware_public_key2"

[Edit Novize: gelöschten Beitrag wieder hergestellt - Thread-Vandalismus wird nicht geduldet!]
 
Zuletzt bearbeitet von einem Moderator:
@Suicidal
Danke für den Hinweis.
Kannst Du noch beschreiben wie man den Konsolenzugang bewerkstelligt?
 
Guten Abend,
zuerst das Recover auf die 93er. Dann ein Update auf die letzte interne 98er.
Danach geht man über die Konsole, so wie es durch Koyaanisqatsi und PeterPawn beschrieben wurde.

Es ist zwar ein etwas umständlicher Weg,aber für mich war es der einzig gangbare und verständliche Weg.

[Edit Novize: gelöschten Beitrag wieder hergestellt - Thread-Vandalismus wird nicht geduldet!]
 
Zuletzt bearbeitet von einem Moderator:
  • Like
Reaktionen: bino
Danach geht man über die Konsole, so wie es durch Koyaanisqatsi und PeterPawn beschrieben wurde.
wieso nicht direkt die FW via Bootloader flashen?
Es ist zwar ein etwas umständlicher Weg,aber für mich war es der einzig gangbare und verständliche Weg.
ja das glaube ich, da es eig. reicht. ein image2ram zu erstellen und dieses via eva_to_memory über den Bootloader die FW installieren lassen, geht natürlich viel schneller .

Ich behaupte mal nach 3x erfolgreichem flashen auf diese Weise hat man das ganze in max 10 (incl Wartezeit) min erledigt.
 
hab mal versucht das FW-Image (134.07.08-63867) mit den eva-tools in ein "in-memory" zu konvertieren.
Das ist aber auch totaler Quatsch ... das Skript ist darauf ausgelegt, daß es eine "kernel.image" und eine "filesystem.image" - jede mit einer Länge > 0 - in der Eingabedatei gibt. Das ist beim Repeater nicht der Fall, da dieser den Inhalt des Kernels und des SquashFS-Images in der Datei "kernel.image" kombiniert und die (durchaus vorhandene) "filesystem.image" damit die Länge 0 hat. Von 0 kann das Skript die Länge der Prüfsumme am Ende der Datei auch nicht abziehen (das wäre dann die Länge "-8"), um den Test auf das Vorhandensein der Prüfsumme auszuführen. Soweit doch eigentlich logisch, oder?

Für den Repeater braucht man auch gar kein "in-memory"-Image ... da kann man einfach die enthaltene "kernel.image" nehmen und in "mtd1" schreiben - schon hat man die Inhouse-Version über den Bootloader installiert.
 
Guten Abend Stoney,
ich habe versucht,das besagte Image zu erstellen.Leider ist es mir nicht möglich, bzw scheint mein geistiger Horizont dafür nicht zu genügen. Der von Koyaanisqatsi und PeterPawn gezeigte Weg über die Konsole ist zwar ein Aufwand von ca. 10 - 15 Minuten, aber bei meiner Hardwarelandschaft ist das zu vertreten.
Es wären die 7590 und der 1750. Mehr habe ich nicht mehr.

[Edit Novize: gelöschten Beitrag wieder hergestellt - Thread-Vandalismus wird nicht geduldet!]
 
Zuletzt bearbeitet von einem Moderator:
@PeterPawn
Sorry dass ich noch einmal nachfragen muss.

Wie kann ich denn das enthaltene "kernel.image" entnehmen bzw. extrahieren?
Und was verstehst Du unter "mtd1"?

Danke!
bino
 
Danke Stoney
habe ich verstanden.

Ist "mtd1" ein Verzeichnis auf dem Repeater?
 
"mtd1" ist eine Flash-Partition auf dem Repeater ("MTD" steht für das etwas abstrakte "Memory Technology Device") und kann aus Windows heraus z.B. auch mit "EVA-FTP-Client.ps1" beschrieben werden, indem man anstelle von "BootDeviceFromImage" einfach die Funktion "UploadFlashFile" verwendet: https://github.com/PeterPawn/YourFritz/blob/master/eva_tools/EVA-FTP-Client.ps1#L649

Dabei ist der Dateiname der erste Parameter und das "mtd1" dann die "target_partition" - es gibt auch wieder viele Wege an die Datei zu gelangen, denn neben dem bereits erwähnten "7-Zip" und "WinRAR" kann man das auch mit "FirmwareImage.ps1" extrahieren.

Damit das nicht mehr als eine Zeile benötigt (denn damit ging das bisher schon), habe ich gerade noch eine Funktion zur Datei hinzugefügt - man kann anstelle des:
Code:
[FirmwareImage]::new("$pwd\original.image").getBootableImage("$pwd\bootable.image")
für die NAND-Boxen (wo das Image im Speicher gestartet wird), auch die folgende Zeile:
Code:
[FirmwareImage]::new("$pwd\original.image").extractMemberAndRemoveChecksum("./var/tmp/kernel.image", "$pwd\flash_me.image")
benutzen, wobei das "./var/tmp/kernel.image" der Name der Datei im AVM-Image (das ist ja das "original.image") ist und nicht geändert werden darf. Die Ausgabe-Datei kann man wieder nennen, wie man will, ich habe mich hier für "flash_me.image" entschieden.

Diese Datei kann man dann (bei Geräten, wo so ein kombiniertes Image durch das Schreiben in "mtd1" installiert wird - ich will mich hier absichtlich nicht auf "NOR-Boxen" festlegen) einfach nach "mtd1" schreiben lassen ... bei anderen Modellen sollte man sich das immer noch tunlichst verkneifen.

Wer sich nicht sicher ist, welches Format ein Gerät braucht, liest besser noch einmal nach (und ich meine tatsächlich auch "lesen" und nicht (zumindest nicht primär) fragen) ... es gab ein paar Berichte, daß GRX-Boxen das Beschreiben von "mtd1" auf diesem Wege übelnehmen würden (deshalb wurde auch "recover_eva" aus Freetz noch einmal angepaßt und um eine Modellabfrage ergänzt).
 
Wurde hier nicht vor kurzem auf eine Anleitung verwiesen wo das alles schon beschrieben wurde?
/howto-fritz-box-firmware-images-auch-unsignierte-ueber-den-bootloader-installieren-577

In Beitrag #6 dort steht doch der 1750E bei den NOR-Flash Modellen, also gelten für diesen dann auch die Teile der Anleitung die für die NOR-Flash Modelle gedacht sind (und da wird nirgends eine "in-memory" erstellt)...
 
Da sich dort noch eine "Lücke" unter Windows auftat beim Extrahieren der "kernel.image" (klar, man kann auf 7-Zip und WinRAR verweisen, aber wer die ansonsten nicht braucht, deinstalliert sie ohnehin besser danach sofort wieder, falls sie sich als Datei-Handler für bestimmte Typen registrieren bei der Installation und dann mal wieder eine Lücke auftaucht), habe ich ja den "Einzeiler" fürs Extrahieren noch hinzugefügt ... aber ansonsten sehe ich es schon ähnlich, daß man nicht alles noch einmal wiederholen sollte.

Außer ggf. den Link zur Anleitung von @qwertz.asdfgh ... nur schade, daß die Anleitung nur im anderen Board verfügbar ist. Wer dort "Anmerkungen" dazu machen will oder Nachfragen hat, müßte sich auch da erst noch einen Account einrichten - für mich persönlich eine Hürde, über die ich nicht springen will. Denn dann müßte man auch da wieder lesen, ob jemand irgendetwas geantwortet hat ... und ggf. sogar dort (so man möchte) auf Fragen antworten.

Dann kommt man durcheinander, in welchem Board man nun welches Thema abgehandelt hat ... am Ende müßte man für die Suche nach nachweislich vorhandenen Themen dann wieder eine Suchmaschine für zwei verschiedene Sites bemühen (bzw. "empfehlen"). Das alles macht die "Mitgliedschaft" in zwei verschiedenen Boards (zu denselben Themen) dann einigermaßen unattraktiv und auch wenn man (heimlich) durchaus noch andere Boards liest bzw. dort ab und an mal vorbeischaut, was es Neues gibt (bis hin zu den "inoffiziellen" Kundenforen für die beiden großen KNB oder "onlinekosten.de" oder auch "router-forum.de"), so ist es doch (für mich zumindest) deutlich bequemer, sich beim Schreiben auf ein Board zu beschränken.

Daher wäre ich tatsächlich dankbar, wenn die Anleitungen "umziehen" würden (dann bemerkt man auch Änderungen und Korrekturen darin eher) ... oder wenn es zumindest hier auch entsprechende Threads zur "Diskussion" zu den Anleitungen gäbe. Ich hätte schon noch die eine oder andere Anmerkung oder Nachfrage (was dann ggf. meinerseits zu einer Änderung an einem Skript führt, wie beim Schließen der Datei beim Extrahieren aus dem AVM-Image) und verkneife mir die halt, weil es "über Bande" auch blöd ist und ich nicht weiß, ob @qwertz.asdfgh das von mir per E-Mail lesen möchte.
 
@PeterPawn
Danke für die Ergänzung bezüglich dem extrahieren des kernel.image. Das könnte man ja auch gleich zum extrahieren der 4 Images aus den Firmware-Dateien der Puma6-Modelle verwenden oder?
Code:
[FirmwareImage]::new("$pwd\original_6490.image").extractMemberAndRemoveChecksum("./var/remote/var/tmp/kernel.image", "$pwd\6490_kernel_arm_flash_me.image")
[FirmwareImage]::new("$pwd\original_6490.image").extractMemberAndRemoveChecksum("./var/remote/var/tmp/filesystem.image", "$pwd\6490_filesystem_arm_flash_me.image")
[FirmwareImage]::new("$pwd\original_6490.image").extractMemberAndRemoveChecksum("./var/remote/var/tmp/x86/kernel.image", "$pwd\6490_kernel_x86_flash_me.image")
[FirmwareImage]::new("$pwd\original_6490.image").extractMemberAndRemoveChecksum("./var/remote/var/tmp/x86/filesystem.image", "$pwd\6490_filesystem_x86_flash_me.image")


Ansonsten richtete sich meine Bemerkung nicht nur an dich sondern unter anderem auch an die letzten Beiträge von @Master SaMMy, @bino oder @stoney die auf ein "in-memory" Image oder "image2ram" verwiesen hatten was ja beim 1750E der falsche Weg ist. Und das obwohl @H'Sishi schon in Beitrag #137 auf die "übliche FTP-/EVA-Methode" hingewiesen hatte (wobei man mittlerweile wohl auch das Hochladen in den RAM per EVA als die übliche Methode bezeichnen kann) und auch du in #147 versucht hattest auf das wohl bestehende Missverständnis hinzuweisen. Der 1750E gehört eben nicht zu den "NAND-Modellen" und hat auch keine DualBoot-Funktion.
 
  • Like
Reaktionen: bino
Ja, das sollte funktionieren.

Nur Dateien der Länge 0 extrahiert auch diese Funktion nicht; man kann sie also nicht auf die "firmware.image" in den Images loslassen, die im "combined format" (also Kernel + SquashFS-Image in einer Datei mit dem Namen "kernel.image") vorliegt ... aus dem bereits beschriebenen Grund.

Für das einfachere "extractMember" (was nicht nach der Prüfsumme schaut), gibt es keinen "Einzeiler" ... da muß man das dann in Variablen speichern und diese in weiteren Aufrufen verwenden, weil es (bisher) keine Funktion gibt, die nur den Namen der Datei im Firmware-Image nimmt und diese Datei dann direkt im Filesystem ablegt.

Wäre die Frage, was man eher nachrüsten sollte ... eine andere Prüfung der Signatur für die TI-Checksum (die sich nicht mehr an 0 Byte Länge stört) oder den "Einzeiler" für das Extrahieren auch ohne den Versuch, sie zu entfernen. Das ist aber auch nicht so richtig akut, denn das kommt eben noch als C#-Klasse und die Entscheidung muß ich erst bis dahin fällen. Wenn jemand gute Argumente für die eine oder andere Lösung hat, lese ich die auch gerne.

Insofern hätte ich für die Verwender von "FirmwareImage.ps1" anstelle der vier Zeilen aus #155 dann auch eine etwas andere Empfehlung, ich würde das als:
Code:
$image = [FirmwareImage]::new("$pwd\original_6490.image");
$image.extractMemberAndRemoveChecksum("./var/remote/var/tmp/kernel.image", "$pwd\6490_kernel_arm_flash_me.image");
$image.extractMemberAndRemoveChecksum("./var/remote/var/tmp/filesystem.image", "$pwd\6490_filesystem_arm_flash_me.image");
$image.extractMemberAndRemoveChecksum("./var/remote/var/tmp/x86/kernel.image", "$pwd\6490_kernel_x86_flash_me.image");
$image.extractMemberAndRemoveChecksum("./var/remote/var/tmp/x86/filesystem.image", "$pwd\6490_filesystem_x86_flash_me.image");
umsetzen, weil dann das Firmware-Image nur ein einziges Mal geladen wird (das steht dann in der Variablen "$image" für die weitere Verwendung bereit) und aus diesem dann der Reihe nach die vier Dateien extrahiert werden. Die Variante in #155 lädt das Image für jede Datei neu und extrahiert dann nur die eine Datei, bevor das Objekt wieder abgeräumt wird.
 
  • Like
Reaktionen: NDiIPP
So, die Inhouse (07.08-63867 Inhaus) ist via EVA-Tools auf dem Repeater drauf.
Dank an alle !
Allerdings wird mir ein Update auf die selbe Inhaus-Version angeboten.
Kann das jemand bestätigen?
 
@bino:
Warte einfach bis nach der nächsten Inhouse-Version ... wenn das dann immer noch so ist, kann man weitersehen. Ansonsten kann es durchaus auch sein, daß AVM bei der JUIS-Abfrage für eine solche "Einstiegsversion" dieselbe Version noch einmal annonciert ... das wäre dann ggf. nur ein Fehler in deren Datenbank (ob die Antwort vom JUIS so ist, wie ich vermute, kann man ja schnell prüfen, wenn man im Besitz eines solchen Repeaters ist und sich die Parameter der Abfrage nicht erst zusammensuchen muß) und man hat sich vollkommen umsonst verrückt gemacht. Wenn der JUIS immer wieder behauptet, es gäbe eine neue Version, wird die Box (oder der Repeater) das auch immer wieder glauben ... nach meinen Erfahrungen erfolgt da kein "lokaler Vergleich" irgendwelcher Versionsnummern.
 
Allerdings wird mir ein Update auf die selbe Inhaus-Version angeboten.
Dann mach doch mal dieses Update, vorausgesetzt die Firmware in der anderen Partition ist entbehrlich.
 
Zuletzt bearbeitet:
@koyaanisqatsi
Habe ich bereits gemacht.
Hinterher die gleiche Situation.
Ich gebe mich mit der Antwort von Peter auch zufrieden.
Abwarten und Tee trinken.
 
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.