[Info] modfs - SquashFS-Image (AVM-Firmware) ändern für NAND-basierte FRITZ!Boxen

ThAlex

Mitglied
Mitglied seit
11 Aug 2006
Beiträge
630
Punkte für Reaktionen
1
Punkte
18
@topversand
Hast Du mal ein Listing des lib-Verzeichnisses unter 7.12 gemacht? Da sind eine Menge Links drin, wenn die bereinigt wurden, weil sie von AVM nicht mehr gebraucht werden, kann schon das ein- oder andere nicht mehr funktionieren.
Soweit ich gesehen habe, hast Du jetzt allerdings wieder 7.11 drauf (oder nur auf die alte Version umgeschaltet?).

Gruß
Thomas
 

jono

Neuer User
Mitglied seit
5 Okt 2005
Beiträge
88
Punkte für Reaktionen
0
Punkte
6
Da weiß ich leider nicht, wo ich das in modfs einfügen muss.
Ich hänge mich hier mal an: Wo und wie muss ich das in modfs einfügen?
Die Tipps von Eisbaerin haben nichts gebracht. modfs startet ja aus einem anderen Verzeichnis.
 

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
12,485
Punkte für Reaktionen
841
Punkte
113
Wie wäre es denn mit der Idee, einfach mal die vom AVM-Wechsel auf uClibc-ng betroffenen Programme neu zu erzeugen?

Da liegt die eigentliche Ursache des Problems, weil die alte uClibc 0.9.33.irgendwas eine libc.so.0 erwartet (und damit auch alle gegen diese alte Version (dynamisch) gelinkten Programme) und die uClibc-ng eine libc.so.1 verwendet, weil ihre Versionsnummer jenseits von 1 liegt.

Das vermeintliche Problem ist also im Handumdrehen an seiner Wurzel zu beseitigen (wer tatsächlich ausschließlich alte Binärdateien aus irgendwelchen Quellen hat, sollte diese aus Security-Gründen ohnehin nicht verwenden - von der Vertrauenswürdigkeit der Quelle bis hin zu inzwischen beseitigten Lücken, wenn die Software schon ein paar Jahre auf dem Buckel hat) und die Suche nach irgendwelchen Workarounds gleicht dem Pflaster auf dem Knie, wenn in Wahrheit der Tumor das Ende der mit dem Pflaster kaschierten Beschwerden längst eingeläutet hat.

Und wer tatsächlich nicht selbst in der Lage ist, die verwendeten Programme zu erzeugen, der kann ja mal bei demjenigen nachhaken, der die derzeit benutzte Version veröffentlicht hat - die uClibc-ng verwendet AVM jetzt schon seit der 06.98-Labor-Reihe und deren Inhouse-Versionen (und iirc auch erste Labor-Exemplare) kamen Ende 2017/Anfang 2018 heraus ... das sind jetzt knapp zwei Jahre und in dieser Zeit sollte man es eigentlich auf die Reihe bekommen haben, einfach mal neue Binaries zu erzeugen.
 

topversand

Neuer User
Mitglied seit
3 Mrz 2013
Beiträge
11
Punkte für Reaktionen
0
Punkte
3
Seiten vom Apache(auf Fritzbox) werden im LAN Netzwerk unter Win10 nicht vollständig geladen.
Mit Dyndns über Internet geht es .
Über Wlan Android keine Probleme.
Der Fehler tritt erst seit Fritz Os 7.12 auf.
Ich habe den Fehler jetzt gefunden. Musste den MTU auf 2500 setzen und die Seiten werden wieder richtig geladen.
Der Wert ist doch nicht normal oder? Ist da ein Fehler im Fritz OS?
 

KunterBunter

IPPF-Urgestein
Mitglied seit
12 Okt 2005
Beiträge
23,256
Punkte für Reaktionen
172
Punkte
63

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
12,485
Punkte für Reaktionen
841
Punkte
113
Weil ich mich - nach entsprechenden Nachfragen, die wohl auch damit zu tun hatten, daß ein echtes Löschen des Kontos auch bei den bereits geschriebenen Beiträgen den Autoren gelöscht hätte (soweit ich das verstanden hatte) - dann doch damit zufrieden gab, daß der Account bestehen bleibt und ich mich nur dazu entschieden hatte, mir stattdessen selbst eine Auszeit bis Oktober "zu verordnen" ... auch in der Hoffnung, daß sich das Ganze in dieser Zeit (bei mir) wieder etwas herunterkühlen würde bzw. von den Leuten, mit denen diese Auseinandersetzungen geführt wurden (und da meine ich jetzt auch nicht die, die hier öffentlich lesbar waren, sondern mehr die "hinter den Kulissen"), dann doch noch einmal irgendwelche Antworten auf Argumente und Nachfragen meinerseits kommen würden.

Ersteres hat halbwegs funktioniert - ich habe mich beruhigt und bin für mich zu der Überzeugung gelangt, daß ich die Leute, die sich mit viel Elan einen Platz auf meiner "Ignore"-Liste erkämpft haben (die gibt es auch zweigeteilt - bei der einen sehe ich die Beiträge gar nicht mehr und bei der anderen verkneife ich mir jede weitere Reaktion), auch deutlich länger in den Genuß dieser Sonderstellung kommen lassen sollte und nicht - wie bisher - nach ~14 Tagen wieder aufräume, weil (vermeintlich) jeder eine weitere Chance verdient hätte.

