Modifikationen mit dem Fritz!Repeater 1200

[PeterPawn]

Ich hoffe, daß man sich da ohne formatieren was weg nehmen kann.

An den ersten 5 Partitionen (mtd0 bis mtd4 - alles aus OS-Sicht) sollte man tatsächlich nicht herumfummeln - das sind der Loader, die zwei Kernel und das TFFS. Die fünfte ist dann ja per se schon "der Rest" des Flash-Speichers - die "ubi"-Partition ist die "physikalische Partition" für alles das, was nach den ersten vier noch übrig bleibt. Den Unterschied zwischen den "physikalischen" und den "logischen" Partitionen (die innerhalb der "ubi"-Partition angelegt werden - das hat ein wenig Ähnlichkeit mit der "extended partition" auf (alten) HDD mit Partition-Table) in der Liste kann man daran erkennen, daß die physikalischen eine "erasesize" von 0x20000 Byte ausweisen, während die logischen nur 0x1f000 Byte anzeigen.

Die Aufteilung der Partitionen in dem von der "ubi"-Partition zur Verfügung gestellten Platz, kann man jetzt allerdings tatsächlich selbst anpassen ... die von AVM vorgesehene findet man in der jeweiligen Firmware in der "/etc/init.d/E03-flash_update", wo mit entsprechenden "ubimkvol"-Kommandos die logischen Partitionen neu eingerichtet werden, wenn die Rahmenbedingungen stimmen. Und die stimmen üblicherweise dann, wenn da im Environment beim Start ein "recovered={1|2}" in "firmware_info" zu finden war ... dann wird in der erwähnten Datei der Part mit dem "force" als erstem Parameter für "check_and_setup_ubi_volumes()" ausgeführt, wo vorhandene Partitionen durch das "ubiformat" ohnehin komplett gelöscht werden (weshalb das Recovery-Programm (mit dem "recovered=2" in "firmware_info") auch den Inhalt der Dateisystem-Partition für beide Systeme zerstört bei den Modellen, wo der UBI-Layer zum Managen der Blöcke verwendet wird) und man sich dann bei Neuanlegen natürlich auch andere Größen aussuchen kann.

Dazu muß man halt eine Firmware passend ändern und diese dann starten lassen - vor dem Flashen erstellt sie dann die logischen Volumes in der gewünschten Größe. Danach darf man dann natürlich kein anderes Recovery-Programm mehr auf die Box loslassen - das würde wieder eine originale Firmware laden und parallel mit dem "recovered=2" auch dafür sorgen, daß die UBI-Volumes neu angelegt werden. Solange man sich an den Partitiongrößen (und Dateisystem-Formaten) einer anderen Cortex-Box orientiert und die Dateisystem-Partitionen groß genug sind/bleiben, damit da die Images nach Updates noch hineinpassen, kann man sicherlich entsprechenden Platz abzwacken ... nur müssen für dessen Verwendung (bei Nutzung der originalen Firmware) sicherlich noch ein paar mehr Stellen angepaßt werden - vom Mounten der "user_data"-Partition bis zu passenden Variablen in der "rc.conf".

Bei Verwendung einer (Alien-)Firmware, die von sich aus NAS-Funktionen mitbringt, sollte das kein Problem sein ... allerdings enthält solche Firmware ja dann i.d.R. auch die passenden "ubimkvol"-Aufrufe, inkl. "user_data"-Partition. Ich rate mal, daß man bei AVM hier auch nur keinen "ungenutzten Flash-Speicher" übriglassen wollte (was bei UBI letztlich ohnehin nicht der Fall wäre, weil der Layer die LEBs über alle PEBs in der physikalischen Partition verteilt als "wear leveling") und daß man deshalb die Partitionen entsprechend vergrößert hat. Schaut man sich die Größe der Partitionen und die der Images an, ist die Diskrepanz schon heftig ... das gilt aber auch für die anderen Modelle und selbst bei der 7590 mit ihren knapp 27 MB für das Dateisystem-Image (in der 07.24), könnte man da noch einiges an Platz der "user_data"-Partition zuschlagen (wobei die ja ohnehin schon mehr Flash hat, so daß das eher bei Modellen mit UBI und kleinerem Flash-Speicher von 128 MB sinnig sein könnte).

