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

°> Hast Du denn beim Aktivieren über das Telefon einen Bestätigungs-Ton erhalten? Jetzt wo Du fragst, nicht so wie normalerweise. Danke für die Antwort. Wenn es bei Dir funktioniert, handelt es sich nicht um ein generelles Problem.
Dann probier ich einfach mal weiter.
Nach mehreren Versuchen auf 2 verschiedenen 7490 Boxen funktioniert telnet nunmehr. modfs ist dabei in allen Fällen erfolgreich durchgelaufen, alle Optionen wurden angewendet. Warum es jetzt funktioniert bzw. vorher nicht, kann ich
mir jedoch nach wie vor nicht erklären. Das tut auch nichts zur Sache. Ich berichte nur vom Verhalten. Es ist keine Kritik!

@PeterPawn
Ich verstehe auch durchaus, wenn es nervt. Aber ich habe schon vorab nach modfs/telnet/7.11 gesucht. Bei einigen Berichten hat es funktioniert und bei anderen nicht bzw. erst nach mehreren Versuchen.
Und ich erwarte auch keine Antwort, es sei denn es soll etwas explizit ausprobiert werden, was der Fehlersuche/Verbesserung dienen kann. Also bitte nicht jeden Beitrag gleich persönlich nehmen.
 
Zuletzt bearbeitet:
Wie kommt denn die Modifikation bei Dir auf die Box?
Na ganz einfach ... ich lasse durch das "modscript" mit dem Namen "mod_custom_images" die erwähnte "E99-custom" in die modifizierte Firmware einbauen und dann muß man nur noch ein passendes Image (oder auch mehrere, ganz nach Belieben) an den Stellen hinterlegen, die von "E99-custom" geprüft werden.

Dieses "modscript" ist schon hier im Thread in #1 aufgeführt, inklusive Link zur Erklärung, was die "E99-custom" kann, wie sie funktioniert und wie man sie einsetzen kann. Was soll ich denn da nun noch beschreiben? Überspitzt gefragt: Soll ich es vertonen und vorsingen oder als YT-Video bereitstellen?

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

Ehrlich ... ich mag ja manchmal tatsächlich etwas ungeduldig sein, denn ich bin irgendwie auch "unendlich müde" von diesen ganzen Diskussionen - aber hast Du überhaupt mal darüber nachgedacht, meiner Aufforderung zu folgen und diesen Thread zu lesen? Bereits in #1 kann man doch dann gar nicht mehr anders, als über diese Modifikation "zu stolpern". Wie schafft man es, diese Stelle zu "überlesen"?

Die Tatsache, daß dieses Script dann irgendwann wg. seltener Benutzung bei den "modfs"-Usern in das "inactive"-Verzeichnis gewandert ist (damit das nicht ständig mit "abgefragt" wird, wenn die wenigsten es benutzen), steht auch irgendwo in diesem Thread - abgesehen davon, daß man es bei der Suche nach "E99-custom" (und das steht wieder als Stichwort in einer der vorhergehenden Antworten an Dich) auch sofort in den "modfs"-Dateien findet.

Auch der "custom_modscripts"-Mechanismus zur (automatischen) Auswahl der anzuwendenden Modifikationen ist in diesem Thread von mir (mehrfach) erklärt worden - ich bin mir wirklich keines Versäumnisses bewußt und weiß beim besten Willen manchmal nicht, was ich noch antworten soll ... außer das tatsächlich alles noch einmal von Beginn an herunterzubeten und dazu habe ich einfach auch keinen Bock, weil ich die Notwendigkeit nicht sehe und mir auch noch niemand diese tatsächlich mit plausiblen Argumenten verdeutlichen konnte.

Warum sollte ich das wiederholen? Nur weil dann "bekannt" ist, daß es irgendwo in den letzten Beiträgen in diesem Thread (erneut) steht? Die sind in einem Jahr auch nicht mehr "das Ende" dieses Threads (vermutlich jedenfalls nicht) und damit genauso gut oder schlecht zu finden, wie jede andere Erklärung in den vorhergehenden Beiträgen in diesem Thread.

Warum reicht es denn nicht aus, daß es überhaupt in diesem Thread dokumentiert ist? An mangelnder Ausführlichkeit von #644 wird es ja hoffentlich nicht liegen ... aber da kann man es am Ende ja auch KEINEM jemals recht machen. Dem einen ist es zu lang, dem anderen zu kompliziert, der dritte will das in einer anderen Schriftart und der vierte versteht nicht, warum "E99-custom" kein FAT32 oder NTFS unterstützt.

Es mag sogar sein, daß die Suche nicht mehr ganz so einfach ist, wie sie früher mal war ... das läuft aber in erster Linie darauf hinaus, daß das IPPF bei bestimmten Suchworten nicht mehr auf den vorderen Plätzen liegt - die gezielte Suche innerhalb des IPPF funktioniert immer noch leidlich, sowohl die interne als auch die über Suchmaschinen mit Beschränken auf eine spezielle Site.

Aber beim sequentiellen Lesen genau dieses Threads hier zum Thema "modfs", wird das kaum hinderlich sein. Ich KANN die Arbeit und die Entwicklung über 4 1/2 Jahre nicht in einem einzelnen Beitrag zusammenfassen (und ich will es auch gar nicht, zumindest nicht mehr hier im IPPF, wo mir Zeichenlimits für Beiträge und fehlende Formatierungsmöglichkeiten ständig einen Strich durch die Rechnung machen) ... das MUSS man als "modfs"-Benutzer einfach auch mal verstehen und vor allem akzeptieren und sich dann tatsächlich selbst "drehen".

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

Zum Thema "Telnet starten": Ich habe gerade noch einmal mit der 113.07.11 im "privaten Modus" des "telefon"-Daemons getestet ... das Aktivieren und Deaktivieren von Telnet funktioniert auch in dieser Version noch ebenso, wie in den vorhergehenden. Die Telefon-Codes werden (auf dem Display des angeschlossenen ISDN-Telefons) sogar wieder korrekt quittiert - nur der erneute Start nach dem Deaktivieren innerhalb desselben "telefon"-Prozesses funktioniert nicht ... aber das ist auch schon seit längerer Zeit so und bereits bekannt (und dokumentiert).

Startet man den "telefon"-Daemon aber neu (ein Weg wäre ein "/etc/init.d/rc.voip restart" - ob/wann das beim Ändern von Telefonie-Einstellungen bei AVM auch erfolgt, weiß ich nicht, kann jeder selbst testen), wird sowohl das Flag berücksichtigt (Byte 14466 in der Datei "/var/flash/fx_conf") und der Daemon bei "0x01" sofort gestartet, als auch später bei der ersten Eingabe von #96*7*, wenn das Flag beim Start des "telefon"-Daemons noch auf "0xFF" stand.

An Änderungen bei AVM liegt es also mit größter Wahrscheinlichkeit nicht, wenn jemand den "telnetd" nicht starten kann - eher an fehlenden Modifikationen (neben der Reaktivierung des "telnetd" braucht es halt auch den "privaten Modus" für den "telefon"-Daemon, der bei den "modscripts" als "Abarbeitung von 'calllog' reaktivieren" firmiert) oder schlicht am falschen Handling, weil sich jemand damit nicht auskennt und auch die letzten 10 Seiten in diesem Thread, wo es u.a. auch um dieses Thema mehrfach ging, nicht gelesen hat. Warum ich das Skript zum Einstellen des "privaten Modus" für den "telefon"-Daemon am Ende "Aktivieren von 'calllog'" genannt habe, habe ich auch irgendwo hier im Thread begründet(!) - der Name leitet sich schlicht von der einschneidensten Veränderung ab, die mit dieser Modifikation zutage tritt.