Letzteres hat dann aber eher nicht funktioniert, es sind immer noch einige "Nachfragen" meinerseits offen - aber da erwarte ich inzwischen auch keine Antworten mehr (bzw. ich möchte gar nicht, daß sich das jetzt noch ändert - weil es diese "Weltsicht" bzw. dieses Fazit meinerseits dann bloß beeinträchtigen würde).

Ich bemühe mich also auch, meinerseits deutlich weniger pointiert zu reagieren ... die Unkenntnis hinsichtlich der Beiträge mancher (dank des Fensterplatzes in der erwähnten Liste, der diesen reserviert wurde), macht das auch wesentlich einfacher und bei den Fragen, wo der Fragesteller (meines Erachtens) gegen meine eigene "policy" verstößt (wenn ich solche neuen Threads überhaupt wahrnehme und sie nicht direkt über "Mark forums read" in Vergessenheit geraten), melde ich mich dann vielleicht nach 14 Tagen oder drei Seiten an Beiträgen erst zu Wort (wenn das bis dahin nicht geklärt wurde oder ich der Ansicht bin, ich könnte noch einen Aspekt beitragen, der bis dahin nicht auftauchte oder wieder unter die Räder kam).

Das heißt noch nicht, daß ich mit der Richtung, in die sich das IPPF generell entwickelt, tatsächlich glücklich wäre (aber es juckt mich nicht länger) ... denn wenn ich meinen "view port" für dieses Board nur noch auf rein technische Fragen beschränke und mich die generelle Entwicklung (auch wenn es schon eine recht lange "Beziehung" ist, die einen mit dem IPPF verbindet) inzwischen eher kalt läßt (weil ich jetzt auch nicht mehr alle neuen Threads/Fragen/Beiträge lese, wie das in der Vergangenheit bisher der Fall war - heute entscheide ich schon anhand des Titels, ob ich überhaupt in einen Thread hineinsehe), geht das "so einigermaßen" und ich will es anderen nicht unbedingt nachmachen mit dem "endgültigen Abschied".

Wobei es schon spannend ist, den Blick auch mal in die Vergangenheit schweifen zu lassen ... es kann ja jeder selbst mal prüfen, wer von den Protagonisten aus diesem Thread:


noch aktiv ist (und in welchem Umfang bzw. zu welchen Themen) und welcher Standpunkt da jeweils vertreten wurde. Es gibt ja auch einige prominente Beispiele, wo die Leute deutlich zum Ausdruck gebracht haben, daß sie mit der Entwicklung unzufrieden waren(sind) und die deshalb "in den Sack gehauen" haben und nicht nur, weil sie keine Zeit mehr für das IPPF hatten.

Die Diskussion über die "Ausrichtung" ist jedenfalls schon sehr alt ... nur hat sich seit dieser Zeit (das sind jetzt > 11 Jahre) die Entwicklung (des Anspruchsdenken) nach meiner Meinung (die muß man nicht teilen und ich will die in diesem Thread auch nicht diskutieren - einer ernsthaften Diskussion stelle ich mich gerne unter "Allgemeines" oder irgendwo in dieser Richtung) nicht wirklich verlangsamt oder wurde irgendwie aktiv (durch die Moderatoren und da meine ich vor und nach dem Eigentümerwechsel) gebremst ... ich sehe da eher eine Progression.

Da ich diese Entwicklung für das IPPF wohl nicht aufhalten kann (meine finsteren Pläne zur Übernahme des IPPF, die ich offenbar mit @KunterBunter und @NDiIPP ausgeheckt hatte, wurden ja vorzeitig aufgedeckt), bleibt am Ende nur die Adaption des eigenen Verhaltens / des eigenen Engagements an diese Entwicklung(en).

--------------------------------------------------------------------------------------------------

