[Frage] Provider Additive entfernen bei Firmware 6.51

[PeterPawn]

1. Ich komme auch immer durcheinander bei den IDs, aber nach der tffs.h von AVM

FLASH_FS_ID_PROVIDERADD_0     = 0x001D,   /*--- /var/flash/provider-additive/? (konfig des nachladbaren Internetanbieters, nicht durch WE geloescht) ---*/

ist das wohl doch die 29 ... hier habe ich das auch schon vor Urzeiten geändert.

2. Zur Extraktion des TFFS-Dumps aus den Support-Daten gibt es auch seit einiger Zeit schon ein Skript unter https://github.com/PeterPawn/YourFritz/blob/master/tffs/tffs_from_supportdata

3. Das Auseinanderpuzzlen eines TFFS-Images kann ein weiteres Skript übernehmen: https://github.com/PeterPawn/YourFritz/blob/master/tffs/dissect_tffs_dump - alles, was ich noch dazu schreiben könnte, zeigt der Blick in das Skript vermutlich besser.

 

[Riverhopper]

Hallo PeterPawn,
Danke für die Inputs #21, werde mich durchkämpfen ;-)

Fragen:
Funktioniert das dissect_tffs_dump Tool https://github.com/PeterPawn/YourFritz/blob/master/tffs/dissect_tffs_dump auch für NAND-TFFS Systeme ?
hier wird IMHO nanddump als Backuptool verwendet.
Und nur um sicher zu sein: Ist die Sicherungs-Methode "cat /dev/mtd$TFFS > /var/tmp/mtd_$TFFS.dump" sowie dissect_tffs_dump für alle MIPS32 (BE) Systemen mit Serial-Flash unabhängig vom Kernel-Versionen (3.0.17 sowie 2.6.xx) anwendbar ?
mein Scope richtet sich hier an alle Fritz-Geräte; auch Repeater oder DOCSIS-Boxen.

LG Riverhopper

 

[PeterPawn]

Da ich nicht alle Geräte kenne, kann ich das nicht sagen (und zu DOCSIS-Geräten beantworte ich keine Fragen, gebe höchstens mal meinen eigenen Senf dazu, dann aber von mir ausgehend) ... und solange bei Geräten mit dem TFFS im NAND eine identische Struktur erzeugt wird (das ist - je nach Parametrierung (mit oder ohne "out of band") - ja der Sinn von "nanddump" anstelle von "cat", weil dabei zusätzliche Daten auf dem Block-Device gelesen werden, die nicht direkt zum Inhalt gehören, sondern zu den Verwaltungsstrukturen des NAND (wear leveling, defect management) und diese ohne Kenntnis des Aufbaus nicht von den "reinen Daten" zu trennen sind), solange läßt sich auch auf diese Ausgabe vermutlich das Skript anwenden. Beim Schreiben über den Bootloader in die "mtdnand"-Partition wird jedenfalls nach dem, was ich bisher gesehen habe, dieselbe Struktur verwendet.

Dort muß allerdings der Bootloader "dazugelernt" haben, denn ansonsten kann der Bootloader (bei anderen Modellen) mit NAND-Flash nichts anfangen (m.W., das muß nicht immer stimmen) - ansonsten wäre der von AVM beschrittene Weg beim Recovery (und im System überhaupt) zwar immer noch "änderungsfreundlich", aber ich würde nicht verstehen, warum er beschritten wurde, denn er machte das im Vergleich zu den NOR-Modellen dann doch etwas komplizierter und vom leichteren Modifizieren durch den Kunden hat AVM selbst ja nichts.

Ansonsten muß man eben mit dem Skript probieren, ob ein TFFS-Dump ordnungsgemäß zerlegt werden kann ... wenn die Text-Dateien sich in dekomprimierter Form "richtig anfühlen", wird der Rest sicherlich auch stimmen. Ich habe gerade keine Zeit und auch keine Lust, das mit der 7412 einfach mal durchzuspielen und ich finde gerade keine erweiterten Supportdaten eienr 7412 in meiner Sammlung.

 

[KingTutt]

