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

Das Impfen mit SIAB ist bei mir erstmal Plan B, weil mein Linux-Rechner leider seit kurzem nicht mehr läuft und ich da erstmal Abhilfe schaffen muss
wie wäre es zB mit dem freetz.ova in einer VM ? Das hat doch alles nötige OnBoard.

Oder ein Raspbian auf einen SBC ?
 
Ich weiß gerade nicht aus dem Kopf, ob die 06.83 schon die 2FA hat und ob da die Wählhilfe noch für das Wählen dieser "Kommando-Codes" verwendet werden konnte

Ergänzung:
Das Problem, dass die Wählhilfe nicht mehr zum Starten des Telnet-Daemons bei NAND-Boxen von FW >= 06.50 verwendet werden kann, ist schon seit 2016 hier im Forum bekannt; siehe separater Thread:
Nur die ist die Wählhilfe zum Einschalten des Daemons ohne Telefon nicht mehr zu gebrauchen.

Vorschlag: Analog-Telefon oder ggf. DECT-Telefon anhängen und die "#96*7*" wählen, restarten und prüfen, ob Telnet-Service verfügbar ist.
Die getestete 6.50 startete erst den Daemon, nachdem ich ein DECT Telefon mit der Box verbunden habe und #96*7* per Telefon gesendet habe.
 
Zuletzt bearbeitet:
Ich wäre da immer noch vorsichtig ... bei mir funktioniert das nämlich bei der 113.06.93 (also einer aktuellen 7490-Release) noch ganz hervorragend:

waehlhilfe_telnetd.PNG

Die Wählhilfe ist auf "ISDN- und Schnurlos-Telefone" eingestellt, die Kommandos "'#96*7*" und "#96*8*" sind als Nummern in einem Telefonbucheintrag hinterlegt und werden per Klick im GUI gewählt (da der Daemon dann natürlich auch abgebrochen wird bei "telnetd aus", ist das oben nur ein Screenshot aus SIAB) - die 2FA ist hier deaktiviert, sollte aber auch nur beim Konfigurieren der Wählhilfe ein Hindernis sein.

Es mag also vielleicht bei anderen FRITZ!OS-Modellen tatsächlich so sein (ich kann unmöglich alle Geräte selbst testen), aber für die, wo ich das selbst prüfen kann, kann ich es ausschließen, daß die Wählhilfe nicht mehr funktioniert für diese Zwecke.

Ohne jemandem zu nahe treten zu wollen, ist das mit der nichtfunktionierenden Wählhilfe für mich mit einiger Wahrscheinlichkeit eher ein Bedienfehler (die unterlaufen mir auch desöfteren ... aber ich teste dann solche "Erkenntnisse" eben auch noch erst einmal gegen, ehe ich die Schuld tatsächlich einer Änderung zuschiebe - ein "modellspezifisches Verhalten" an dieser Stelle würde mich zumindest auch sehr überraschen) oder das Nichtbeachten der Hinweise zum wiederholten Starten und Stoppen des Daemons zwischen zwei Reboots.

Dieses etwas merkwürdige Verhalten (anderenorts hier schon beschrieben, zusammengefaßt in etwa: Der Dienst kann pro "uptime" nur einmal gestartet und gestoppt werden - das Flag wird aber trotzdem bei jeder Änderung gesetzt und beim nächsten Reboot auch richtig ausgewertet.) hat AVM m.W. erst eingebaut, als man die "Erfolgsmeldung" beim Einschalten ("telnetd ein") unterdrückt hat ... die "Abschaltmeldung" kommt nach wie vor und wird auf Telefonen mit passendem Display auch angezeigt.
 