Solange man sich dabei auf Änderungen der Größen beim "ubimkvol" beschränkt (das "-m" steht für "den noch verfügbaren Rest"), sollte man auch keinen echten Schaden anrichten können ... der Rest der Daten ist beim "ubiformat" ohnehin Geschichte. Aber man muß bei Änderungen dann sorgsam vorgehen (und die Vorgänge verstanden haben), damit das "ubiformat" überhaupt zum Zuge kommt und man nicht hinterher der Überzeugung ist, das würde alles gar nicht funktionieren, nur weil man nicht in den "force"-Zweig gekommen ist.

Fazit: Ohne "Formatieren" geht es nicht, aber das ist (für die logischen Volumes) ziemlich ungefährlich.

Und BTW ... das Handling des Flash-Speichers für die NAS-Funktionen sollte bei den Boxen mit UBI-Layer auch effektiver sein als bei denen mit YAFFS2 (wozu die VR9-Boxen gehören), weil dort auch als Dateisystem-Format UBIFS verwendet wird, was nicht nur direkt mit dem UBI-Layer zusammenarbeitet, sondern auch noch eine Runtime-Compression der Daten enthält und damit (bei komprimierbaren Daten, ansonsten ist das nur Verschwendung von Rechenzeit) weniger Platz für Dateien belegen sollte. Einfach das AVM-Dateisystem in eine UBIFS-Partition zu packen und damit eine "beschreibbare" OS-Kopie zu erhalten, scheitert aber nicht nur an der weniger effektiven Kompression im Vergleich zu SquashFS (wo auch doppelt vorhandene Dateien nur einmal eingepackt werden) und zu kleinen Partitionen ... auch der (AVM-)Kernel ist leider nicht in der Lage, eine UBIFS-Partition als Root-Device zu mounten - der Scanner ist dafür nicht ausgelegt und man müßte (selbst wenn alles in die Partition passen sollte) mit einem eigenen Kernel mit geändertem Scanner antreten. Damit bleibt für ein "beschreibbares Root-Dateisystem" (was ja gerade beim Austesten eigener Änderungen sehr hilfreich sein kann) weiterhin nur "overlayfs" ... solange AVM das im Kernel beläßt.

 

[hermann72pb]

Danke, Peter für die Aufklärung! Der eigentlichen Problemstellung hier wird es wahrscheinlich wenig nutzen, aber zumindest rein akademisch sollte es doch möglich sein, auch die Aufteilung des physikalischen Speichers (also unter den mtds) zu verändern, oder? Gibt es dafür Werkzeuge "am Board" und geht denn eine solche "Operazion am offenen Herzen" überhaupt, oder kommt man da ohne JTAG nicht weiter? Ich versuche hier einfach (wiederum rein akademisch) ein Beispiel dafür zu konstruieren: Alien-Firmware hat eine völlig andere Aufteilung unter den mtds und womöglich auch einen anderen Bootloader usw. Und das will man jetzt bei der Ziel-Box nachstellen, wo man die Alien-Firmware verwenden will und zwar auch ruhig im kleineren mtd-Bereich mit der bootloader-Partition als Beispiel. Ist sowas überhaupt denkbar? Oder wird es dann zu akademisch und zu riskant?
Geht auch so bisschen in die Richtung deiner Spekulationen mit UBIFS als Root: Es gab doch hier Versuche (ob die immer noch lauffähig sind, weiß ich nicht) Debian auf die Boxen zu installieren. Ich hatte mich zwar damit gar nicht auseinander gesetzt, vermute aber, dass es dort auch um so einen RW-Root ging. Die Frage ist natürlich, wo und wann so ein RW-Root Sinn macht. Leichter warten lässt es sich aber schon.
Und wenn schon UBIFS so effektiv ist, macht es Sinn und ist es überhaupt üblich SD-Karten und USB-Sticks damit zu formatieren? Die Frage in Richtung SD-Karte schielt so bisschen auf RaspberryPi, wo es bekanntlich ein leidiges Thema ist, wenn man die SD-Karte mit irgendwelchen Logs ständig beschreibt und sie dann nach 2-3 Jahren ihren Geist aufgibt.

 

[PeterPawn]