Hi Peter, Deine Scripte und tool werde ich auch einmal versuchen. Ich müsste noch eine unangetastete 7490 Edition EWE Zugriff haben, wo ich einmal die erweiterten Support Daten runterladen und mit Deinen Tools zerlegen kann.

Leider ist mir die Funktionsweise noch nicht ganz klar. tffs_from_supportdata benötigt als input die Support Daten, als Output ein Verzeichnis und als index? Evtl. die ID 29 für die Provider Additive? zumindest kommt eine Datei tffs_2.dump dabei raus.
Das dissect_tffs_dump bekommt dann als input den tffs_2.dump von tffs_from_supportdata. Aber obwohl die yourfritz_helpers im gleichen Verzeichnis liegt wird sie von source nicht gefunden. Setze ich ein $PWD/ in Zeile 42 davor passiert irgendwie nicht (wie eine Endlosschleife).

Was ich allerdings noch nicht in den diversen Threads gefunden habe: Was macht man, wenn das Kind quasi schon in den Brunnen gefallen ist? Also man per Bootloader die Provider Variable gelöscht hat, dann ein Recovery durchgeführt hat, keine alte Firmware mehr im zweiten System ist und man nun für Oma-Greta wieder einen Auslieferungszustand herstellen möchte.

Sicherlich kann man zunächst die Provider Variable im Urlader-Environment wieder setzen, aber wie funktioniert der Match zwischen dieser Variablen und den Provider Additiven, die ja in der Original AVM Firmware enthalten sind? Das einfache setzen der Provider Variablen wird ja vermutlich kaum ausreichen, sonst könnte man ja jede 7490 von AVM durch setzten dieser einen Variablen zu einer Edition XYZ um konfigurieren.

Bei der 7490 Edition EWE steht in der provider Variablen z.B. ewe_7490_0714 drin. Schaut man nun in die providers-049.tar und vergleicht das mit den erweiterten Support Daten stellt man fest, das z.B. die VDSL Anschlüsse das verzeichnis ewetel_xdsl nutzen. Was mir derzeit unklar ist, wie das Mapping von der Variable im Urlader-Environment zu den Provider Daten funktioniert. Auch gibt es kleine unterschiede. So steht z.B. in den erweiterten Supportdaten eine VLAN ID von 2011 für das DSL Interface, während das Provider Macro eine VLAN ID von 2019 vorgibt. Hast Du Peter zu diesem Matching bzw. was man machen kann wenn man nichts zuvor gesichert hat, noch weitere Hintergrundinfos?

 

[PeterPawn]

@KingTutt:
Der Index bei tffs_from_supportdata dürfte zwischen der ersten und der zweiten TFFS-Partition auswählen, wenn ich mich richtig erinnere.

Die TFFS-Partition mit dem kleineren Wert im "segment header" (vorzeichenlose 32-Bit-Zahl in den Bytes 4-7) ist die zuletzt geschriebene ... der Wert beginnt bei -1 (also 0xFFFFFFFF) und wird mit jedem Schreibvorgang entsprechend verringert (0xFFFFFFFE = -2, 0xFFFFFFFD = -3, usw.). Da auch AVM nicht ohne weiteres sagen kann, welche der beiden Partitionen nun gerade dran ist und vermutlich auch, weil man aus der Differenz auch die zuletzt geschriebenen Einstellungen herleiten kann, enthalten die Support-Daten beide Partitionen und man muß sich eine aussuchen zum Auseinanderpuzzlen.

Warum die yourfritz_helpers nicht gefunden wird, kann ich natürlich auch nur raten ... die Zeile mit dem "source" oder "." (keine Ahnung, was ich da verwendet habe, ist identisch in der Auswirkung) sollte sich ja leicht finden lassen. Ich könnte mir aber durchaus vorstellen, daß Du den Symlink mit der eigentlichen Datei durcheinander bringst - die Datei liegt ja unter "helpers" in einem anderen Pfad.

Ich habe keine Boxen mit "provider additive", ich kenne auch nur den Mechanismus, wie man ihn aus der Außenansicht der Firmware ableiten kann. Wenn man vor dem Recovern (oder was man auch immer nach dem Löschen von "provider additive" gemacht hat) nicht seine eigene Sicherung angelegt hat (meinetwegen über die erweiterten Support-Daten), wüßte ich auch nicht, wie man an diese Daten gelangen sollte.