Wer die letzten Seiten hier nicht lesen will, der sucht halt nach dem Problem. Wenn ich bei Google mit der Frage "site:ip-phone-forum.de PeterPawn telnet aktivieren modfs problem" aufschlage, kriege ich im dritten Link (ohne Werbung, falls die jemand anzeigen läßt) den auf die Seite 79 in diesem Thread als Vorschlag und auf dieser Seite steht dann ab dem fünften Beitrag allerhand zu den Startproblemen des "telnetd", die mit 06.98 Einzug in die Firmware gehalten haben.
suche telnet start problem bei google.PNG
Das heißt also, daß man bei der eigenen Suche nach der Antwort nur die letzten 7 Seiten vor dieser hier durchforsten müßte - ist das tatsächlich so schwer oder gar zuviel verlangt?

Und selbst die letzten 10 Seiten zu lesen, wenn man sich längere Zeit nicht mit dem Thema befaßt hat (was ich bei "von 06.93 aus" einfach mal "unterstelle"), ist in meinen Augen mehr als zumutbar ... immerhin hat man diese Zeit ja zwischendrin "gespart" und wer solches "Aufholenmüssen" vermeiden will, der muß eben ständig mitlesen. Punkt. Ist das jemandem zuviel, zwingt ihn auch niemand zur Verwendung von "modfs" ... sowohl das Angebot durch mich als auch die Nutzung durch irgendeinen Interessenten ist nach wie vor absolut freiwillig.

Ich tue zwar mein Möglichstes, um wirklich jedem unter die Arme zu greifen, der sich ernsthaft mit "modfs" befassen will und auch die eigene Zeit zu investieren bereit ist, aber ich lasse mich genauso wenig zum Support "zwingen" (und erst recht nicht zu Wiederholungen von bereits Geschriebenem), wie ich jemanden zur Benutzung von "modfs" verdonnern kann.

Ich bin mir sicher, daß @sulihari das gar nicht "böse gemeint" hat ... das ist bei mir aber genauso (bzw. genauso wenig der Fall). Ich bin halt nur "angefressen", wenn man sich zuvor schon die Mühe gemacht hat, etwas zu beschreiben und ggf. auch wieder zu ändern und das dann hier wieder zu "verkünden" und erläutern ... und dann interessiert es doch niemanden, weil "Fragen kostet ja nichts."

Das ist aber genau nicht der Fall ... das kostet zwar kein Geld hier, aber es kostet Nerven und Zeit der anderen und ich begreife immer beim besten Willen nicht, wieso man sich "die Blöße" so einer (ich nenne sie mal "überflüssig", auch wenn mir andere Adjektive einfallen würden) Frage gibt, wenn man es doch (und nun wirklich "ganz einfach", denn das oben Geschriebene zu Google ist kaum einfacher zu haben) selbst "ermitteln" könnte.

Aber nun sollten mit diesem Beitrag auch die notwendigen Links erneut vorliegen (und weitere Erklärungen/Tests, die hier vielleicht erstmals aufgeführt sind - wenn es um die Frage geht, ob AVM bei der 113.07.11 noch einmal geändert hat) und ich werde mich irgendwann auch wieder beruhigen ... ich hoffe nur inständig, daß nicht innerhalb der nächsten drei Monate dann der/die Nächste mit genau derselben Frage hier aufläuft. Denn nach meinem Verständnis hätte dann der 1000. Fragesteller dasselbe "Anrecht" auf die eigene Antwort, wie die 999 vor ihm (inkl. @sulihari) ... das kann auf Dauer aber nicht gut gehen.

Ich hab's mir halt mal wieder "vom Herzen geschrieben" ... also "Mund abputzen" und weitermachen (und nicht zu persönlich nehmen). Ich bin ja durchaus auch erfreut, wenn jemand "modfs" benutzen möchte (schließlich habe ich es dafür ja auch entworfen) ... aber ich bleibe eben auch dabei, daß es eher die Leute als Zielgruppe hat, die sich auch etwas intensiver damit befassen wollen und damit in der Lage sind, selbst Infos zu suchen, zu finden und anzuwenden. Die anderen sollen es dann einfach bleiben lassen ... das gefährdet dann auch die Sicherheit ihrer FRITZ!Boxen nicht. Denn eines ist sicherlich auch klar ... ich engagiere mich ja nicht für sicherere FRITZ!Boxen, um gleichzeitig jedem x-beliebigen FRITZ!Box-Besitzer den Strick in die Hand zu drücken, mit dem er dem Leben seiner Box (und der Sicherheit seines Heimnetzwerks) ein Ende setzen kann. Die Verwendung von "modfs" erfordert ein Minimum an Verantwortungsbewußtsein und Engagement, wenn man es (erfolgreich) benutzen will. Einfacher als Freetz ist es sicherlich immer noch ...
 
Zuletzt bearbeitet:
Thema Boot-Manager:
Ich habe die Erkennung, ob ein System modifiziert wurde, geändert. Bisher war es so, daß beim Vorhandensein des Boot-Managers automatisch davon ausgegangen wurde, daß der natürlich nur enthalten ist, wenn das System irgendwie modifiziert wurde. Die Entscheidung, was für diese Modifikation benutzt wurde, wurde anhand der Existenz entsprechender Versionsdateien in "/etc" entschieden. Im "no-freetz"-Modus erzeugt Freetz diese Datei (/etc/.freetz-version) aber gar nicht ... damit bleibt für diese Variante nichts weiter als die Feststellung, daß man die Quelle der Modifikation nicht ermitteln kann - in der Anzeige erscheint das jetzt (wie bei anderen, unbekannten Modifikationen auch) als Bindestrich an der Stelle, wo ansonsten "YourFritz", "Freetz" oder "modfs" stehen würde.