Zudem Thema gibt es über die Jahre so viele Informationen, dass ich nun fragen muss
kann man den bei den aktuelle OS wie 7.0 oder 6.98 den Telnetzugang über den Telefonbucheintrag
#96*7 wieder aktivieren kann. Hatte gelesen das man dazu auf 06.50 zurück muss, aber für dieses alte OS kann man bei AVM kein recover nicht mehr finden. Oder es soll eine Möglichkeit geben ShellInABox zu implementieren, aber it welchen Script und wie der Weg ist wurde nicht so richtig beschrieben. Ich wollte das erst mal auf einer 7560 realisieren, diese hat das OS 7.0 ...
 
Du solltest für die hier nicht unterstützte 7560 Dich eher hier einlesen.
LG
 
So, die 7.01 ist raus, aber modfs, was mit der 6.93 er Firmware noch perfekt klappte, funktioniert nicht mehr. Es ist die aktuelleste modfs-Version. Ausgeführt habe ich es auf einem USB Stick, wo Platz genug war, wo modfs und die Firmware abgelegt war. Auch mit prepare_fwupgrade vorher komme ich nicht weiter: Beim Packen des Rootfilesystems stürtzt die Fritzbox ab. Ich habe parallel mal die Box angepingt, kurz vor dem Absturz mit Reload danach geht die Pingzeit von 0,5 ms auf 30 ms für mehrere Pings hoch, bevor die Box gar nicht mehr erreichbar ist und sich reloadet. Anscheinend ist die Last beim Packen zu hoch.

Das 7er Image ist ja doch deutlich größer:
-rwxrwxrwx 1 boxusr14 root 27453440 FRITZ.Box_7490.113.06.93.image
-rwxrwxrwx 1 boxusr11 root 33310720 FRITZ.Box_7490.113.07.01.image
 
Zuletzt bearbeitet:
Ich versuche mal, es mir anzuschauen ... wird aber eher Richtung Wochenende gehen.

Die Frage, warum das Image so viel größer ist, stellte sich ja im Firmware-Thread schon ... mal sehen, wo AVM da zugelegt hat.

Ansonsten bräuchte man für die 07.00 (zumindest dann, wenn das "modfs" auch auf dieser Version laufen soll) am ehesten mit der neuen C-Library gelinkte Pakete ... ich habe noch nicht mal meinen Freetz-Fork auf die aktuelle Freetz-Version gebracht, geschweige denn damit irgendwelche Binaries erzeugt (weder für "modfs" noch für YourFritz) für die Verwendung in einer FRITZ!OS 7-Version.

Erst mal schreibe ich AVM jetzt wieder wegen der Quellen für die nun fertige 07.01 an ... keine Ahnung, wie groß die Änderungen ggü. der zwischenzeitlich bereitgestellten Source-Version für einen der Laborstände am Ende wirklich sind.

Und noch einmal explizit an @tacitus-nrw: Hattest Du denn auch Swap-Space zur Verfügung gestellt? Eigentlich reicht es ja schon, wenn auf einem USB-Stick eine passende Partition existiert, dann wird die automatisch eingebunden.

Will man das mit einer Datei machen (ich weiß gerade nicht, ob das auf einem FAT32-Volume auch geht), muß man es von Hand vorbereiten:
Code:
# dd if=/dev/zero of=/var/media/ftp/YourFritz/swapfile bs=$(( 1024 * 1024 )) count=$(( 2 * 1024 ))
2048+0 records in
2048+0 records out
Das dauert eine Weile (es legt eine Datei mit einer Größe von 2 GB mit lauter Nullen auf dem USB-Stick an und "YourFritz" muß für den eigenen USB-Stick passend ersetzt werden - entweder das Label oder der vom FRITZ!OS generierte Pfad aus Hersteller und Modell) und ist in erster Linie von der Schreibrate des USB-Sticks abhängig. Es sollten aber auch 512 MB schon locker reichen, dafür gibt man eben "count=512" an.