Es gibt meines Wissens keine "Zuordnung" ... es gibt einen TFFS-Node (29) für diese providerspezifischen Einstellungen und jeder beliebige Wert in der "provider"-Variablen führt zum Entpacken und Anwenden dieser Einstellungen, wenn der "active_provider" in der ar7.cfg nicht diesem Wert entspricht ... so habe ich mir das jedenfalls mal zusammengereimt anhand von Testergebnissen (allerdings bei einer alten 7390 und vor längerer Zeit, es war sicherlich irgendeine Version mit 06 vorne, aber frag mich nicht welche genau und wann das war, ich müßte erst alte Aufzeichnungen aus einem Backup herauspolken).

Diese Providereinstellungen haben per se auch nichts mit der providers-049.tar zu tun ... dann bräuchte es sie ja gar nicht, wenn die Box sie dort bereits auslesen könnte - nur bei abweichenden oder nicht vorhandenen Angaben für den Provider in der providers-049.tar macht das in meinen Augen überhaupt Sinn.

Aber ich habe auch schon lange keine solche Provider-Datei (also eine aus dem TFFS-Node 29) mehr in der Hand gehabt (irgendjemand "spendete" damals mal seine Datei für einige Tests, da ließ die sich über Telnet auch noch problemlos auslesen, wenn man das "mknod" dafür von Hand machte oder das "mkconfigfile" von AVM verwendete) ... vielleicht findet sich ja mal jemand, der sie aus seiner Box ausliest (wenn die nicht providerspezifisch wäre, sondern kundenspezifisch, dann bräuchte es ja TR-069 an dieser Stelle nicht mehr und dann müßte eben auch jede Box individuell vom Provider "provisioniert" werden vor der Auslieferung an den Kunden) und mir zur Verfügung stellt, wenn es um eine aktuelle Box geht.

 

[KingTutt]

Beim yourfritz_helpers werde ich wohl mal etwas debuggen müssen, das mit dem Symlink hatte ich schon berücksichtigt und mit die Datei direkt als RAW aus dem richtigen Unterverzeichnis bei Github gezogen.

Zu den "provider additive":
Ich werde dann mal versuchen etwas mit zu helfen. Mich interessiert, wie dieser Mechanismus funktioniert. Zum einen, falls ich selbst mal gezwungen bin ein Recover durch zu führen möchte ich wissen, was man alles berücksichtigen müsste und zum anderen, weil ich hier einen Kontakt per PN habe, der Ein Recover gemacht hat wonach die Autokonfiguration nicht mehr funktionierte. Allerdings konnte das von Seiten der Hotline wieder angestoßen werden... (keine Ahnung wie, evtl. per TR069)
In meinen Setting konnte ich dank Deinem Pointe auf jeden Fall entnehmen, dass die Variable "active_provider" in der ar7.cfg dem Verzeichnis aus der providers-049.tar entspricht.

 

[KingTutt]

@PeterPawn
nachdem ich im script dissect_tffs_dump in Zeile 42 noch ein $PWD/ vor dem yourfritz_helpers eingebaut habe funktionierte es. Keine Ahnung, warum er das Hilfsskript nicht direkt aus dem Verzeichnis geladen werden konnte.

Nun zu den Ergebnissen der Analyse:

• Erweiterte Supportdaten aus der 7490 Edition EWE ausgelesen (nicht vergessen den Haken für die Erweiterten Daten wieder raus zu nehmen)
• die scripte tffs_from_supportdata, dissect_tffs_dump, yourfritz_helpers von Peters GitHub Account runterladen

• ./tffs_from_supportdata INPUTFILE OUTPUTDIR 1
  --> man erhält tffs_1.dump

• ./tffs_from_supportdata INPUTFILE OUTPUTDIR 2
  --> man erhält tffs_2.dump

• cmp -l tffs_1.dump tffs_2.dump | gawk '{printf "%08X %02X %02X\n", $1, strtonum(0$2), strtonum(0$3)}'
  --> der Dump des TFFS-Node 29 von den TFFS-Partitionen 1 und 2 ein und derselben Box war identisch