Außerdem gibt es eben Threads wie diesen hier (und das habe ich in #1619 schon geschrieben - das war gleich zu Beginn meiner Auszeit), wo der "Support" für meine bisher angebotenen Projekte irgendwie "beheimatet" ist und solange ich kein eigenes Board aufmache oder bei einem anderen "Unterschlupf" finde (das haben schon andere vor mir gemacht/machen müssen, u.a. auch das "ruKernelTool" - wobei ich dabei eben kein alternatives Board akzeptieren kann/will (wie Zebradem oder DEB), was nebenbei noch Themen beherbergt, die sich in "Grauzonen" bewegen), ist das hier die einzige Möglichkeit der "Interaktion", wenn man mal von den GitHub-Issues in https://github.com/PeterPawn/modfs absieht ... und die sind generell nicht so richtig gut für "Fragen" oder neue Erklärungen/Funktionen geeignet, sondern eher für die Fehlermeldung/-diskussion.

--------------------------------------------------------------------------------------------------

Solange sich das hier in einem "zivilen Rahmen" bewegt, schreibe/antworte ich als nun doch weiter im IPPF (erst wieder seit Oktober, denn die selbstverordnete Pause habe ich strikt "durchgehalten") - aber primär bis ausschließlich eben zu rein technischen Fragen und mit wachsender Liste von zu ignorierenden Teilnehmern.

Geht das am Ende dann doch wieder zu weit nach meiner Ansicht und greift die Moderation dann nicht ein, geht das aber auch wieder zurück in die "innere Emigration" und ich beschränke weitere Aktivitäten ausschließlich auf den Support "meiner" (bestehenden) Projekte - andere "Veröffentlichungen" (von eigenen Threads im IPPF bis zu Open-Source-Software) habe ich ja schon deutlich zurückgefahren.

Und nein: Ich werde meinerseits definitiv NICHT dazu übergehen, jemanden aktiv über den "Report"-Link zu denunzieren, nur weil mir etwas nicht paßt, was derjenige geschrieben hat - dazu lasse ich mich auf keinem denkbaren Weg verleiten. Verstößt etwas (einigermaßen unzweifelhaft) gegen Gesetze (Links auf nicht-legale Inhalte) oder Board-Regeln (wie SEO-Placement), ist das etwas vollkommen anderes (halt nicht nur "Meinung") - ebenso, wenn man diesen Link zur "Kommunikation" mit den Moderatoren als Gruppe nutzen will.
 
  • Like
Reaktionen: Einerwiekeinersonst

jono

Neuer User
Mitglied seit
5 Okt 2005
Beiträge
88
Punkte für Reaktionen
0
Punkte
6
Danke, PeterPawn, für deine Antwort.
So kann es gehen:
Datei CSmtp in einem Editor öffnen: Link libc.so.0 durch libc.so.1 ersetzen
Geänderte CSmtp in FritzBox kopieren
Ich weis, nicht die feine englische Art ...
Gefunden im Nachbaruniversum: photovoltaikforum
 

ThAlex

Mitglied
Mitglied seit
11 Aug 2006
Beiträge
630
Punkte für Reaktionen
1
Punkte
18
Habe jetzt die 7.12 mit modfs installiert. Telnet lässt sich nicht mehr mit Telefoncode reaktivieren, wie noch in der 7.11 wieder. Beim Start oder nach einem Neustart des rc.voip ist es aber wieder aktiv.
Sonst ist mir noch nichts aufgefallen.

Gruß
Thomas
 

Chatty

Aktives Mitglied
Mitglied seit
13 Mrz 2006
Beiträge
1,714
Punkte für Reaktionen
28
Punkte
48
Ich wollte gerade FRITZ.Box_7490-07.19-73949-Inhaus modden, aber leider schlägt das Entpacken fehl, weil das loopback-Device zu klein ist:
Code:
# df /dev/loop1
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/loop1              126931    126931         0 100% /var/tmp/4105_1575586135
Und modfs fängt das offensichtlich gar nicht als Fehler ab:
Code:
ext3-Dateisystem über loopback-Device einbinden ... OK
Entpacken des root-Dateisystems für die Modifikationen ... OK

Das entpackte Dateisystem ist jetzt bereit für die Modifikationen.
Aber 0% ist einige Zeit vor dem Abschluss des Entpackens erreicht.
 

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
12,485
Punkte für Reaktionen
841
Punkte
113
Die Verwendung eines ext3-Images als Container auf Partitionen, die nicht "nativ" von Linux unterstützt werden (und wo man damit die Firmware nicht entpacken kann), ist schon lange nicht mehr wirklich auf dem Schirm.

Angesichts der Größe der Daten im Image (inzwischen kratzt AVM an der 100 MB-Grenze beim Inhalt) reichen die 128 MB im vorbereiteten ext3-Image sicherlich nicht mehr aus heutzutage ... ggf. wird da auch noch das ext2-Image (mit der "filesystem_core.squashfs") selbst erst einmal ausgepackt und das hat dann auch noch einmal 29 MB ... und so läppert sich das zusammen.

Wer tatsächlich mit dem "ext3"-Image arbeiten will, der muß entweder die Datei "files/128MB_ext3.gz" durch ein größeres Image ersetzen (das ist vordefiniert und gepackt, weil früher auf einer FRITZ!Box die Tools zum dynamischen Erstellen nicht vorhanden waren, das ging schon beim "mkfs" los ... und das müßte auch heute dort noch fehlen) oder die dynamische Erzeugung eines solchen Images ins Skript einbauen (seitdem die statische BusyBox dabei ist und auch nur noch diese genutzt wird, sind auch die Tools eigentlich vorhanden - wobei das dann alles schnarchlangsam ist, wie die Benutzung dieses Images insgesamt) oder eben doch gleich eine Partition mit einem nativen Dateisystem verwenden, denn auch die "Empfehlung" für den Aufbau des verwendeten USB-Speichers hat sich im Laufe der Zeit ja gewandelt und der "letzte Stand" wäre es, daß man einfach einen USB-Stick mit einer Swap-Partition und einer "extX"-Partition mit ausreichender Größe bereithält ... das geht erstens am schnellsten und ist zweitens nicht auf die Container-Datei angewiesen.

Wobei es (zumindest theoretisch) auch funktionieren müßte, wenn man selbst VOR dem Aufruf von "modfs" ein größeres Image in der Box einhängt (wenn man denn unbedingt mit einem solchen Image arbeiten will, weil man nur FAT/NTFS/was_weiss_ich-Volumes an der Box hat) - denn das Skript weicht ja nur dann auf das eigene 128 MB-Image aus, wenn es keinen anderen Ort mit passendem Dateisystem finden kann - deshalb gab es wohl auch in den letzten Jahren so wenige, die das brauchten.

Wobei ich (bei einer 7490 zumindest) auch erwarten würde, daß vor der Verwendung des ext3-Containers noch die Benutzung des NAND-Flashs für das NAS käme ... außer dort ist auch nicht mehr genug Platz, um die Anforderungen (die stehen ganz vorne im Skript und können jederzeit im GitHub-Repo nachgeschlagen werden: https://github.com/PeterPawn/modfs/blob/master/modfs#L83 - gerade der "extract_space_needed" ist inzwischen viel zu klein dimensioniert und alle anderen Angaben müßten auch neu berechnet werden, wenn man ernsthaft mit diesen Werten arbeiten will und nicht einfach ein passendes Volume mit ausreichend freiem Platz bereitstellt) zu erfüllen oder es wurde kein "INCLUDE_NAND=1" gefunden: https://github.com/PeterPawn/modfs/blob/master/modfs#L2432 - auch das wurde ja nachträglich eingebaut (und beschrieben hier im Thread), damit der interne NAND-Flash (der im Gegensatz zu einem USB-Stick auch nicht einfach ersetzt werden kann) nicht überstrapaziert wird, solange der Benutzer das nicht explizit so haben will.

Für mich persönlich ist es jedenfalls keine wirkliche Überraschung, wenn das ohne ein natives Volume mit genug freiem Speicherplatz nicht (mehr) richtig funktioniert ... die Werte stammen noch aus der 06.2x-Zeit und danach wechselte die "Empfehlung" auf einen USB-Stick mit Swap-Space und nativem Volume und damit gab es keine Notwendigkeit, die Werte (ständig) anzupassen.

Ich wäre eher erstaunt, wenn das mit der 07.11 oder 07.12 noch funktioniert hätte und nicht schon dabei gegen den Baum ging. Das hat mit der 07.19-Labor-Reihe an sich also eher nichts zu tun ... bitte betrachtet das alles als "nicht länger unterstützt" (ich baue das trotzdem nicht aus, das bleibt als Relikt erst mal drin) und verwendet passend formatierte USB-Sticks oder sorgt dafür, daß "modfs" den NAND-Flash des NAS verwenden kann. Letzteres bringt wohl nur bei der 7490 bzw. 3490 etwas, weil die genug Platz im Angebot haben und das braucht dann auch zusätzliche Angaben beim Aufruf, sowohl für den Start ohne Swap-Space (https://github.com/PeterPawn/modfs/blob/master/modfs#L2477), als auch für die Benutzung des YAFFS-FS für das Arbeitsverzeichnis (https://github.com/PeterPawn/modfs/blob/master/modfs#L2432).
 

Chatty

Aktives Mitglied
Mitglied seit
13 Mrz 2006
Beiträge
1,714
Punkte für Reaktionen
28
Punkte
48
Ich habe einen Stick mit ext2 zur Verfügung gestellt. Mein Tipp: Es ähnlich wie mit swap zu machen. Standardmäßig prüft das Skript das Vorhandensein und bricht sonst ab. Man kann die Verwendung des NAND aber erzwingen.
 

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
12,485
Punkte für Reaktionen
841
Punkte
113
Da ich für die 07.19 ohnehin ein paar Anpassungen vornehmen muß, denke ich tatsächlich darüber nach, den Teil mit dem ext3-Image komplett "totzulegen" (aber nicht zu entfernen) ... wenn wirklich jemand mal keinen Stick mit einem nativen Volume haben sollte, kann er sich ja (wie oben schon geschrieben) das passende Image selbst erstellen und dann auch mounten. Damit ist es dann automatisch erforderlich, daß der "modfs"-Benutzer seinerseits dafür sorgt, daß ein natives Linux-Dateisystem vorhanden ist (weil der Platz in anderen FS nicht mehr berücksichtigt wird) ... nur stimmen damit die Berechnungen für aktuelle Versionen immer noch nicht (und das Skript kann auch erst nach dem Entpacken ermitteln, welche Version es da vor sich hat). Ich will die Angaben aber auch nicht stumpf anheben (z.B. auf 256 MB oder gar 512 MB), weil es dann wieder in anderen Situationen (z.B. bei teilweise belegtem Platz im NAS-Flash auf 7490/7390, der aber normalerweise noch ausreichen würde) wieder zu hohe Anforderungen würden (die teilweise gar nicht mehr befriedigt werden könnten aus den ~400 MB, die da noch frei sind, wenn man die OS-Partitionen abzieht).

Das manuelle Anlegen eines passenden Images erfolgt analog zum Anlegen eines Swap-Files, wie es hier irgendwo beschrieben wurde ... zuerst mittels "dd" eine Datei in der gewünschten Größe erzeugen (die "ext"-Dateisysteme wachsen und schrumpfen nicht dynamisch), als Eingabedatei bietet sich dabei "/dev/zero" an, weil die erzeugte Datei dann nur binäre Nullen enthält:
Code:
[email protected]:/var/media/ftp/YourFritz $ dd if=/dev/zero of=new.image bs=1M count=512
512+0 records in
512+0 records out
536870912 bytes (512.0MB) copied, 26.367051 seconds, 19.4MB/s
[email protected]:/var/media/ftp/YourFritz $
für eine 512 MB-Containerdatei mit dem Namen "new.image".

Danach dann mittels "mke2fs" (das findet man bei "modfs" im "bin"-Ordner, sortiert nach den HWRevisions der unterstützten Boxen) die Dateisystem-Strukturen einrichten ... am besten für eine "ext3"-Partition. "ext2" fehlt das Journal, was bei Neustarts durch Steckerziehen zu Inkonsistenzen führt, die schlimmstenfalls das Mounten verhindern und "ext4" hat ein paar Merkmale ggü. "ext3", die in diesem Kontext kein Mensch braucht.

Code:
[email protected]:/var/media/ftp/YourFritz $ mke2fs -t ext3 -L modfs new.image
mke2fs 1.42.13 (17-May-2015)
Creating filesystem with 131072 4k blocks and 32768 inodes
Filesystem UUID: 2a0b98c0-f466-4888-848c-bf96af6e91cd
Superblock backups stored on blocks:
        32768, 98304

Allocating group tables: done
Writing inode tables: done
Creating journal (4096 blocks): done
Writing superblocks and filesystem accounting information: done

[email protected]:/var/media/ftp/YourFritz $
Das "-L modfs" sorgt dafür, daß die Partition im Image ein Label "modfs" erhält ... würde das Image so gemountet, daß "udev" mit den AVM-Dateien dabei eine Rolle spielt, würde auch "modfs" als Verzeichnisname für den Mountpoint verwendet. Aber die "normalen" "udev"-Skripte von AVM springen darauf nicht an, daher muß man das meistens noch von Hand mounten. Das Anlegen (und Löschen) des notwendigen Loop-Devices übernimmt normalerweise das "mount"-Applet der BusyBox.

Code:
[email protected]:/var/media/ftp/YourFritz $ mkdir /var/media/ftp/modfs
[email protected]:/var/media/ftp/YourFritz $ losetup -a
/dev/loop0: 0 /filesystem_core.squashfs
/dev/loop1: 0 /wrapper/custom.custom
/dev/loop2: 0 /var/media/ftp/bintools.custom
[email protected]:/var/media/ftp/YourFritz $ mount new.image /var/media/ftp/modfs
[email protected]:/var/media/ftp/YourFritz $ losetup -a
/dev/loop0: 0 /filesystem_core.squashfs
/dev/loop1: 0 /wrapper/custom.custom
/dev/loop2: 0 /var/media/ftp/bintools.custom
/dev/loop3: 0 /var/media/ftp/YourFritz/new.image
[email protected]:/var/media/ftp/YourFritz $ mount | grep modfs
/dev/loop3 on /var/media/ftp/modfs type ext3 (rw,relatime,errors=continue,user_xattr,acl,barrier=1,data=writeback)
[email protected]:/var/media/ftp/YourFritz $ cd /var/media/ftp/modfs/
[email protected]:/var/media/ftp/modfs $ wget -q -O - http://yourfritz.de/modfs.tgz | gunzip | tar -x
[email protected]:/var/media/ftp/modfs $ ls -l
-rw-rw-r--    1 1000     1001         11080 May  9  2018 BOOTSELECTION.ger
-rw-rw-r--    1 1000     1001         18092 Mar 31  2017 LICENSE
drwxrwxr-x    9 1000     1001          4096 Dec  6 21:45 bin
drwxrwxr-x    2 1000     1001          4096 Dec  6 21:45 contrib
drwxrwxr-x    2 1000     1001          4096 Dec  6 21:45 files
drwxrwxr-x    2 1000     1001          4096 Dec  6 21:45 locale
drwx------    2 root     root         16384 Dec  6 21:38 lost+found
-rwxr-xr-x    1 1000     1001        107023 Jun 28 16:12 modfs
dr-xr-xr--    3 1000     1001          4096 Dec  6 21:45 modscripts
[email protected]:/var/media/ftp/modfs $
Wobei ich gerade festgestellt habe, daß das Skript derzeit bei der Suche nach einem Arbeitsverzeichnis tatsächlich nur die Mountpoints berücksichtigt, an denen direkt ein USB-Speicher gemountet wurde. Das kommt mit auf die Liste der geplanten Änderungen ... ob/wann das was wird, weiß ich noch nicht. Daher gilt bis auf weiteres immer noch die "Forderung", einen passenden USB-Stick bereitzustellen.
 

Whoopie

Aktives Mitglied
Mitglied seit
19 Okt 2004
Beiträge
838
Punkte für Reaktionen
5
Punkte
18
Hallo,

ich habe jetzt eine FB 6591 Cable und möchte bei dieser Telnet aktivieren und ein Skript anpassen.
Mir ist ehrlich gesagt unklar, wie ich eine modifizierte FW mit modfs an meinem Linux-PC erstellen kann. Ich lese meist, dass es direkt auf der FB durchgeführt wird.

@PeterPawn: wenn du einen Tester für diese Box benötigst, sag einfach Bescheid.

Gruß,
Whoopie
 

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
12,485
Punkte für Reaktionen
841
Punkte
113
Die 6591 ist etwas komplett anderes und "modfs" wird Dir hierbei nicht helfen können.

Zu diesem Thema solltest Du eher den Thread von @fesc lesen ... der befaßt sich mit der 6591 und ihren Eigenheiten und enthält auch eine Beschreibung (ich würde es nicht Anleitung nennen, weil es wohl auch (m.E. zurecht) nicht darauf zielt, jeden - auch ohne eigene Kenntnisse - zu einer Modifikation der Firmware zu führen), wie man über das UEFI-BIOS der Box eine eigene Shell lädt, von der aus man dann wieder die SquashFS-Images im eMMC modifizieren kann, um dort bei laufendem FRITZ!OS einen permanenten Shell-Zugriff zu erhalten (besser ohnehin mit SSH anstelle von Telnet).

"modfs" ist ausschließlich darauf ausgerichtet, die Firmware auf einer VR9-Box (die verwenden eine YAFFS2-Partition als "Host" für das SquashFS-Image mit dem Root-Dateisystem für das FRITZ!OS) direkt zu modifizieren (und soll dazu tatsächlich - in den meisten Fällen - auf der Box selbst ausgeführt werden).

Dazu muß also bereits vorher ein Shell-Zugang vorhanden sein - und für die (üblichen) VR9-Modelle gibt es dafür dann auch noch die Möglichkeit, eine Shell-in-a-Box-Instanz in das bereits installierte System einer solchen Box einzupflanzen, indem man sie mit einem speziellen Image aus dem Speicher startet.

Dieses Image installiert dann nicht komplett sich selbst (wie das die AVM-Images machen) in den Flash-Speicher, sondern nur den gewünschten Zusatz-Service (hier eben Shell-in-a-Box) in die erwähnte YAFFS2-Partition ... deshalb funktioniert das auf diesem Weg auch nur bei den Geräten, die ebendiesen Aufbau haben.
 

grisu911112

Neuer User
Mitglied seit
19 Jan 2010
Beiträge
5
Punkte für Reaktionen
0
Punkte
1
Hallo,
ich komme bei modfs nicht weiter.
Ich habe eine FB 7490
1. mit 7.12 frisch recovert
2. mit EVA-Discover.ps1 den Bootmodus "eingefangen"
3. mit
Code:
.\EVA-FTP-Client.ps1 -Verbose -Debug -ScriptBlock { BootDeviceFromImage .\implant_siab_3.10.107.image.7490 }
Shell in Box installiert
4. dann die Sicherung der Fritzbox wieder hergestellt um wieder online zu sein
5. mit
Code:
mkdir -p /var/mod;cd /var/mod;wget -qO- http://yourfritz.de/modfs.tgz | gunzip -c | tar x
modfs heruntergeladen und entpackt
6. mit
Code:
./modfs
modfs gestartet

Beim ersten mal wurde gefragt ob in die zweiter Partionin das gleich System installiert werden soll dies wurde bejaht.

Um nun die Modifikation durchzuführen habe ich Option "b - ein neues root-Dateisystem aus einem Firmware-Download vom Server des Herstellers verwenden" gewählt. Dies wird wie folgt angebrochen:
Code:
Bitte den Buchstaben des gewünschten Punktes eingeben : b

Ermitteln der Download-URL für die Version 113.07.12 ...  Fehler
Es wurde keine Quelle für den Download der Version 113.07.12 gefunden.
dann noch der Versuch mit Option "a - das root-Dateisystem des laufenden Systems benutzen". Hier wird das root-System entpackt und der "Frage - Antwort"-Katalog abgearbeitet. Das Packen des Boor-Systems bricht dann wieder mit "Fehler" ab.

ich habe bei beider Fehlern über "showshrigbuf modfs" mal den Log in eine Textdatei kopiert un mit angehangen.
Vielleicht kann sich das mal jemand anschauen und mir ein wenig Hilfestellung geben.

Gruß Grisu
 

Anhänge

Micha0815

IPPF-Promi
Mitglied seit
25 Feb 2008
Beiträge
3,606
Punkte für Reaktionen
180
Punkte
63
Versuche doch, falls es mit dem DL hakt "händisch" die 7.12-FW ins NAS zu kopieren ... u.U. hakt es beim Unterschied int.<->DE-Version ... und darüber zu installieren?
Du musst dabei u.U. die Owner-Rechte des image im modfs-Verzeichnis anpassen und die noexec-Problematik im Hinterkopf behalten.
LG und auf die Schnelle aus dem Kopf
 

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
12,485
Punkte für Reaktionen
841
Punkte
113
Die automatische Suche bei AVM nach derselben Version, wie die bereits auf der Box installierte, verläßt sich darauf, daß "juis_check" mit Parameter "-c" (dadurch wird "Patch" dekrementiert, aus 07.12 wird also 07.11) bei der Abfrage von AVM auch die richtige Antwort erhält.

Mangels aktiver Version 07.12 kann ich das für eine 7490 gerade nicht überprüfen ... aber man kann jederzeit selbst diesen Aufruf machen (die notwendigen Dateien stehen im "modfs"-Archiv im "bin"-Folder) und nach der Anzeige (fast am Ende) in der "modfs_Download.txt" liefert AVM eben die Antwort, daß es keine neuere Version gäbe (der Return-Code ist 2) ... da kann "modfs" dann auch keine Version von AVM laden. Einen anderen Weg als das Dekrementieren von "Patch" kenne ich nicht, um die aktuelle Version bzw. die URL für deren Download zu ermitteln ... bisher hat das eigentlich auch immer für die aktuelle Version geklappt.

Aber wenn das mal nicht funktioniert, kann man ja einfach selbst die notwendige Version laden (woher auch immer) und auf der Box ablegen ... beim Aufruf mit "modfs update image-name" kann man den Namen der Image-Datei ja dann angeben.

Worin der Fehler beim "mksquashfs" in der anderen Log-Datei jetzt bestehen soll, kann ich auch nicht sicher erkennen ... mich irritiert aber schon die Länge des Protokolls, denn selbst wenn das ein Ringbuffer ist und die ersten Zeilen auch mal überschrieben werden können, so würde doch ohne zusätzliche Angaben (von denen da oben ja nichts steht) ein Ringbuffer für 64 KB angelegt: https://github.com/PeterPawn/modfs/blob/master/modfs#L2816 und da sollte deutlich mehr hineinpassen (der Platz ist auch reserviert und würde bei Speichermangel nicht fehlen), als man in der Datei sehen kann.

Außerdem verstehe ich halt nicht, warum das Skript hier (zumindest sieht man das in der Datei "modfs_Fehler.txt") das "tmpfs" der Box als "Arbeitsverzeichnis" auserkoren hat - da fehlt aber auch der komplette Beginn der Datei (oder zumindest des Protokolls im Ringbuffer), in dem man das irgendwie recherchieren könnte (da steht dann auch die "Aufrufzeile", die man zum Verfolgen braucht).

Wie das aussehen würde, kann man sich in der anderen Datei ansehen. Da ich (siehe weiter vorne, war aber gerade auch erst irgendwo Thema) auf die korrekten Größenangaben und passenden Abläufe bei den "nicht update"-Aufrufen aber auch nicht mehr schwören würde, würde ich es hier einfach noch einmal mit dem erwähnten "update"-Aufruf mit Angabe der Datei versuchen ... natürlich auf einer frisch gestarteten Box.

Dann sollte auch die Protokoll-Datei ausreichend groß angelegt werden und man sieht ggf. mal ein komplettes Protokoll. Es ist nämlich (in der "modfs_Download.txt") durchaus noch richtig, wenn der Download in das "tmpfs" erfolgt ... aber spätestens an dieser Stelle: https://github.com/PeterPawn/modfs/blob/master/modfs#L3316 , wo dann 134 MB (zusätzlich) an freiem Speicherplatz zum Entpacken des Images gesucht werden, sollte auf einer 7490 (und auch Deine hat - nach der Anzeige in der "modfs_Download.txt" am Beginn - nur 118 MB im "tmpfs" gesamt) eine zwangsweise Umschaltung auf ein Arbeitsverzeichnis auf der "ext3"-Partition (oder im NAND, da aber nur bei passenden Environment-Settings) erfolgen.

Denkbar, daß das beim Aufruf ohne weitere Parameter (also beim "Klonen" des derzeit installierten Systems) nicht mit den passenden Größenangaben läuft ... aber seitdem ich auch den Test, ob die Versionen in beiden Partitionen tatsächlich identisch sind, am Beginn deaktiviert habe (schon vor längerer Zeit), würde ich auch nichts mehr auf die korrekte Funktion dieses Zweigs geben - erst recht nicht angesichts des gestiegenen Platzbedarfs der AVM-Firmware.

Eigentlich soll(te) bei dieser Version (wenn wirklich die Partitionen dasselbe System enthalten) nur das laufenden Root-FS (also die "filesystem_core.squashfs" aus dem "wrapper"-Verzeichnis) entpackt, modifiziert, eingepackt und in die (zweite) YAFFS2-Partition kopiert werden - dafür braucht man weniger Platz, weil weder die originale Image-Datei, noch "kernel.image" oder "filesystem.image" irgendwo zwischengelagert werden müssen. Was da jetzt konkret bei der Suche nach genug freiem Speicher als Größenangabe verwendet wurde, weiß ich nicht ... steht auch nicht in der "modfs_Error.txt" (warum auch immer das da fehlen mag, denn 64KB reichen bei mir sogar für 694 Zeilen:
Code:
/var/media/ftp/YourFritz/modfs # wc -l modfs.log.1575573159
694 modfs.log.1575573159
/var/media/ftp/YourFritz/modfs # ls -l modfs.log.1575573159
-rw-r--r--    1 root     root         63028 Dec  5 20:12 modfs.log.1575573159
/var/media/ftp/YourFritz/modfs #
) und daher kann ich dazu auch nichts sagen (jedenfalls nicht im Moment). Wenn das generell zu lang werden sollte als Protokoll (bisher waren 64 KB die max. Größe für die Ringbuffer-Programme von AVM, die da ja nachgenutzt werden), kann/muß man einfach ein paar der "modscripts" auslassen (EDIT: also die Datei selbst oder nur die "x"-Flags löschen), wenn man erst mal die generelle Funktion abklären will - das ergibt dann auch weniger Einträge in der Protokoll-Datei (die ja bei Dir > 100 KB sein soll mit ihren 552 Zeilen, wobei die Zeitstempel schon mal als 4 Byte "epoch" gespeichert sind und nicht als 26 Byte Zeichenketten).

Aber wenn man ganz sichergehen will, zwingt man einfach "modfs" per Environment-Variable auf ein bestimmtes Arbeitsverzeichnis ... das wäre hier ein Aufruf mit:
Code:
MODFS_WORKING_DIR=/var/media/ftp/SMI-USBDISK-02 modfs ...
und dann sollte - bei genug freiem Platz auf der Partition - das Ganze auch durchlaufen; jedenfalls wenn es nicht noch der richtigen Antwort vom JUIS von AVM bedarf (was man mit dem "update imagefile" vermeidet).

=========================================================================

Denn selbst wenn ich (mit meinem Tool "juis_check") heute von Hand nach einer Nachfolgeversion für 07.11 suche (und zwar auch mit der richtigen "Revision", während "-c" die auf "00000" setzen würde), erhalte ich auch die Auskunft, es gäbe keine neuere Firmware:
Code:
vidar:/home/FritzBox/FB7490/firmware $ juis_check fb7490 Version=113.07.11-68718
usr/local/bin/juis_check: No newer version found, check was made with source version '113.07.11-68718'.
Ich glaube erst mal nicht, daß mein Skript plötzlich "kaputt" sein soll ... eher käme mir da eine Änderung bei AVM in den Sinn, die sich auf das Ergebnis auswirkt.

Dazu müßte man aber auch wieder wissen, wie das für die anderen Programme zur JUIS-Abfrage aussieht (das mit der Suche nach der aktuellen Version ist ja schon eine Besonderheit von "juis_check" (die anderen brauchen das ja auch nicht, während es genau für "modfs" erforderlich war) und das Verstecken der realen MAC-Adresse ebenfalls) und dafür habe ich im Moment weder Zeit noch Lust.

Erst dann, wenn ich definitiv weiß, daß es an meinem eigenen "juis_check" liegt und dieses von AVM irgendwie erkannt und mit abweichenden Antworten "versorgt" wird, sehe ich hier die Notwendigkeit, mir das genauer anzusehen.

EDIT: Ja, für die 07.1x-Versionen passen die Angaben zum benötigten Speicherplatz einfach nicht mehr ... die haben schon im entpackten Zustand mehr als 90 MB und in die Größenangabe für den benötigten Platz (96 MB in "free_space_for_unpack_tmpfs": https://github.com/PeterPawn/modfs/blob/master/modfs#L88) sollte da (nach den früheren Berechnungen) noch das Image selbst auch reinpassen - das geht natürlich absehbar schief und bei der Variante mit dem Download wird für das Image ein anderes Verzeichnis gewählt (was das Problem entschärft, weil damit per se nicht genug Platz bleibt und auf eine Partition ausgewichen wird) bzw. beim Update mit vorhandener Datei liegt das dann auch an einem anderen Ort und braucht zusätzlichen Platz beim Entpacken des Firmware-Images (das ist noch nicht das Entpacken des SquashFS-Images), was ebenfalls hilfreich ist beim "Verdrängen" aus dem (begrenzten) "tmpfs".

Jetzt könnte man hingehen und die Angaben (deutlich) erhöhen ... mit dem Ergebnis, daß es für frühere Versionen dann wieder zuviel wäre. Ein dynamisches Ermitteln des tatsächlich benötigten Platzes liegt jenseits dessen, was ich hier noch implementieren will.
 
Zuletzt bearbeitet:

grisu911112

Neuer User
Mitglied seit
19 Jan 2010
Beiträge
5
Punkte für Reaktionen
0
Punkte
1
Hallo,
so jetzt hat es geklappt, schien ein Problem mit dem Speicher zu sein. Habe jetz alles von /var/media/ftp/mod ausgeführt. Vorher mit einem Remount auch vom ftp aus ausführbar gemacht. Dann hat er als tmp-Verzeichnis für das erstellen des neuen Root-Systems den USB-Stick genutzt und dann lief es durch.

Also Danke für die Denkansätze

Gruß Grisu
 

Chatty

Aktives Mitglied
Mitglied seit
13 Mrz 2006
Beiträge
1,714
Punkte für Reaktionen
28
Punkte
48
Bei mir stürzt modfs beim Auspacken (manchmal auch erst, wenn es auf die Eingaben zu den modscripts wartet) seit 07.19-75160 ab. 07.19-74979 kann ich immer noch bearbeiten. Es steht eine 3GB-Swap-Partition bereit.
Ich vermute, man muss eine der Variablen ab free_space_for_unpack ändern?
 

3CX PBX - GRATIS
Linux / Win / Cloud

Statistik des Forums

Themen
233,805
Beiträge
2,038,688
Mitglieder
352,770
Neuestes Mitglied
Trombo76