Wenn die Datei dann existiert, muß man sie initialisieren und als Swap-Space einbinden:
Code:
# mkswap /var/media/ftp/YourFritz/swapfile
Setting up swapspace version 1, size = 2147479552 bytes
# swapon /var/media/ftp/YourFritz/swapfile
# cat /proc/swaps
Filename                                Type            Size    Used    Priority
/var/media/ftp/YourFritz/swapfile       file            2097148 0       -2
Dann sollte es eigentlich gar nicht mehr zu Speicherproblemen beim Packen kommen ... nur muß man eben eine Swap-Datei immer von Hand einbinden (sowohl "dd" als auch "mkswap" muß man nur einmal machen, das "swapon" nach jedem Neustart, wenn man den Swap-Space nutzen will), während eine passende Partition gleich automatisch vom FRITZ!OS richtig eingebunden wird:
Code:
# blkid
/dev/sda1: TYPE="swap" PARTUUID="013898e3-01"
/dev/sda2: LABEL="YourFritz" UUID="ed85d36c-ae21-431f-be3a-41df0884d49a" TYPE="ext3" PARTUUID="013898e3-02"
/dev/sda5: LABEL="storage" UUID="33132262-834d-41a5-b4eb-59b4266e8789" TYPE="ext3" PARTUUID="013898e3-05"
# cat /proc/swaps
Filename                                Type            Size    Used    Priority
/dev/sda1                               partition       1953772 0       -1
Die Kommandos oben sollten alle auch mit der AVM-BusyBox schon machbar sein.
 
Also bei mir hat es mit der 7.01 - wie die vorherigen Male/Versionen auch - mit dem Bereitstellen des Images auf dem NAS und Neustart der Box vor dem Versuch beim ersten oder zweiten Mal geklappt.

Leider funktioniert Telnet (oder die Aktvierung von Telnet über die Wahlhilfe) - genauso wie auf der Laborversion - nicht. Ansonsten läuft die modifizierte Version auf meiner Box.
 
# wird das USB-Subsystem gestoppt, während wichtige Teile des Hauptspeichers
# in eine Swap-Partition (oder -Datei) ausgelagert sind, bleibt es u.U. beim
# Neustart hängen - das wird hier versucht zu korrigieren
Diesen Punkt besser abwählen, so meine einfältige Erkenntnis. Weshalb der Stepp mit "telnet" durchläuft und im Nachgang nicht funzt? Ich vermute als DAU etwas in Richtung busybox.config
LG
Ansonsten läuft die modifizierte Version auf meiner Box.
Mit welcher Version von modfs und als "Master" an einem DE-xDSL-Anschluss? Ich kann hier nicht ganz ausschliessen, dass der Urlader/Bootloader einer "jungen" FB7490 mit 1und1-Branding über das Restart-Script (Neustarten mit Auswahl=<Branding>) den entscheidenden Unterschied macht.
 
Zuletzt bearbeitet:
Der Patch für das Deaktivieren des Swap-Space beim Entladen von Volumes und/oder des gesamten USB-Stacks sollte man eher gerade dann auch einbinden lassen, wenn man die Absicht hat, auf dem erzeugten Image irgendwann auch mal wieder "modfs" ausführen zu lassen ... ansonsten kann es nämlich tatsächlich geschehen, daß der USB-Stack vom FRITZ!OS abgeräumt wird beim Versuch des Neustarts und dann waren gerade wichtige Teile ausgelagert, die aber auch erst beim weiteren Herunterfahren wieder benötigt werden.

Das war früher beim "dsl_monitor"-Prozess im FRITZ!OS gerne mal der Fall (der wird im "Normalbetrieb" praktisch nicht gebraucht und ist trotzdem aktiv gewesen) ... da wartete dann das DSL beim Stoppen darauf, daß der lange nicht mehr funktionierende USB-Stick die ausgelagerten Daten wieder herausrückt, damit der Daemon beendet werden kann.

Mit dem Patch werden die auf dem USB-Volume (oder der -Partition) liegenden Swap-Spaces im Rahmen des "Entladens" eines USB-Sticks mittels "swapoff" wieder deaktiviert, was zum Einlagern der dorthin ausgelagerten Speicherseiten führt.