• cmp -l tffs_1-box1.dump tffs_1-box2.dump | gawk '{printf "%08X %02X %02X\n", $1, strtonum(0$2), strtonum(0$3)}'
  00000092 33 32
  0000009A 31 30
  00000292 33 32
  0000029A 35 34
  --> der Vergleich des TFFS-Node 29 von 2 verschiedenen Boxen (beide 7490 Edition EWE) gab an 4 Byte einen Unterschied

• im script dissect_tffs_dump musste ich (s.o.) in Zeile 42 ein $PWD/ ergänzen

• ./dissect_tffs_dump < tffs_1.dump
  --> erzeugt ein Verzeichnis mit einer .bin Datei je Node und eine .inflated Datei wenn der Node mit gzip gepackt war

• die Datei 001d.bin (HEX 29) bzw. 001d.inflated enthält die provider additive

• tar -xf 001d.inflated
  --> man erhält ein Verzeichnis provider_additive in meinem Fall mit 3 Dateien

  1. ar7.cfg
  2. desc.txt
  3. startinfo.txt
• ein diff auf die entpackten Dateien zweier unterschiedlicher Boxen zeigt KEINEN Unterschied! Das deckt sich mit der Aussage von Peter, dass die Dateien providerspezifisch und nicht kundenspezifisch sind
• Freetz speichert die Provider-Additive in seinem Backup als provider_additive.tar ab.

Zum Inhalt der Dateien:

ar7cfg {
       active_provider = "__refto__:ewetel_adsl";
}
// EOF

box:settings/opmode=opmode_pppoe

activate_on_start = 1;
activation_done = 1;

Vermutlich speichert der Provider hier auch, dass die Box aktiviert worden ist. Man müsste das mal nach einem Werksreset vergleichen und schauen, ob activation_done = 0 gesetzt ist.

Was ich interessant finde: die provider Variable im Urlader Environment hat den Wert ewe_7490_0714. Nach dem Provider-Additiv müsste dann bei der Einrichtung der active_provider = ewetel_adsl genutzt werden. Zumindest würde ich das "__refto__:ewetel_adsl" so interpretieren. Tatsächlich finde ich in der ar7.cfg aber active_provider = ewetel_xdsl. Vermutlich wird per der Einrichtung geprüft, ob es sich um einen ADSL Anschluss handelt und wenn nicht wird bei einem VDSL Anschluss auf die andere Konfiguration gewechselt??

Fragen die noch offen sind:

• kann man (wie) einen gesicherten TFFS-Node 29 bzw. die Datei 001d.bin (z.B. nach einem Recover) wieder zurück spielen? Wenn ja, geht das per Bootloader oder nur nur aus einem laufenden System von der Shell? Ziel wäre es, folgenden Weg zu beschreiten:
  • Provider Additiv sichern (z.B. mit erweiterten Supportdaten)
  • provider Variable im Urlader über den Bootloader löschen
  • AVM Recover durchführen
  • provider Variable im Urlader über den Bootloader wieder setzen
  • Provider Additiv wieder zurück spielen
• darf man das Provider additiv hier im Forum mit hochladen? (vermutlich wegen copyright nicht, andererseits sind das nur Textfiles, die man sich auch selbst per Editor erstellen könnte?)

@Peter
Ich stelle Dir das Additiv gerne für die weitere Analyse zur Verfügung.

 

[PeterPawn]

@KingTutt:
Wiederherstellen des Node 0x1D geht über das laufende System am einfachsten - logisch.

Ansonsten klappt es aber auch über eine "Recovery-Simulation" ... das ist ja auch nichts anderes - in Bezug auf das TFFS - als das Auslesen von Environment und Countern (die werden m.E. schon lange entweder zweckentfremdet oder gar nicht mehr genutzt) und das Zusammenbauen eines passenden TFFS-Images aus diesen beiden Komponenten (es wird noch die Name-Table für die Environment-Variablen benötigt, die kann man mit "name_table_from_kernel" erzeugen lassen) mit anschließendem Schreiben dieses Images in MTD3 und MTD4.