UBIFS braucht UBI und das ist für "raw flash" (also MTD - Memory Technology Devices) gedacht, während SD-Karten und USB-Sticks ihrerseits bereits einen eigenen Layer Controller mitbringen, der die Funktionen des FTL (Flash Transition Layer) - inkl. Wear-Leveling - übernimmt. Um auf solchen Geräten dann wieder "raw MTD" zu betreiben, braucht es sogar erst noch einen zusätzlichen Treiber (z.B. den hier: https://elixir.bootlin.com/linux/latest/source/drivers/mtd/devices/block2mtd.c), der dann auf so einem "block device" wieder ein MTD emuliert - irgendetwas in dieser Richtung macht AVM m.W. auch bei der 6591 (und sicherlich der 6660 ebenso), wenn es darum geht, das TFFS (was auf MTD aufsetzt) am Ende in einer eMMC-Partition zu betreiben. Aber so etwas sollte eher die Ausnahme bleiben ...

Es sollte auch bei einer Alien-Firmware nicht erforderlich sein, die physikalischen Partitionen zu ändern, solange die Daten jeweils in ihr Ziel passen. Denn jede vernünftige Firmware sollte sich an den tatsächlich vorhandenen Größen der Partitionen orientieren (zumindest bei denen, die sie "vorfinden" und nicht selbst erstellen will - denn dafür bräuchte es dann natürlich wieder Ideen, wie groß das jeweils sein sollte) und diese dann auch benutzen - wie sinnvoll eine Alien-Firmware ist, die einen vollkommen anderen Aufbau des Geräts erwartet, muß man ja ohnehin im Einzelfall beurteilen. Ein (ggf. schlechtes) Beispiel wäre hier wohl der DVB-C-Repeater, der m.W. auch mit einer 1750E-Firmware als Alien mit dem WLAN nichts mehr anfangen kann (wenn ich das richtig im Kopf bzw. die Erfolgsmeldungen richtig gefunden und gelesen habe).

Bei AVM gibt es in EVA im Konfigurationsbereich die Angaben, wie groß die jeweiligen MTD-Partitionen sein sollen ... daraus generiert der Loader dann erst die Einträge in seinem eigenen Environment. Wer sich mal einen Dump eines Bootloaders von AVM ansieht, der wird feststellen, daß die "mtdX"-Einträge für das Environment dort in Textform gar nicht vorkommen - die stehen als Paare aus Startadresse und Größe ab Verschiebung 12 im erwähnten Konfigurationsbereich und zwar für max. 16 MTD-Einträge (danach geht die Tabelle der anderen Werte los) - oder vielleicht waren's auch nur 15, weil die Liste mit einem leeren Eintrag enden soll, das ist ohne Gerät, in dem auch MTD15 tatsächlich verwendet wird im Bootloader, nur schwer zu verifizieren.

Aber wie auch immer ... man müßte dann also (zumindest wenn man bei EVA als Loader bleibt) auch noch den erwähnten Konfigurationsbereich im Loader ändern (der steht auch nur bei den MIPS-Modellen mit NOR- oder SPI-Flash so dekorativ am Offset 0x580 herum - bei allen anderen Modellen muß man ihn sich erst deutlich weiter hinten im Loader suchen) und das ist ein Punkt, von dem ich nur dringend abraten kann, solange man nicht der Ansicht ist, die notwendigen Zusammenhänge durchschaut zu haben (und das behaupte ich auch von mir nicht - ich habe nur ein paar mehr Fakten und ggf. sogar zusätzliche daraus resultierende Fragen zusammengetragen im Laufe der Zeit).

 

[hippie2000]

Apropos Basteln:
Müßte man nicht auch die FW des FR1200 auf die FB7520 drauf machen können?

So abwegig ist das nicht. Ich habe mir für zuhause einen Freetz alien mit Repeater N/G Firmware auf dem W503V geschrieben.

Der Grund war ich wollte man auf einer 80m Strecke testen ob der WLAN-Client Mode mehr Performance hat als das WDS1. Resultat war es ändert sich nichts, ausser dass der Repeater danach nur DHCP kann und die IP gerne mal umhersprang - repeatet hat er immer 1A Und am N/G Freetzen ist Bricken wollen, ohne LAN Port keine Recovery...

Ich hab dann eine lange Zeit probiert die Telefonie in den Repeater einzubauen auf dem W503V - irgendwann liess ich es schleifen - zu viel Arbeit am Webinterface. Es war ein Experiment, und ich kehrte wieder zu WDS zurück damals..

 

[Insti]

@eisbaerin
Hast du die Möglichkeit mal den Stromverbrauch zu messen vom R1200 und von der 7520?

 

[NDiIPP]

Repeater 1200: ca. 3-5W (mit aktivem WiFi)
Fritzbox 7520/7530: ca. 5-6W ohne xDSL, ca. 6-7W mit xDSL (mit aktivem WiFi in beiden Fällen).