Da zu diesem Zeitpunkt i.d.R. dann der speicherhungrige Prozess des Packens aber schon beendet ist (wenn man "modfs" benutzt hat), steht auch wieder genug freier Platz im Hauptspeicher zur Verfügung ... nur werden ausgelagerte Seiten eben erst dann wieder eingelesen, wenn sie tatsächlich gebraucht werden oder der Swap-Space deaktiviert werden soll.
 
Nein, den Swap Speicher habe ich nicht zusätzlich angelegt. Mit der 6.92 klappte es ja auch noch so, würde das dann das nächste Mal mit zusätzlichem Swap versuchen. Den Patch für das Deaktivieren des Swap Speichers beim Entladen der USB Sticks habe ich abgewählt, weil das nun beim Modfs bei der 7 er Version zu einem Fehler mit Abbruch führte.
Aber wie ich das nun so lese, wie viel nun in der 7er Version verändert wurde, warte ich mal lieber, als dann ggf. nur noch eine halb oder gar nicht mehr funktionierende Box zu haben. An der 7er Version war für mich halt die Möglichkeit, die Telekom Smarthome Komponenten auch nutzen zu können, interessant. Ich bleibe dann noch auf 6.92
 
Hat jemand auf der 7490 mit OS 7.01 telnet aktiviert bekommen? Im Telefon-Display erscheint nach dem wählen von #96*7* "zurückgewiesen". Auch mit Freetz funktioniert Telnet nicht mehr. Auf einer 7560 OS 7.0 mit Freetz klappt es noch.
 
Hat jemand auf der 7490 mit OS 7.01 telnet aktiviert bekommen? Im Telefon-Display erscheint nach dem wählen von #96*7* "zurückgewiesen".
das wird mit "#96*7" nicht mehr gehen;
da muß man seit 7.01 die Datei "/etc/init.d/S85-app" anpassen

siehe auch:
Versucht mal, den Daemon nicht länger über "telefon" starten zu lassen ... dazu muß man noch irgendwo (z.B. in der "/etc/init.d/S85-app", wenn es die noch geben sollte) die Zeile:
Code:
telnetd -l /sbin/ar7login
hinzufügen.

Ich würde am ehesten tippen (das war in einigen Labor-Versionen auch schon so), daß AVM den Telefon-Daemon nicht länger den "telnetd" starten läßt.
 
  • Like
Reaktionen: eDonkey
Danke, das hat geholfen!
 
Wie trägt man
telnetd -l /sbin/ar7login
am besten ein? Ich gehe davon aus, das kann man nur während dem modfs machen?
 
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.
 
Bei mir steht es in der rc.user.
Wenn man die dann aber mal löscht, schießt man sich selber ab, wenn dann nicht noch SIAB oder dropbear läuft.

Geht nicht auch: Auf die alte FW umschalten, Telnet aktivieren, auf die neue FW umschalten?
 
Ich vermute(! - zum systematischen Testen bin ich noch nicht gekommen), daß AVM sogar das Flag nach wie vor noch umschaltet in der "fx_conf", wenn man das Telefon mit den Codes verwendet - nur wird es von "telefon" wohl nicht mehr ausgewertet bzw. der Start des "telnetd" erfolgt nicht.

Je nachdem, wo wirklich das "Problem" liegt, kann/muß man sich andere Wege suchen.

Ich bin ohnehin verblüfft ... zwar "predige" ich auch ständig, daß man anstelle von Telnet irgendetwas Sicheres verwenden sollte, aber falls AVM tatsächlich hier reagiert und den Start des "telnetd" entfernt, während bei der Anmeldung ohne Kennwort immer noch die Checkbox als "Alternative" für die ganz Faulen bleibt, ist das für mich ein etwas merkwürdiges Konglomerat aus Maßnahmen zur weiteren Steigerung der Sicherheit.