Zum Auslesen kann man "eva_get_environment" aus "eva_tools" nehmen (das kann beides auslesen, sowohl das Environment als auch die Counter - nur den richtigen "Dateinamen" beim Auslesen angeben ... env oder count (prüfen, letzteres ist aus dem (schwachen) Gedächtnis)) - das erzeugt m.E. auch gleich das passende Format, was für "build_tffs_image" benötigt wird, wobei letzteres nicht nur die drei erwähnten Komponenten (Environment, Counter, Name-Table) zu einem Image zusammenpackt, sondern auch noch alle danach angegebenen Dateien, die wieder aus einem TFFS-Dump stammen können (also 001D.bin im Falle der Additiv-Datei).

Wenn man sich also mit dem TFFS-Dump und "dissect..." die in einer aktuellen Box enthaltenen Einstellungen aus den erweiterten Support-Daten holt, kann man mit einer entsprechend langen Liste an zusätzlich zum TFFS-Image hinzuzufügenden Dateien eine (fast) 1:1-Kopie der laufenden Einstellungen erzeugen und dabei auch die Additiv-Datei wieder hinzufügen, wenn man eigentlich gar keinen Shell-Zugang hat (weil die originale Firmware läuft) und hat dann diese Datei wieder in der Box, auch ohne den Komplettverlust der eigenen Einstellungen oder den Shell-Zugang. Auch das "externe Löschen" der "nicht vom Hersteller ..."-Markierung in der ID 87 (0x57) ist auf diesem Wege möglich, wenn man nicht "komplett recovern" will. Wobei das am Ende dann wirklich im Angesicht des notwendigen Aufwands eher eine Lösung für "Spezialfälle" wäre, denn da geht "Recovery" und Wiederherstellen der eigenen Einstellungen (bis auf das Zertifikat und die DECT-Keys) dann doch wieder deutlich schneller, wenn man das nicht aus dem Effeff beherrscht mit dem Zusammenbau eines neuen TFFS-Images - wobei für das Löschen des Inhalts von Node 87 ja gar kein komplettes Auseinandernehmen und Zusammensetzen notwendig wäre, da reicht es schon, die Node-ID zu suchen und zu entfernen (bzw. als gelöscht zu markieren).

Ich nehme die kleine Datei dann gerne per E-Mail an eine der bekannten Adressen - man kann nie genug Beispiele haben, wo man bei Bedarf auch noch einmal nachsehen kann.

 

[KingTutt]

Ich nehme die kleine Datei dann gerne per E-Mail an eine der bekannten Adressen

Bekannt ist gut.
Entweder habe ich Tomaten auf den Augen oder Du hast sie 1a versteckt. Weder auf GitHub, noch in diversen Readme Files noch im Sourcecode bin ich fündig geworden. Meine Recherchen haben zwar eine über den Business Weg zutage gefördert, aber ich bezweifle, das Du die gemeint hast :noidea:

 

[PeterPawn]

modfs/admin/packages/framework ... alles an "yourfritz.de"

Das GitHub-Repo enthält seit einigen Tagen (inzwischen unterstützt GitHub ja Commits mit "Unterschrift") auch einen passenden Public-Key für GPG, der auch eine Liste von möglichen E-Mail-Adressen enthält.

 

[KingTutt]

@KingTutt:
Wiederherstellen des Node 0x1D geht über das laufende System am einfachsten - logisch.

Also ich habe mir gemerkt, dass man mit

echo clear_id 87 >/proc/tffs

den Node 87 als gelöscht markieren kann. Aber wie schreibt man denn einen? Geht das alla

major=$(grep tffs /proc/devices)
tffs_major=${major%%tffs}
mknod /var/flash/provider_addon c $tffs_major 29
cat 001D.bin > /var/flash/provider_addon
rm -f /var/flash/provider_addon

Wenn man sich also mit dem TFFS-Dump und "dissect..." die in einer aktuellen Box enthaltenen Einstellungen aus den erweiterten Support-Daten holt, kann man mit einer entsprechend langen Liste an zusätzlich zum TFFS-Image hinzuzufügenden Dateien eine (fast) 1:1-Kopie der laufenden Einstellungen erzeugen und dabei auch die Additiv-Datei wieder hinzufügen, wenn man eigentlich gar keinen Shell-Zugang hat (weil die originale Firmware läuft) und hat dann diese Datei wieder in der Box, auch ohne den Komplettverlust der eigenen Einstellungen oder den Shell-Zugang.