Bei den Boxen, wo das Root-Dateisystem in der "filesystem_core.squashfs" liegt, wurde immer dann, wenn es keine Versionsdatei irgendeines der drei Frameworks für die Modifikation gab, auf das Erstellungsdatum des SquashFS-Images zurückgegriffen. Daher tauchte bei einer mit "no-freetz"-Modus behandelten 7590 keine "zuletzt geändert ..."-Zeile auf (wie in #1676 zu sehen), während die bei der 7490 in #1677 immer ausgegeben wurde - halt mit leerem "modifiziert durch", weil das sich beim "no-freetz"-Modus nicht ermitteln ließ (an diese Stelle tritt ja jetzt der (schon länger geplante) Bindestrich als Anzeige, daß die Angabe fehlt).

Obwohl es aber nicht zwingend ist (besonders nicht im alternativen System, denn das kann ja absolut "original AVM" sein), daß ein System überhaupt geändert wurde, wäre die Anzeige auf der 7490 immer auf ein "zuletzt modifiziert" hinausgelaufen ... daher wird jetzt das Dateidatum des SquashFS-Images mit der Angabe von AVM zum Erstellungsdatum der Firmware verglichen und wenn diese beiden Zeitangaben weniger als 10 Minuten auseinander liegen, wird auf "originales System" entschieden (ich gehe mal davon aus, daß niemand außerhalb von AVM eine Firmware innerhalb von 10 Minuten nach deren Erstellen erhält und sie dann auch noch modifizieren kann in diesen 10 Minuten).

Das setzt allerdings voraus, daß die Angaben von AVM auch in der neuen Variante, wo das Erstellungsdatum der Firmware anhand des Dateidatums der "/etc/version" ermittelt wird, von allen Frameworks für die Modifikation unverändert übernommen werden - ansonsten stimmt aber am Ende auch das angezeigte Datum der Firmware nicht mehr mit den Angaben hier im Board überein (in den entsprechenden Firmware-Threads).

Da es mit ein paar Kniffen auch machbar ist, ein System nur temporär zu ändern und dabei trotzdem den Boot.-Manager in das System zu integrieren, wird auch nicht länger automatisch davon ausgegangen, daß das aktive System beim Vorhandensein des Boot-Managers IMMER modifiziert sein müsse - diese Angabe soll sich ja nur auf permanente Modifikationen, die auch einen Neustart überleben, beziehen.

Wenn es irgendwann im "no-freetz"-Modus von Freetz doch noch irgendeine (eindeutige) Marker-Datei geben sollte, kann ich die Anzeige auch noch in diese Richtung erweitern (im Moment sehe ich keinen passenden Ansatz in der "fwmod_custom" im "no-freetz"-Abschnitt) ... ebenso, falls weitere Frameworks auftauchen und benutzt werden. Wenn Bedarf besteht und eine Erkennung/Unterscheidung sinnvoll und "stabil" möglich ist (bisher heißt die Versionsdatei bei beiden Forks ".freetz-version" und "stabil" meint ein Verfahren, was sich nicht in vier Wochen schon wieder ändert), bin ich auch bereit, die Anzeige um "Freetz-NG" (oder wie auch immer die korreke Schreibweise sein mag, meine diesbezügliche Frage harrt noch immer der Antwort) zu erweitern, nachdem der Einbau des Boot-Managers dort inzwischen auch wieder möglich ist (von r15195 bis r15627 war er ja aus irgendwelchen Gründen "verbannt").

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

Thema "Telnet-Daemon":
Ich habe das "mod_telnet_enable" dahingehend überarbeitet, daß man nicht länger die Box neu starten muß, wenn man den Telnet-Daemon per Telefon abgeschaltet hatte (was man grundsätzlich machen sollte, solange er nicht benötigt wird, denn das Teil ist nun mal eine wandelnde Sicherheitslücke) und ihn danach mit dem Telefon-Code erneut starten will. Bekanntlich funktioniert das nicht, solange die Instanz des "telefon"-Daemons dieselbe ist. Daher habe ich ein kleines Skript zusammengeklöppelt (https://github.com/PeterPawn/YourFritz/blob/master/tools/telnetd_by_avm), das zunächst mal die Voraussetzungen für den Start des "telnetd" durch den "telefon"-Daemon prüft und - wenn diese erfüllt sind, wobei auf dem "CONFIG_RELEASE=0" bestanden wird, das entweder in der "rc.conf", der "featovl.cfg" oder per Modifikation "mod_enable_calllog" gesetzt werden kann - danach prüft, ob der "telefon"-Daemon läuft, aber der "telnetd" nicht. Ist das der Fall, wird über "rc.voip restart" der "telefon"-Daemon neu gestartet, der dann - da alle anderen Voraussetzungen erfüllt sind, was ja zuvor getestet wurde - auch den "telnetd" wieder anwirft.

Dieses Skript mußte nun nur noch irgendwo in der AVM-Firmware eingebaut werden, wo man es auch ohne Neustart und ohne aktiven Shell-Zugang ausführen kann ... ich habe mich hier für die "/usr/bin/system_status" entschieden, die wohl eher ein Relikt aus längst vergangener Zeit, aber immer noch vorhanden ist. In dieser Datei wird am Ende der Aufruf des erwähnten Shell-Skripts eingebaut ... das heißt dann für den Benutzer eines entsprechend modifizierten Systems, daß er nach dem Aktivieren des Telnet-Daemons über #96*7* nur noch einmal die URL "fritz.box/cgi-bin/system_status" aufrufen muß ... sollte der Telnet-Daemon nicht laufen, obwohl die Voraussetzungen alle erfüllt sind, wird der Telefon-Service neu gestartet und mit ihm dann auch der Telnet-Daemon. Ist eine Voraussetzung nicht erfüllt, wird das in der Ausgabe von "system_status" angezeigt ... läuft der "telnetd" bereits, passiert genau gar nichts weiter.

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

Beide Änderungen sind direkt in die aktuell auf yourfritz.de bereitgestellte Version eingeflossen - Fehler bitte melden ... obwohl ich alle geänderten Teilfunktionen getestet habe, habe ich keinen "großen Test" gemacht, bei dem die geänderten Firmware-Versionen dann auch geflasht und gestartet werden, sondern nur jeweils durch "bind"-Mounts die geänderten Dateien im laufenden System ersetzt und auf das erwartete Ergebnis geprüft.
 
  • Like
Reaktionen: NDiIPP
Kannst Du mal bitte die Ausgabe von "gui_bootmanager get_values nocache" und "gui_bootmanager debug" posten? Es geht mir erst mal darum zu ermitteln, ob schon das Eruieren der Werte nicht paßt oder ob es "nur" die korrekte Anzeige ist, die hier nicht erscheinen will.
Wird diese Ausgabe von Dir noch benötigt, oder hat sich das mit den Änderungen in folgendem Posting bereits erledigt? Zur Zeit ist meine Zeit zum Debuggen leider sehr begrenzt...
Thema Boot-Manager:
 
@KingTutt:
Nein, danke - hat sich erledigt. Ich war nur im ersten Moment irritiert, weil ich tatsächlich der Ansicht war, selbst der "no-freetz"-Modus würde die "/etc/.freetz-version" im Image hinterlassen - bis ich dann genauer in die "fwmod" geschaut habe und außerdem gibt es sicherlich auch noch Leute, die mit "fwmod -u" und "fwmod -p" komplett "von Hand" modifizieren. Dann kam noch die Frage hinzu, wieso bei Deiner 7490 Änderungen angezeigt wurden und bei der 7590 (ebenfalls ohne eine der drei "Marker-Dateien") nicht - als ich das gefunden hatte, war das Problem umzingelt. Dann kam noch die fehlende Ausgabe des Bindestrichs hinzu, der schon länger "angelegt" ist im Skript und wg. falschem Code nicht ausgegeben wurde.

Das ist jetzt erst mal alles erledigt ... ich denke im Moment über eine Möglichkeit nach, die Modifikationen durch Freetz auch im "no-freetz"-Modus oder beim Entpacken/Packen mit "fwmod" zu erkennen. Leider hat Freetz die Änderung durch AVM übernommen, daß das Feld "mkfs_time" im Superblock nicht länger diese Zeitangabe enthält, sondern die Größe des Images. Ich weiß gar nicht mehr genau, ob das originale Format da tatsächlich zu einem Fehler führte und welche Auswirkungen dieser dann hatte ... schaut man in die Kernel-Quellen, taucht da keine echte Referenz auf das Feld "mkfs_time" in einem SquashFS-Superblock auf.

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

Solange also nicht irgendwelche AVM-Tools direkt auf ein solches Image zugreifen (wenn es als Datei vorliegt) oder gar auf ein MTD-Device oder eine eMMC-Partition und dort den Superblock analysieren, sollte der Unterschied zwar vorhanden sein, aber keine wirkliche Rolle spielen. Damit könnte man das (wenn der Patch in Freetz entfällt - zumindest als Standard und er nur in speziellen Fällen, mit speziellen Optionen aktiviert wird) dann doch wieder unterscheiden, ob es sich um ein originales AVM-Image handelt (mit der Längenangabe in diesem Feld, die deutlich kleiner als ein "epoch"-Wert ist) oder ob das "nacherzählt" und mit eigenem Programm gepackt wurde. Alles natürlich nur unter der Voraussetzung, daß die Änderung bei AVM tatsächlich keine Bedeutung hat ... andererseits ließen sich selbstgepackte Images auch vor der Existenz dieses Patches (https://github.com/Freetz/freetz/commit/fe6e2339e3c8325b88cadb5b25c2b60342baf99e) erfolgreich entpacken und auch mounten, wenn ich mich richtig erinnere.

Es gab damals ja ab und an mal Probleme, als AVM das Format einführte ... oft genug lag deren Ursache aber ganz woanders und da ist mir zwar bei der Analyse von Image-Files dieser Unterschied irgendwann aufgefallen und ich habe den garantiert auch mal als "mögliche Fehlerquelle" irgendwo aufgeführt (hier und hier in jedem Falle), aber seitdem die passenden Kernel-Quellen vorliegen, kann man ja - zumindest für den beim Mounten zuständigen Code - überprüfen, ob die zusätzliche Längenangabe irgendwo verwendet wird und das ist - soweit ich sehen kann - nicht der Fall.

Selbst wenn die damalige These, daß der "flash_update.ko" das bei der 7360 irgendwie getestet hätte (die m.W. auch nie "bewiesen" wurde - es funktionierte dann halt mit der Längenangabe in "mkfs_time" und "nopad"-Option), stimmen sollte, spielt das für NAND-Boxen (bzw. alles, was "dual boot" wäre) keine Geige, denn da wird der "flash_update.ko" gar nicht verwendet - der kommt (afaik) nur da zum Einsatz, wo der Flash-Speicher im laufenden System benutzt wird und damit das System nach dem Flashen (und zwar unabhängig vom Ergebnis, weil schon das Löschen vor dem Schreiben das System lahmlegt bei allem, was sich nicht bereits im RAM befindet) unbedingt neu gebootet werden muß (und zwar "ohne Nachsorge").

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

Ich werde mal eine Diskussion in dieser Richtung im Freetz-GitHub vom Zaune brechen ... mal sehen, ob ich das als "Experiment" durchsetzen kann oder ob ich es auf meinen Fork beschränken muß. Damit hätte man aber wieder einen Indikator, ob es sich um ein AVM-Image handelt oder ob das neu gepackt wurde. Da die Supportdaten nichts in dieser Richtung abfragen und damit daraus auch kein neues "verräterisches Detail" wird, daß man eine modifizierte Version einsetzt (und außerdem wäre ich ja für eine Option, mit der man das regeln kann, was in "mkfs_time" gespeichert wird), sehe ich erst einmal kein Problem ... außer daß man beim Packen für Boxen mit NOR-Flash (single system) ggf. die zusätzliche Option verwenden müßte.

Wer seine Box an AVM sendet, sollte ohnehin vorher wieder die originale Firmware installieren bzw. er kriegt bei Freetz ja auch den Hinweis, daß der Einsatz von Freetz zum Verlust der Gewährleistung durch den Hersteller führen würde. [ Ob das zwingend stimmt (https://freetz.github.io), steht auf einem anderen Blatt, denn die "Gewährleistung" (genauer die Haftung bei Mängeln) ist gesetzlich geregelt (Dauer in §438 BGB) und nur für die "Herstellergarantie" bestimmt AVM selbst die Regeln. ]

Da sehe ich also insgesamt keinen Nachteil bei einem funktionierenden Zeitstempel, solange nicht tatsächlich in irgendeiner Firmware für irgendein Modell doch noch auf diese Längenangabe zurückgegriffen wird. Bei Boxen mit einem einzelnen System macht auch der Einsatz des Boot-Managers nur sehr begrenzt Sinn.

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

Parallel werde ich mal im "modfs" diesen Zeitstempel nach dem Packen einfach mittels "dd"-Kommando setzen - bei den Boxen, die da unterstützt werden, kommt garantiert kein "flash_update.ko" zum Einsatz. Wenn das dann - bei einer ausreichenden Anzahl von Einsätzen - ohne Probleme funktioniert, kann man als Alternative auch noch über einen zusätzlichen Aufruf in "fwmod" nachdenken, welcher einfach nur diesen Zeitstempel im Superblock eines Images setzt ... das kann man dann auch beim "no-freetz"-Mode noch einbauen (geht aber erst nach dem "mksquashfs" und das findet wieder in "fwmod" und nicht in "fwmod_custom" statt).
 
Ehrlich ... ich mag ja manchmal tatsächlich etwas ungeduldig sein...
Danke für die Abreibung ;-). Ich habe es jetzt leider noch nicht geschafft, den ganzen Thread von Anfang bis Ende durchzulesen.
Aber mit Deiner Hilfe ist mir es gelungen, mein Ziel umzusetzen und SIAB zusammen mit einem Update zu starten.

Ich habe das inaktivierte Skript "mod_custom_images" in das Verzeichnis mit den aktiven Modskripten kopiert und dann das Update getestet.

Aber von "customize the original firmware with extension packages" war nichts zu sehen. Dann erst ist mir aufgefallen, dass das Skript nicht ausführbar war.
Nach "chmod +x .../mod_custom_images" war immer noch keine Abfrage zu sehen, ob "mod_custom_images" angewendet werden sollte.
Die Kontrolle des Protokolls ergab aber, dass es ohne Nachfrage angewandt worden war.

Das SIAB.image habe ich in /var/media/ftp/ abgelegt und in shellinabox_tmpfs.custom umbenannt und dann das Update durchlaufen lassen.

Im Ergebnis liegt der Inhalt des Image unter /var/shellinabox/.

Habe ich es richtig verstanden, dass das beim nächsten Neustart wieder verschwunden wäre, wenn die shellinabox_tmpfs.costum nicht mehr unter /var/media/ftp/ zu finden ist?

Telnet habe ich aktiviert, calllog auch - und seit der letzten Version von modfs lässt es sich wieder über den Telefoncode reaktivieren, nachdem man es ausgeschaltet hat.
(Da wäre noch ein wechselseitiger Hinweis hilfreich - bei calllog "ist Voraussetzung, um Telnet einschalten zu können" und bei Telnet "bitte beachten calllog muss aktiviert sein")

Zum Schluss noch folgendes: Es ist schon ein bisschen witzig, wenn Du schreibst
Ich wüßte halt nicht, wie diese Alternative aussehen sollte
und dann etwas weiter unten genau eine solche Alternative beschreibst, wie mit Hilfe des Modscripts "mod_custom_images"
= "customize the original firmware with extension packages" genau das erreicht werden kann.
Wenn man übrigens der Erläuterung in #644 https://www.ip-phone-forum.de/threads/modfs-squashfs-image-avm-firmware-ändern-für-nand-basierte-fritz-boxen.273304/post-2156232 folgt, tritt das Problem mit den gefärbten Codeblöcken auf, die sind nun im Code enthalten und müssen erst wieder entfernt werden.

Und eigentlich ist es doch Voraussetzung, wenn man auf Telnet verzichten will, eine Alternative zu haben, die Telnet ersetzen kann.
Mir wäre allerdings SSH lieber, dann könnte ich vielleicht auch mal mit WinSCP drauf schauen oder ich hätte zumindest nicht die Einschränkungen von Shellinabox mit Schwierigkeiten beim copy / paste aus einem anderen Fenster und der relativ kurzen Scrollback-Möglichkeit im Browserfenster (oder kann man das erhöhen?). Das Inhaltsverzeichnis eines Image mit Shellinabox und SSH konnte ich übrigens nicht finden (die Suche hier im Forum lässt keine Suche nach SSH zu, weil das Wort zu kurz ist). Trotzdem herzlichen Dank.

EDIT: Das Inhaltsverzeichnis einer custom.Image habe ich jetzt doch noch entdeckt, es handelte sich um einen Anhang im Beitrag #1362
https://www.ip-phone-forum.de/attachments/custom_image_content-txt.93820/. Da konnte der Inhalt ja nicht in der Forumssuche gefunden werden.

Gruß
Thomas
 
Zuletzt bearbeitet:
  • Like
Reaktionen: Micha0815
Es ist schon ein bisschen witzig
Meine Aussage, die Du dort zitierst, bezog sich ja eindeutig darauf, daß ich keine Alternative zu dem bisher bereits von mir Bereitgestellten wüßte, die einigermaßen generisch wäre. Ich gehe natürlich (und in meinen Augen auch zurecht) davon aus, daß man - wenn man sich mit "modfs" befaßt - auch die bisher von mir dafür bereitgestellten Modifikationen und meine Erläuterungen dazu in seine Recherchen einbezieht.

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

Mir wäre allerdings SSH lieber
Niemand sollte Dich davon abhalten können ... die Binaries für einen SSH-Server in der FRITZ!Box gibt es sogar wieder in "yf_bin" bereits "vorkompiliert" und wer kein Linux-System auf einem PC hat, kann seine FRITZ!Box als "first stage build host" benutzen und sich dort das passende SquashFS-Image zusammenpacken lassen.

Warum gibt es von mir kein "fertiges" SSH-Paket? Auch die Frage habe ich bereits mehrfach beantwortet. Da ich generell gegen die Verwendung von Kennwörtern beim SSH-Zugriff bin, sind die von mir bereitgestellten Binärdateien (konkret hier "dropbearmulti") so modifiziert, daß sie nur die schlüsselbasierte Authentifizierung zulassen: https://github.com/PeterPawn/YourFreetz/commit/29d81c6c019550ef7c930891af1c538a8eac21cf - für den Host-Key wird dabei das ohnehin vorhandene FRITZ!Box-Zertifikat benutzt. Die öffentlichen Schlüssel, denen der Zugriff erlaubt sein soll, muß man aber noch irgendwie selbst auf die Box bringen - und das ist auch genau der Teil, der in einer generischen Lösung gar nicht funktionieren KANN, denn schließlich sollte jeder sein eigenes Schlüsselpaar haben.

Da es auch nicht ganz trivial ist und obendrein noch vom Modell der verwendeten FRITZ!Box abhängt, wo und wie man diese Schlüssel so speichert, daß sie (a) änderbar (sofern man das möchte) und (b) trotzdem vor unbefugtem (Schreib-)Zugriff sicher sind, gibt es dazu zwar auch "Empfehlungen" meinerseits, aber ebenfalls keine "allgemeingültige Lösung". Das fängt nämlich bereits damit an, daß man sich erst einmal überlegen muß, wo und wie man nun das Home-Verzeichnis (i.d.R. bei einer FRITZ!Box halt nur für den "root"-Benutzer, denn es macht nur wenig Sinn, auf die AVM-Benutzerverwaltung noch eine eigene aufzupropfen) anlegt und ob das dann eine persistente Speicherung von Dateien ermöglicht oder nur volatile Daten enthalten sein sollen. Man kann den eigenen öffentlichen Key ja auch einfach in eine "authorized_keys"-Datei in "/etc" packen und dann diese nur noch in das auserwählte Home-Verzeichnis kopieren (natürlich im Unterverzeichnis ".ssh", aber das sieht man ja auch in den Optionen, mit denen "dropbear" von mir erzeugt wurde).

Wenn man sich das "rc.shellinaboxd" als Vorlage nimmt und darin beim Start des SSH-Servers einfach aus einem "inline"-File (aka "here document") eine "authorized_keys" an der richtigen Stelle erstellt, die den eigenen (öffentlichen) Key enthält, ist das auch nur eine weitere, denkbare Lösung ... denn dann muß man wieder dafür sorgen, daß das eigene (Customizing.-)Image an einer Stelle liegt, wo definitiv niemand mit NAS-Zugriffen das gesamte Image austauschen kann.

Aber genau für solche Fälle gibt es ja wieder eine passende Option im "modfs" (die steht dann auf der Seite NACH dem von Dir inzwischen offenbar gelesenen Beitrag #644 - deshalb kann und will ich es auch niemandem ersparen, sich tatsächlich den Thread durchzulesen, auch wenn die Nummern - dank des Löschens einiger Beiträge durch ihre Autoren - nicht immer 100% stimmen) ... mit dieser kann man beim Installieren eines Systems im derzeit inaktiven Partitionset auch gleich noch weitere Dateien in die "wrapper"-Partition schreiben lassen und diese ist dann eben nicht ohne weiteres über NAS-Zugriffe zu erreichen und damit auch relativ sicher vor Manipulationen bzw. wer bis zu diesem Punkt käme, hätte auch noch andere Möglichkeiten.

Da sich "dropbear" auch nicht daran stört, wenn die "authorized_keys"-Datei über einen Symlink irgendwo anders hinzeigt, kann man den Inhalt der Datei auch wieder an vielen verschiedenen Orten speichern ... bis hin zum SquashFS-Image für das "rootfs", wo er dann - per Definition - unveränderlich wäre.

Die Vor- und Nachteile der jeweiligen Speicherung sollte ich bei "E99-custom" auch bereits erläutert haben - bei einer 7490 kann man z.B. auch einfach eine Datei unter "/var/flash" verwenden, denn auch die ist (a) nicht von außen zu lesen oder zu schreiben und (b) bei der 7490 sogar persistent - bei anderen VR9-Modellen aber nicht (das ist die "config"-Partition und deren Handling ist bei AVM einigermaßen undurchsichtig - aber nur, wenn man über unterschiedliche Modelle vergleicht, innerhalb eines Modells war das bisher ziemlich "stabil").

Es gibt nun mal an dieser Stelle so viele unterschiedliche Möglichkeiten (die alle ihre Berechtigung bzw. ihre Vor- und Nachteile haben), daß ich mich nicht für eine einzelne entscheiden WILL ... wer auf einer FRITZ!Box mit einer Shell umgehen möchte, der sollte m.E. auch in der Lage sein, diese - nun wirklich eher simplen - Shell-Befehle für den Start eines SSH-Daemons in ein passendes rc-Skript zu klöppeln - ansonsten sollte er besser auf den Shell-Zugang komplett verzichten.

Ich erwarte ja schon gar nicht mehr, daß die Leute sich die Binaries selbst erstellen (obwohl es Freetz eben schon seit Jahren gibt) ... mit meiner Bereitstellung aktueller Dateien inkl. passender "Unterschrift" wollte ich u.a. auch die älteren Quellen "austrocknen", bei denen es weder aktuelle Versionen noch irgendeine Form der Sicherung der Authentizität einer Datei gab - und das für Binaries, die die Leute am Ende auf ihren Systemen einfach starten (sollen).

Ich bin ja zur Unterstützung bis zu einem gewissen Punkt durchaus auch bereit - aber irgendwann muß der Motor nach dem Anschieben (ja, ich bin so alt, daß das zu meiner Zeit noch funktionierte bei PKWs) auch mal anspringen und von selbst weiterlaufen ... ich habe nicht die Absicht, bis zur nächsten Tankstelle zu schieben, weil jemand die entsprechende Anzeige nicht im Auge haben WILL oder sie einfach ignoriert.

Im Klartext ... ich habe nicht die Absicht, anderen alles bis ins Kleinste "vorzukauen", sondern ich erwarte einfach, daß man sich (bei Interesse) damit auch selbständig befaßt.

Bei mir gibt es z.B. folgende "Zusätze" bei jedem "modfs"-Lauf, die auch alle nur mit den Mitteln arbeiten, die ich im Rahmen von "modfs" auch allen anderen zur Verfügung stelle:

  • ich tausche die BusyBox von AVM immer gegen meine eigene, statisch gelinkte aus (auch die steht in "yf_bin") - der zusätzliche Platzbedarf juckt mich dabei kein Stück, die Gewißheit, die notwendigen Applets dann über "busybox <cmd>" aufrufen zu können, ist mir das allemal wert
  • ich füge weitere öffentliche Schlüssel hinzu, damit ich die installierte Firmware über weitere Images (analog zu DECT-Updates) erweitern kann, wenn das notwendig ist (damit kann ich solche Images halt selbst signieren)
Diese beiden Schritte sind ganz simpel zu erledigen, dazu braucht es lediglich in "files" eine Datei "binaries_<hwrevision>_<kernel_version>.tgz" mit dem folgenden Inhalt:
Code:
root@FB7490:/var/media/ftp/YourFritz/modfs $ tar -tvf files/binaries_113_3.10.107.tgz
drwxr-xr-x root/root         0 2019-06-27 11:44:50 bin/
-rwxr-xr-x 1000/1001   1237428 2019-06-27 11:45:14 bin/busybox
drwxr-xr-x root/root         0 2016-07-03 23:25:35 etc/
lrwxrwxrwx root/root         0 2017-04-22 11:20:57 etc/avm_firmware_public_key9 -> /wrapper/etc/firmware_signing_1.key
lrwxrwxrwx root/root         0 2017-04-22 11:20:56 etc/avm_firmware_public_key8 -> /wrapper/etc/firmware_signing_2.key
drwxr-xr-x root/root         0 2016-04-09 23:01:25 lib/
drwxrwx--- root/root         0 2016-06-04 06:16:16 usr/
drwxrwx--- root/root         0 2016-04-13 04:39:49 usr/bin/
root@FB7490:/var/media/ftp/YourFritz/modfs $
und die Anwendung von "copy_binaries" als "modscript" - alles kein Hexenwerk und anhand der Datumsangaben kann man auch sehen, daß sich darin praktisch nur die BusyBox an und an mal ändert ... der Rest ist "stabil".
  • ich füge Symlinks für ein paar zusätzliche Start-Skripte in "/etc/init.d" ein, diese Symlinks verweisen auf Dateien in der YAFFS2-Partition des laufenden Systems
  • es wird ein zusätzlicher "hook" für "onlinechanged" installiert
  • in jedem Branding wird ein zusätzliches Verzeichnis "custom" im GUI-Baum installiert
Das alles macht ein einzelnes, zusätzliches "modscript", das ich unter "contrib/custom/modscripts/mod_custom" abgelegt habe (ich verwende das anstelle des "mitgelieferten" "mod_custom") und das - ohne den Kram drumherum - die folgenden Befehle als Quintessenz enthält:
Code:
                ln -s /wrapper/etc/init.d/E99-custom $check_filename
                ln -s /wrapper/etc/init.d/S02-config $rootdir/etc/init.d/S02-config
                ln -s /wrapper/etc/init.d/S03-early-syslogd $rootdir/etc/init.d/S03-early-syslogd
                ln -s /wrapper/etc/init.d/S03-path $rootdir/etc/init.d/S03-path
                ln -s /wrapper/etc/init.d/S20-config $rootdir/etc/init.d/S20-config
                ln -s /wrapper/etc/init.d/S50-rdate $rootdir/etc/init.d/S50-rdate
                sed -e "s|^\(find /etc/onlinechanged/\.\) -\(type.*\)\$|\1 /var/custom/etc/onlinechanged/. -\2|" -i $rootdir/bin/onlinechanged
                for TARGET_BRANDING in $TARGET_BRANDINGS; do
                        ln -s /var/custom/usr/www/custom $rootdir/usr/www/$TARGET_BRANDING/custom
                done
                ln -s /var/media/ftp $rootdir/nand
Da wird also fast alles erst einmal nach "/wrapper" (also in die YAFFS2-Partition des laufenden Systems) umgebogen ... wenn es irgendwo anders liegen soll, kann man das von dort ja weiterleiten. Wie man auch sehen kann, wird alles das, was nicht nach "/wrapper" geht, dann wieder unter "/var/custom" "verortet" und das ist nun mal genau der Pfad, mit dem fast alle von mir bereitgestellten Binaries kompiliert wurden - kann man alles im "YourFreetz"-Repo im "YourFritz"-Branch nachlesen.

Wie kommen nun die Dateien nach "/wrapper"? Ganz einfach ... denn dafür gibt es ja den Beitrag #661 und das dort beschriebene "ADD_TO_WRAPPER". In meinem "modfs"-Tree gibt es dafür dann das Verzeichnis "atw_3.10.107" mit folgendem Inhalt:
Code:
root@FB7490:/var/media/ftp/YourFritz/modfs $ find atw_3.10.107/
atw_3.10.107/
atw_3.10.107/etc
atw_3.10.107/etc/firmware_signing_1.key
atw_3.10.107/etc/custom_config.conf
atw_3.10.107/etc/init.d
atw_3.10.107/etc/init.d/S03-path
atw_3.10.107/etc/init.d/S20-config
atw_3.10.107/etc/init.d/E99-custom
atw_3.10.107/etc/init.d/S02-config
atw_3.10.107/etc/init.d/S03-early-syslogd
atw_3.10.107/etc/init.d/S50-rdate
atw_3.10.107/custom.custom
atw_3.10.107/config
atw_3.10.107/config/custom.tar.xz
atw_3.10.107/bin
atw_3.10.107/bin/custom_config
atw_3.10.107/bin/custom_config/link_to_export
atw_3.10.107/bin/custom_config/initialize
atw_3.10.107/bin/custom_config/shutdown
atw_3.10.107/bin/custom_config/writer
atw_3.10.107/bin/custom_config/yourfritz_helpers
atw_3.10.107/bin/custom_config/monitor
atw_3.10.107/bin/custom_config/lazy_countdown
root@FB7490:/var/media/ftp/YourFritz/modfs $
Da weden also in erster Linie die vorher verlinkten Start-Dateien übernommen (deren Inhalt ist erst mal egal), die Signatur-Keys kopiert und - das ist wieder wichtig - eine "custom.custom"-Datei (ein SquashFS-Image mit meinen "Standarderweiterungen" - bis hin zum "Midnight Commander") in das neu installierte System kopiert. Bis auf den "custom_config"-Teil (den ich zwar auch mal hier irgendwo veröffentlicht hatte, der ist aber nicht mehr aktuell, weil sich beim "notifyfs" etwas geändert hat) ist das alles bereits "öffentlich" und wer Interesse daran hat, kann es sich selbst so oder in jeder anderen, von ihm selbst gewünschten Form nachbauen.

Die wirklich wichtigen Sachen werden dann wieder aus dieser "custom.custom" heraus gestartet ... in erster Linie eben ein SSH-Server (meist tatsächlich "dropbear"), der sowohl den Shell-Zugang als auch - per SFTP - den Dateizugriff ermöglicht.

Das alles wurde von mir veröffentlicht und (mind. einmal) auch hier im IPPF jeweils beschrieben ... an dieser Stelle ist dann aber mit dem "Vorkauen" auch Schluß. Ich sehe noch ein, daß es ein paar "Grundbedürfnisse" bei der Modifikation einer Firmware geben könnte (der "gui_bootmanager" gehört meinetwegen dazu und ein paar Mods fürs AVM-GUI), aber ich erkenne nicht einmal den (permanenten) Bedarf nach einem Shell-Zugang ... selbst wenn man den für ein erneutes Update per "modfs" benötigt. Niemand wird schließlich daran gehindert, sich den genau zu dem Zeitpunkt, wo er benötigt wird, auch wieder per "implant_siab..." in die laufende Version einzubauen ... und die Unterschiede bzw. Probleme beim Umgang mit dem Browser, den Telnet-Client oder einem SSH-Client, sind mir am Ende ebenfalls egal. Wer der Ansicht ist, er braucht den Shell-Zugang (und sei es dreist, um "modfs" verwenden zu können), der muß auch mit solchen "Widrigkeiten" fertig werden - ansonsten sollte er (schlauerweise) selbst die Entscheidung zum Verzicht treffen.

Wer schlau ist, wartet nicht erst darauf, daß ihm jemand anderes "schlüsselfertige Lösungen" präsentiert ... wer sich nur ein wenig damit befaßt, sollte solche Vorhaben wie "Ich baue mir mit "modfs" einen SSH-Server in mein System ein." auch problemlos selbst auf die Reihe bringen - und er braucht dazu im Prinzip nichts weiter als seine FRITZ!Box und einen Editor. Schließlich ist genau deshalb das "modfs" von mir ja als "offenes Framework" konzipiert worden, damit da jeder seine eigenen Idee mit umsetzen kann. Ich hatte ja mal den Glauben, daß es tatsächlich "user contributed modifications" geben würde ... offenbar verwenden die meisten aber doch nur das, was ihnen bereits vom "modfs.tgz" mitgeliefert wird.

Letztlich wollte ich eigentlich nur die Einstiegshürde ggü. Freetz etwas senken ... das sollte (zumindest als "modfs") gar keine "Full-Service-Solution" werden (und ist es auch nicht). Das kann vielleicht mal für "YourFritz" etwas werden ... ist aber noch ein weiter Weg und die Mitstreiter (bei der Programmierung von irgendetwas) rennen einem auch nicht gerade die Bude ein. Daß ich mich dann eher selten dazu aufraffen kann, da weiter Hand anzulegen, ist hoffentlich auch nachvollziehbar ... mir persönlich reichen nämlich die Möglichkeiten der Automatisierung beim Modifizieren der Firmware, die inzwischen vorhanden sind, durchaus.

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

tritt das Problem mit den gefärbten Codeblöcken auf, die sind nun im Code enthalten und müssen erst wieder entfernt werden.
Hier verstehe ich nicht so richtig, was Du mir sagen willst ... ich hoffe halt immer noch, daß irgendwann mal wieder die Möglichkeit der farblichen (und typographischen) Hervorhebung in die CODE-Blöcke Einzug hält (bei vBulletin war sie ja vorhanden) und werde gewiß nicht hingehen und die BBCode-Tags entfernen. Abgesehen davon kann ich manche Beiträge gar nicht mehr editieren (habe ich ebenfalls mehrfach bereits betont/festgehalten), weil sie das nachträglich gesetzte Limit der Zeichenanzahl reißen und ich sie nach den simpelsten Änderungen nicht länger speichern kann. Wenn Dich das also stören sollte, mach' einfach bei der Administration entsprechenden "Krach".
 
Habe ein kleines Problem!
Fritzbox 7490 OS 7.12

Habe von 7.11 auf 7.12 geupdatet. Hat auch alles wunderbar geklappt.

Betreibe einen Apache auf der Fritzbox und seit dem Update werden die Seiten von 192.168.178.1:85 nicht mehr richtig geladen.

192.168.178.1:85 , Seiten werden nicht richtig geladen (Browser lädt endlos)
Zugriff vom Internet , funktioniert
Zugriff über stunnel intern , funktioniert
Zugriff über stunnel extern , funktioniert

Ist ein Bug in 7.12 bekannt?

Vielleicht kann mir jemand helfen
 
Zuletzt bearbeitet:
Ja, in der Pause einfach eine zweite Sitzung aufmachen und in der Datei (der Pfad beginnt mit dem blau angezeigten in der "modfs"-Ausgabe und geht mit "etc/init.d/S85-app" weiter) die gezeigte Zeile eintragen ... das kann auf mehreren Wegen erfolgen.

[ Wer weiß, wie "job control" in der Shell funktioniert, unterbricht den "modfs"-Aufruf mit Ctrl-Z und ändert die Datei, bevor er mit "fg" das "modfs" dann fortsetzen läßt - das erspart die zweite Sitzung. Aber dabei auf die Verzeichnisse aufpassen - beim "fg" sollte wieder das Verzeichnis aktuell sein, was beim Unterbrechen auch aktiv war - sonst könnte "modfs" mit (relativen) Pfaden durcheinandergeraten. Wer sich nicht sicher ist, nimmt lieber die zweite Session und wartet mit dem [Enter] vor dem Einpacken innerhalb von "modfs", bis die Änderungen ausgeführt sind. ]

Einer (ein Weg) wäre z.B. "vi" ... aber auch ein
Code:
echo "telnetd -l /sbin/ar7login" >>PFAD/etc/init.d/S85-app
(PFAD durch den blauen Teil ersetzen)
wäre eine Möglichkeit (und erspart dem Ungeübten den Umgang mit dem "vi") ... das schreibt den Text beim "echo" zwischen den Anführungszeichen als Zeile an das Ende der angegebenen Datei (die zwei spitzen Klammern sind wichtig, damit das wirklich ans Ende angefügt wird).

Wenn ich das Telnet-Skript anpasse, kommt da eine Abfrage für die Version des Ziel-OS rein und wenn die jenseits von 06.98 ist (also auch für weitere Labor-Versionen mit dieser Nummer), kommt die Zeile ans Ende oder ich finde eine ähnliche Lösung - ich hätte immer noch gerne einen Telnet-Service, der nicht ständig aktiv sein muß (zumindest nicht bei jedem) und nur bei Bedarf vom Benutzer gestartet werden kann.


Code:
echo "telnetd -l /sbin/ar7login" >>PFAD/etc/init.d/S85-app

Würde auch fast funktionieren, wenn der mount punkt für das loop dev nicht "ro" gemountet ist,
Kleiner Eingriff in die modfs unter dem Punkt

Code:
mount -o ro "$loopdev" "$mp" 2>/dev/null

wird zu

mount -o rw "$loopdev" "$mp" 2>/dev/null

und der Eingriff in der Zwangspause vor dem Packen funktioniert reibungslos.

Alles weitere lief ohne Probleme.
 
Ganz große Ausnahme, weil mein Account noch funktioniert und "modfs" nun mal "mein" Projekt ist, für dessen Support ich noch keine "neue Heimat" gefunden habe.

Kleiner Eingriff in die modfs unter dem Punkt
Ich weiß zwar nicht genau, wovon Du da sprichst und um welche Zeile in "modfs" es genau geht (für das genauere Verlinken eignet sich ja das GitHub-Repo hervorragend), aber wenn das "$loopdev" hier die YAFFS2-Partition sein sollte, ist das ohnehin zum Scheitern verurteilt.

Was dort in "/etc/init.d/S85-app" steht, interessiert kein Schwein (ohne zusätzliche Aktionen jedenfalls nicht) ... diese Skripte werden nämlich aus dem SquashFS-Image gestartet (nach einem "pivot_root") und auch wenn die "Quellen" für dieses Image in einer ganz bestimmten Konstellation (nämlich beim Verwenden eines zusätzlichen Loop-Devices für das "ext3"-Dateisystem, welches dann Anwendung findet, wenn die physisch vorhandenen Dateisysteme alle keine Linux-Attribute unterstützen - also praktisch FAT oder NTFS sind) in einem Loop-Device versammelt sein können, ist dieses dann garantiert nicht per se "read-only" gemountet ... dann würden nämlich gar keine Dateien dort gespeichert, weder in der Pause noch sonstwann.

Ich glaube gerne, daß sich das "echo"-Kommando nach dem Eingriff auch mit einem "PFAD" ausführen ließ, der auf irgendeine YAFFS2-Partition verweist. Aber ich bezweifele, daß auf diesem Weg auch im fertigen Image (bzw. in dem System, das mit diesem Image arbeitet) der gewünschte Telnet-Daemon in der "S85-app" gestartet wird.
 
Zuletzt bearbeitet:
Ich habe gerade mittels modfs eine 7490 von 7.01-telnet-enabled auf 7.19-72263-telnet-enabled aktualisiert.

Für die dauerhafte Aktivierung von Telnet machte ich (modfs bietet dafür kein modscript mehr):
# echo "/usr/sbin/telnetd -l /sbin/ar7login" >>./etc/init.d/S85-apps

Trotz der beiden modscripts mod_exec_on_* waren die betroffenen Stellen mit noexec gemounted. Vor den modscripts war es so:

Code:
# grep -r noexec ./etc 2>/dev/null
./etc/init.d/S15-filesys:if mount -t yaffs2 /var/dev/nand "${mountpoint}" -o sync,noexec ; then
./etc/init.d/S15-filesys:if mount -t yaffs2 /var/dev/nand "${mountpoint}" -o sync,noexec ; then
./etc/hotplug/udev-mount-sd:if mount -t squashfs -o ro,noexec $DEVNODE "$MNTPATH"; then
./etc/hotplug/udev-mount-sd:if mount -t vfat -o $READMODE,noatime,shortname=winnt,uid=$FTPUID,gid=$FTPGID,utf8,$FMASK,$DMASK,noexec $DEVNODE "$MNTPATH"; then
./etc/hotplug/udev-mount-sd:if mount -t antfs -o $READMODE,noatime,utf8,noexec $DEVNODE "$MNTPATH"; then
./etc/hotplug/udev-mount-sd:if mount -t $filesystem_type -o noexec $DEVNODE "$MNTPATH"; then
./etc/boot.d/yaffs_functions:if ! mount -t yaffs2 "${mtd_block_dev}" "${avm_media_mnt}" -o sync,noexec ; then
./etc/boot.d/yaffs_functions:if ! mount -t yaffs2 "${mtd_block_dev}" "${avm_media_mnt}" -o sync,noexec ; then
./etc/boot.d/ubi_functions:if ! mount -t ubifs "${ubi_dev}" "${avm_media_mnt}" -o sync,noexec; then
./etc/boot.d/ubi_functions:mount -t ubifs "${ubi_dev}" "${avm_media_mnt}" -o sync,noexec

Die modscripts erschlagen aber nur Zeile 1, 2, 3 und 6. Also habe ich die übrigen Zeilen auch geändert:
Code:
# sed -i "s/noexec/exec/" ./etc/hotplug/udev-mount-sd
# sed -i "s/noexec/exec/" ./etc/boot.d/yaffs_functions
# sed -i "s/noexec/exec/" ./etc/boot.d/ubi_functions

# grep -r noexec ./etc 2>/dev/null
#

Offenbar wird /var/media/ftp schon durch boot.d gemounted. Am Ende konnte ich jedoch unterhalb dieses Pfades wieder gewohnt alle Binaries ausführen.
 
Die Dateien in "/etc/boot.d" gibt es erst seit dieser Labor-Reihe, soweit ich das verfolgt habe.

Die Änderung durch den (modfs-)Patch wird bei "antfs" und "vfat" absichtlich ausgespart (die Unix-Flags dort sind ohnehin nur emuliert), der Patch heißt auch ebenso absichtlich:

prevent mount with 'noexec' option for ALL USB volumes with native file-systems

bzw. in der Übersetzung dann

Mounten aller USB-Speicher (mit Linux-Dateisystemen) ohne 'noexec'-Option

Das Verkürzen des Tests auf die Anfangsbuchstaben der Dateisystem-Typen (da wird "[^av]" verwendet, also alles, was nicht mit "a" oder "v" beginnt, paßt auf die Suche) ist zwar auch potentiell fehlerträchtig, aber bisher noch kein Auslöser einer Fehlfunktion.

Das erwartete Verhalten bei "fremden" Dateisystemen kann man sicherlich diskutieren und unterschiedlich sehen, aber es handelt sich hier nicht direkt um Fehler in den Patches, sondern um absichtliche Beschränkungen in meinen Vorschlägen.

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

Bei den Dateien in "/etc/boot.d" warte ich erst mal ab, wie sich das entwickelt und ändere daher noch nichts am "modfs". Für mich sieht das derzeit so aus, als wollte AVM den Startvorgang (der sich bei VR9- und GRX-Boxen - und was es sonst noch so an Plattformen gibt inzwischen bei AVM - schon "in Nuancen" unterschieden hat) jetzt vereinheitlichen und die unterschiedliche Behandlung der Dateisysteme (YAFFS2, UBIFS) und unterschiedliche Treiber/Features/Reihenfolgen aus den anderen Startdateien so weit isolieren, daß diese "low level functions" den Inhalt der Dateien in "/etc/init.d" nicht mehr daran hindern, über mehrere Modelle und Plattformen in identischer Form eingesetzt zu werden.

Ob AVM das mit dem "systemd" nun auch auf den Boxen tatsächlich ernst meint, muß man ebenso erst mal abwarten, wie die Entwicklung beim Einsatz von AppArmor (also einer zusätzlichen Sicherheitsschicht im Linux, die für bestimmte Programme die nutzbaren Funktionen dergestalt einschränken kann, damit auch ein erfolgreicher Angreifer über einen solchermaßen gekaperten Prozess nicht einfach "alles" machen kann), was inzwischen auch in der Firmware aufgetaucht ist.

In der Labor-Version startet der Init-Prozess jedenfalls nicht länger die "/etc/init.d/rc.S", sondern die "/etc/boot.d/1" und die Dienstdefinitionen liegen als "systemd"-Services vor, wobei die steuernde Instanz ein neues Binary "/bin/supervisor" ist und man im Moment raten muß, wieviele Eigenschaften bzw. wieviel Code das vom "systemd" wohl geerbt hat - die Dateien (und Pfade) in diesem Konglomerat sehen jedenfalls stark nach "systemd" aus, auch wenn der als Binary nicht vorhanden ist (im Gegensatz zu den "großen Systemen" die ich so kenne, wo der eigentlich immer als "/usr/lib/systemd/systemd" existiert).

Aber die nächste Version scheint ja in vieler Hinsicht wieder eine Zäsur zu sein und da so manch anderer Patch, der an den Startdateien ändert, wohl auch bei der Startvariante mit dem "systemd" ins Leere läuft, hält sich mein Ehrgeiz da noch eine Weile in deutlichen Grenzen.

Die klare Ansage meinerseits wäre es also im Moment, daß die neue Labor-Reihe vielleicht im Hinblick auf die nunmehr fehlenden Shell-Services "aufgebohrt" werden kann mit "modfs", aber daß praktisch alle Patches, die sich an den Startdateien zu schaffen machen, als "untested" anzusehen sind.

Wer sich einen eigenen Shell-Zugang einrichten will, erzeugt am einfachsten die notwendige Datei für diesen Dienst im Verzeichnis "/lib/systemd/system" als "irgendwas.service". Der Inhalt kann sich dabei auf die Zeilen:

Code:
[Service]
ExecStart=<kommando zum starten des dienstes>

beschränken, wobei die notwendige Software für den Shell-Zugang (von der BusyBox mit dem "telnetd"-Applet über "Shell-in-a-Box" bis hin zu einer simplen "rcmd"-Emulation mit dem "sh"-Applet und dem "initd") natürlich gesondert zu installieren wäre (das ist bei "modfs" bisher ja auch so, dafür kann man den "copy_binaries"-Patch verwenden).
 
Hallo,
ich habe erfolgreich ein Update meiner 7490 mit modfs auf 7.12 durchgeführt. Leider fehlt bei 7.12 eine library libc.so.0, welche ein Drittprogramm "CSmtp" unbedingt benötigt.

CSmtp: can't load library 'libc.so.0'

Kann die library libc.so.0 irgendwie nachinstalliert werden?

Der source-code für SCmtp kann hier geladen werden:

source CStmp

Kann ich den mit Freetz-NG neu kompilieren? Falls ja wie?

Gruß
XC
 
Bei mir half oft ein einfacher Link z.B.:
ln -s /lib/libc.so.1 /var/media/ftp/libc.so.0

oder du baust es bei modfs gleich in /lib mit ein:
ln -s /lib/libc.so.1 /lib/libc.so.0
 
Hi,
link erstellen geht aber CSmtp schaut wohl direkt ins \lib\ verzeichnis.
Gruß
XC
 
Ja, natürlich. Man muß es dann mit einem Parameter aufrufen:
Code:
LD_LIBRARY_PATH=/var/media/ftp CSmtp  .......

Oder wie ich schon schrieb, den Link direkt beim bauen in /lib reinsetzen.
 
Zuletzt bearbeitet:
Probiere erst mal mit dem Parameter aufzurufen, denn nach der 1. fehlenden lib folgen meist noch weitere.
Die mußt du erstmal alle aufschreiben.
 
Vielleicht fehlt ja auch nur der entsprechende Link im /lib/-Verzeichnis. Ich habe noch die 7.11 installiert. Ich habe mal das Listing von /lib/lib... abgespeichert.

Gruss
Thomas
 

Anhänge

  • list-dir-lib.txt
    70.7 KB · Aufrufe: 12

Statistik des Forums

Themen
244,696
Beiträge
2,216,701
Mitglieder
371,316
Neuestes Mitglied
realbluethunder
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.