Wenn AVM hingegen nur die #96*7* und #96*8* bei der Code-Auswertung entfernt hat und damit das Flag nicht mehr gesetzt oder gelöscht werden kann, dann müßte ja bei den Leuten, wo zuvor das Telnet-Flag aktiv war, der Daemon auch nach dem Update weiterhin starten. Das ist aber genau nicht der Fall, wenn ich die Meldungen hier im IPPF richtig interpretiere.

Daher tippe ich eben auf die zuerst von mir beschriebene Variante - komischerweise hat ja auch AVM immer noch den "telnetd" (auch immer noch mit dem Patch zur Prüfung des Symlinks offensichtlich) in der BusyBox. Wobei ich noch erwähnen sollte, daß meine "Erkenntnisse" hinsichtlich FRITZ!OS 7 sich in weiten Teilen auf die 7580 stützen, weil ich meiner 7490 wegen Alterschwäche des NAND-Flashs nicht mehr jeden jugendlichen Leichtsinn zumuten will (s. Anhang, die braucht jetzt schon 1' 45" beim Start, um über die Lesefehler im SquashFS zu kommen).

Aber für "modfs" und dessen Tests muß sie noch einmal ran (und dafür wird sie von mir auch "aufgespart") ... auch das war ein Grund, warum ich die ganzen Labor-Reihen der 7490 nicht mehr mitmachen wollte mit diesem Gerät. Die ist halt beim Entwickeln und Testen ein paar mal zuviel "traktiert" worden ... man vergißt allzu leicht, daß Flash-Speicher nur eine begrenzte Anzahl von Schreibzyklen verträgt.

Daher werde ich die Nutzung des eingebauten Flash-Speichers als mögliches Arbeitsverzeichnis auch gleich noch entfernen im "modfs" bzw. nur noch auf ausdrückliche Anweisung beim Aufruf zulassen.
 

Anhänge

  • 7490_masq.txt
    212.1 KB · Aufrufe: 17
Genau das ist der Grund, warum ich modfs schon lange nur noch auf der 7580 und komplett im RAM ausführe.
Selbst die Quell- und Ziel-Datei liegen alle im RAM.
 
Es hängt halt auch immer davon ab, wie häufig man "modfs" einsetzt ... wer sich damit tatsächlich nur von Release- zu Release-Version bewegt und zwischendrin vielleicht mal drei oder vier Labor-Versionen ausprobiert, kommt immer noch locker über 10 Jahre und mehr (soviele neue Versionen gibt es bei AVM ja auch nicht wirklich).

MLC-Zellen sollen durchschnittlich 3.000 Schreibvorgänge vertragen und TLC-Zellen immer noch 1.000 ... die muß man auch erst mal (mit dem Schreiben (bzw. bei der Verwendung von "modfs" auch mit dem "Vorbereiten") einer neuen Firmware) erreichen. Das ist bei "normaler Nutzung" (auch mit "modfs") praktisch ausgeschlossen, weil es selbst bei 10 Jahren Nutzungsdauer (mit TLC-Flash) immer noch 100 Schreibvorgänge pro Jahr oder mehr als 8 pro Monat oder 2 pro Woche wären. Welche Technologie die in der 7490 verbauten Chips nutzen, müßte ich auch erst recherchieren, daher der "worst case" als Grundlage.

Nur wer tatsächlich ständig aufs Neue in diesen Speicher schreibt (Lesen juckt nicht wirklich), bei dem gehen die "bad blocks" dann halt auch mal hoch - es gibt auch einen gesonderten "procfs"-Eintrag, wo man sich den Gesundheitszustand seines eigenen NAND-Flashs genauer ansehen kann (Namen habe ich gerade nicht parat - ist aber nicht zu übersehen). Vielleicht liegt der aber auch im "sysfs" oder im "debugfs" ... ich weiß es schlicht nicht mehr, habe das aber hier irgendwann auch mal geschrieben, als diese "Auskunft" von AVM das erste Mal in den Kernel eingebaut wurde.
 

Statistik des Forums

Themen
246,004
Beiträge
2,244,319
Mitglieder
373,392
Neuestes Mitglied
lukaskr07
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.