Das holen kann ich nachvollziehen, aber das zurück spielen in die Box noch nicht. Vermutlich muss man da das zusammengebastelte TFFS per Bootloader zurückspielen.

Auch das "externe Löschen" der "nicht vom Hersteller ..."-Markierung in der ID 87 (0x57) ist auf diesem Wege möglich, wenn man nicht "komplett recovern" will.

Dieses Flag hndelt man sich natürlcih ein, wenn man per shell die provider Additive zurück spielt, abgesehen davon, dass man bei aktueller Firmware nicht mal so eben an die Shell ran kommt. Daher gingen meine Überlegungen ja auch in die folgende Richtung:

• erst die erweiterten Support Daten erstellen, um an die Additive zu gelangen
• dann die provider Variable im Urlader löschen
• dann ein Recovery
• dann die provider Variable im Urlader wieder setzen
• dann die aus den Support Daten extrahierten Additive wenn möglich über den Bootlader zurückspielen -> dadurch würde die Markierung in der ID 87 nicht entstehen

Gedacht ist das Scenario ja dafür, wenn man eine Providerbox (aus welchen Gründen auch immer) komplett in den originalen Auslieferungszustand zurücksetzen möchte.
Das Löschen von Node 87 mit einem anschließenden Werksreset macht ja nicht das gleiche.

 

[PeterPawn]

@KingTutt:
Soweit alles richtig, aber beim Schreiben über das System (also "cat ... > somewhere") ist der unkomprimierte Inhalt zu verwenden, die Kompression übernimmt der TFFS-Treiber. Das Hantieren mit "mknod" und das Auslesen der Major-ID kann einem das AVM-Skript "mkconfigfile" abnehmen, das habe ich bisher auch noch in so ziemlich jeder Firmware gefunden - aber das macht natürlich auch nichts anderes als Deine Kommandos oben, es tippt sich nur leichter (und ich würde das natürlich wieder mit "sed" lösen, weil ich gleich das "tffs" in einem Schritt auch noch "abschneiden" würde vor der ID).

Ansonsten kann man eine Box mit der Kommandozeile natürlich in den "originalen Zustand" versetzen ... vorausgesetzt, man hat in einer Partition ein System mit Telnet-Zugang (oder irgendeinem anderen Shell-Zugang) und in der anderen eines ohne. Dann löscht man den Node 87 (das Flag wird auch erst wieder gesetzt, wenn ein weiteres Login stattfindet über "ar7login"), schreibt den Node 29 neu (den dekomprimierten Inhalt des gesicherten Nodes verwenden, solange man über den TFFS-Treiber zugreift), schreibt die "provider"-Variable neu und schaltet auf die andere Partition um. Danach nur noch ein Update (ob das auf eine identische Version überhaupt noch funktioniert, habe ich aber auch noch nicht getestet, seitdem das Downgrade nicht mehr möglich ist) und es findet sich praktisch keine Spur mehr von anderen Systemen. Wobei das Update als letzter Schritt auch unterbleiben kann, beim nächsten "regulären" Update wird ohnehin das andere System überschrieben. Da die Einstellungen im TFFS nur einmal existieren, gelten sie ja für beide Systeme und es ist egal, aus welchem System heraus man dort die Änderungen vornimmt (gilt für "file nodes" und für "environment variables").

 

[Riverhopper]

Vermutlich muss man da das zusammengebastelte TFFS per Bootloader zurückspielen.

ich denke Du meinst hier PeterPawns eva_store_tffs Tool https://github.com/PeterPawn/YourFritz/blob/master/eva_tools/eva_store_tffs
mit dem man mit "eva_store_tffs MTDx <image-file>" eine "TFFS-Partitionen" flashen kann.

LG Riverhopper

 

[KingTutt]

@KingTutt:
Soweit alles richtig, aber beim Schreiben über das System (also "cat ... > somewhere") ist der unkomprimierte Inhalt zu verwenden, die Kompression übernimmt der TFFS-Treiber.

Danke, das war mir nicht bewusst!

Das Hantieren mit "mknod" und das Auslesen der Major-ID kann einem das AVM-Skript "mkconfigfile" abnehmen, das habe ich bisher auch noch in so ziemlich jeder Firmware gefunden - aber das macht natürlich auch nichts anderes als Deine Kommandos oben, es tippt sich nur leichter (und ich würde das natürlich wieder mit "sed" lösen, weil ich gleich das "tffs" in einem Schritt auch noch "abschneiden" würde vor der ID).

Magst Du das für mich und die Nachwelt hier noch einmal exemplarisch posten? Ich verstehe nicht ganz was da mit "abschneiden" gemeint ist.
Also "mkconfigfile 001D.inflated" .... sed?

Ansonsten kann man eine Box mit der Kommandozeile natürlich in den "originalen Zustand" versetzen ... löscht man den Node 87... schreibt den Node 29 neu ... schreibt die "provider"-Variable neu und schaltet auf die andere Partition um.

Das wäre dann in etwa:

echo clear_id 87 >/proc/tffs

mkconfigfile 001D.inflated 

echo "provider ewe_7490_0714" >/proc/sys/urlader/environment

wget -qO /var/tmp/switch_system http://yourfritz.de/7490/switch_system
chmod 755 /var/tmp/switch_system
./var/tmp/switch_system

Das switch_system mag evtl. auch in einer Zeile gehen, aber so weit bin ich noch nicht. Außerdem Wenn ich alles zusammen habe, dann versuche ich noch mal alles zusammen zu fassen, als eine Art Kochrezept

 

[PeterPawn]

"mknod" für die "provider_additive" als "Einzeiler" (unter dem Namen /var/tmp/additive):

mknod /var/tmp/additive c $(sed -n -e "s|^ \?\([0-9]*\) tffs\$|\1|p" /proc/devices) 29

Die kann dann mit "cat" einfach mit dem dekomprimierten Inhalt beschrieben werden, das Löschen kann entfallen, denn der Node liegt ja im tmpfs.

Das AVM-Skript "mkconfigfile" macht auch nichts anderes als das Ermitteln der TFFS-ID und das Ausführen eines "mknod"-Kommandos, allerdings wird neben dem Dateinamen für das char-Device noch die Minor-ID erwartet ... ein Beispiel für die Verwendung findet sich im "modscript" für die rc.user-Abarbeitung, dort wird genau damit das char-Device im tmpfs auch angelegt. Im Prinzip könnte man es auch als

mknod $1 c $(sed -n -e "s|^ \?\([0-9]*\) tffs\$|\1|p" /proc/devices) $2

abkürzen.

Für eine Umschaltung des Systems würde ich niemals das Skript von yourfritz.de verwenden, wenn ich es erst laden müßte (und es nicht ohnehin schon auf der Box ist).

Das macht ja auch nichts anderes, als "linux_fs_start" auszulesen und (über die Modulo-Division durch 2) den alternativen Wert zu ermitteln, um den dann mittels "echo" in /proc/sys/urlader/environment zu schreiben. Macht man das ohnehin von Hand (so schwierig ist der Schluß, was der andere Wert wäre, ja nicht), dann braucht man das ganze Skript nicht, das war nur für "dummies".

 

[PeterPawn]

Ich habe letztens mal den Dump der TFFS-Partition einer 7412 gesehen (es gibt ja nur einen einzelnen) und dabei festgestellt, daß da die Strukturen tatsächlich andere sind (und das liegt wohl nicht nur an den "out of band"-Daten). Damit ist die Frage, ob man mit "dissect_tffs_dump" auch das Abbild der NAND-Partition bearbeiten kann, mit "nein" zu beantworten (im GitHub habe ich das bereits vor ein paar Tagen entsprechend geändert). Man bräuchte also zumindest für den "Lese-Teil" eine abweichende Logik für einen Dump einer NAND-basierten TFFS-Partition.

 

[jimbovv]

Hey,

ich möchte etwas ähnliches machen. Mein FritzBox hat "nicht vom Hersteller unterstützt Änderungen". Die Meldung möchte ich mit einem Reset (via Recovery) weg bekommen. Leider geht das nicht wegen Provider addative. Habe die Fritz Box 7390 M-Net Edition. Habe zwar früher die Box schon mal entbrandet, aber scheinbar hat die FritzBox ihr Branding noch nicht komplett vergessen. Ich möchte jedoch nicht auf eine andere Version Downgraden und ich brauche auch kein Backup von der M-Net Edition, daher ist mein anliegen etwas anders als das ursprüngliche in diesem Thread:

Zusammengefasst: Wie schaffe ich es das meine Box das Branding vergisst und ich das Recovery ausführen kann, obwohl ich Fritz OS 6.51 habe welches kein Telnet mehr kann?

 

[KunterBunter]

Habe zwar früher die Box schon mal entbrandet, aber scheinbar hat die FritzBox ihr Branding noch nicht komplett vergessen.

Die Fritzboxen von M-net haben gar kein Branding. Was hast du da also genau gemacht?
Durch welche Aktion deinerseits wurde dann die Hinweismeldung hervorgerufen?
Ein Recovery kannst du bei gesetzter Environment Variablen provider = additive nicht ausführen, wie du selbst festgestellt hast. Also ist es die einzige Möglichkeit, die Environment Variable zu entfernen, wenn du wirklich ein Recovery machen willst, nur um die Meldung los zu werden.

 

[PeterPawn]

Die einfachste Lösung ist das Erstellen eines eigenen Images, das nicht anderes macht, als mit "echo clear_id 87 >/proc/tffs" den Marker-Node zu löschen (an manchen Stellen auch als "fwattrib" geführt, aber zum Löschen braucht man keinen Namen angeben) und dieses Image startet man dann aus dem Hauptspeicher der Box über den Bootloader. Nach dem Löschen bootet dann dieses Image noch einmal (diesmal aus dem Flash) und alles ist wieder in Ordnung.

Die Alternative ist etwas steiniger ... aus den erweiterten Support-Daten einen TFFS-Dump extrahieren (schauen, welcher der aktuellere ist) und dann mit diversen Skript-Dateien dieses TFFS in seine Bestandteile zerlegen, die Dateien für den Node 87 identifizieren und mit anderen Skriptdateien (die brauchen dann aber alle zusätzlichen Nodes als Parameterliste, eine Version mit einer Liste der "normalen Nodes" als Datei gibt es dort bisher nicht) dann wieder ein TFFS zusammenbauen und dieses anschließend über den Bootloader in beide Partitionen schreiben ... wie gesagt, viel viel mehr Aufwand.

Beim Erstellen des eigenen Images muß man nur in irgendeiner (nicht zu frühen) Datei in /etc/init.d/Sxx-irgendwas das erwähnte Kommando hinzufügen (dahinter ein "reboot", ggf. warten, bis der ctlmgr da ist - wie das geht, steht in /bin/boxfeaturedisable in rebootfeatovl()), neu packen lassen (kann alles auch "fwmod" übernehmen) und das Ergebnis (genauer die kernel.image aus diesem Image-(TAR-)File bei der 7390 mit "hidden root"-Image) über den Bootloader in den Speicher laden und starten. Dauert (mit etwas Routine, beim ersten Mal vielleicht länger, tut trotzdem nicht weh) ca. 10 Minuten (das Aus- und Einpacken braucht am längsten) ... und wenn man es richtig macht, ändert sich sonst an der FRITZ!Box absolut gar nichts.

 

[Pokemon20021]

dieses Image startet man dann aus dem Hauptspeicher der Box über den Bootloader.

Hallo PeterPawn,
ich denke hier kann man die 2 Skripte:
https://raw.githubusercontent.com/PeterPawn/YourFritz/master/eva_tools/image2ram
https://raw.githubusercontent.com/PeterPawn/YourFritz/master/eva_tools/eva_to_memory
nehmen, jedoch ist mir nicht klar, ob das Setting "startaddress=0x80000000" für alle NAND-Boxen, d.h. z.B. auch für FB7362 gilt ?

Gruß
Pokemon20021

EDIT: Text angepasst, eine Frage "Einpflegen des Löschbefehls ins Image" entfernt, da die Textstelle gefunden wurde; man muß nur das Posting zuende lesen ;-)