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

maulich · 13 Feb 2016

Das "eventadd...usw" ist halt die erste Zeile, die in dieser Datei enthalten ist...

Zur Benutzung:

Das Script "edit_rcuser" ruft den Editor "vi" auf...Wenn Du da mal in den weiten des Internets suchst, findest Du recht zügig Seiten zur Bedienung desselben...Ich fand folgende Seite immer ganz hilfreich:

https://de.wikibooks.org/wiki/Vi-Befehlsreferenz:_Bearbeitung

Auf die Schnelle:

vi startet im Befehlsmodus...

Mit der Taste "o" kannst Du in den Eingabemodus wechseln und Daten einfügen. ("o" beginnt die Eingabe in einer neuen Zeile, unterhalb des Cursors)

Jetzt kannste in der neuen Zeile deine(n) Befehl(e) eintragen.

Wenn Du fertig mit editieren bist, drückst Du "Escape" um den Eingabemodus zu verlassen und zum Befehlsmodus zurückzukehren.

Mit ":" gelangst Du nun in den sog. Ex-Modus, und dort wird dann mit "w" die Datei gespeichert, und mit "q" der Editor verlassen...(Hintereinander ":", "w", "q", "Enter" eingeben.)

Wenn Du, aus irgendeinem Grund den Editor ohne speichern der Datei verlassen möchtest gibst Du im Ex-Modus "q!" gefolgt von Enter ein...

Viel Erfolg!

PeterPawn · 14 Feb 2016

So, die angekündigte "neue" Version ist jetzt verfügbar (https://github.com/PeterPawn/modfs/releases/tag/v0.3.2), als Download für die FRITZ!Box direkt unter http://yourfritz.de/modfs-0.3.2.tgz zu erreichen ... #1 wird entsprechend angepaßt.

Änderungen ggü. der 0.3.1:

"corner case" beseitigt, wo beim Fehlen von "automatisch" abzuarbeitenden "modscripts" vor dem Schritt mit den "optionalen" Änderungen trotzdem versucht wurde, die bereits abgearbeiteten Skripte aus der Liste zu löschen, was dann natürlich schief ging

-

alle "modscripts" sind jetzt nur noch "optional", weil die bisher automatisch ausgeführten Änderungen zur Reaktivierung des Telnet-Daemons und zur Abarbeitung der debug.cfg/rc.user unter geeigneten Umständen gar nicht mehr notwendig sind (Telnet ist auch nur noch "Notnagel", wenn nichts anderes mehr geht - andere Dienste (SIAB, SSH) wären für ständige Nutzung viel sicherer) und ich für die Zukunft eigentlich davon wegkommen will ... wenn das jemandem nicht paßt, kann er/sie ja durch entsprechende Änderungen an den "x"-Flags seine eigene Entscheidung treffen, welche Änderungen automatisch und welche nur auf Nachfrage angewendet werden sollen

-

die Änderung zum Umschalten zwischen den Systemen per GUI (guibootmanager) ist jetzt in zwei Versionen enthalten (einmal als gui_boot_manager_v0.1 mit der bisherigen Version und einmal als ..._v0.2 mit der neuen), wobei nur die neuere als "optional" angeboten wird
diese neue Version funktioniert (vermutlich) nur mit dem neuen "responsive design" der AVM-Firmware, für eine ältere FRITZ!OS-Version sollte man dann lieber mit "chmod ug-x modscripts/gui_boot_manager*" die neue (bzw. beide) Version(en) deaktivieren und mit "chmod ug+x modscripts/gui_boot_manager_v0.1" die alte wieder "optional" aktivieren
das erweiterte Shell-Skript dahinter kümmert sich jetzt bei Bedarf auch darum, daß das Branding bei einem Wechsel der zu verwendenden System-Version so angepaßt wird/angepaßt werden kann, daß es auch einen Wert hat, der in dem anderen System überhaupt enthalten ist ... wer also zwischen einer deutschen Version (meist ja mit "avm" und "1und" im Dateisystem) und einer internationalen Version (nur Branding "avme") umschalten will, kann jetzt gleich bei der Umschaltung das Branding passend setzen lassen
Anhang anzeigen 85629

-

es ist jetzt auch möglich, "modfs" nur dazu zu verwenden, ein passendes SquashFS-Image für eine andere FRITZ!Box zu erstellen und die dafür verwendete FRITZ!Box gar nicht zu ändern
könnte man z.B. nutzen, um auf einer 7490 die passende Datei für eine 7412 zu erstellen
für das Kopieren einer so erzeugten Image-Datei in die (inaktive) Partition einer NAND-Box gibt es ein Skript unter https://github.com/PeterPawn/YourFritz/blob/master/update_yaffs2/install_inactive_rootfs (http://yourfritz.de/7490/install_inactive_rootfs als Link ohne HTTPS für den Download direkt aus dem FRITZ!OS heraus) - es ist eine leichte Abwandlung von "update_yaffs2" und kopiert die angegebene Datei (als Standard wird "filesystem_core.squashfs" angenommen) einfach nur in die zuvor ermittelte yaffs2-Partition ... sollte eigentlich auf jeder NAND-Box funktionieren; zur Umschaltung auf das bisher inaktive System kann man dann im Anschluß ja z.B. switch_system verwenden
für das Erzeugen einer solchen Image-Datei auf einer anderen Box wird der "update"-Modus (mit Angabe des Quell-Images) verwendet ... folgt auch den Image-Namen noch ein weiterer Parameter, wird das erzeugte Image unter diesem Namen gespeichert und ansonsten die verwendete FRITZ!Box gar nicht weiter geändert - auch wenn sie ggf. für einige "modscripts"-Files noch als "Quelle" für bestimmte Angaben (z.B. Brandings) herangezogen wird, weil diese Skript-Dateien natürlich davon ausgehen, daß die Box gemeint ist, auf der das Skript abgearbeitet wird
Code:
```
./modfs update [I]source_image[/I] [I]target_file_name[/I]
```
Auch solche Späße wie automatischer Download der passenden Quelldatei sind natürlich auf Informationen aus der Box angewiesen, auf der "modfs" läuft ... daher reicht die Ergänzung dieser neuen Möglichkeit nur für diesen "update with file"-Modus m.E. vollkommen aus - man muß halt die notwendigen Vorbereitungen von Hand erledigen.

splenditnet · 14 Feb 2016

modfs-0.3.2 Skripterror in Line 2493: "sh: 1: unknown operand"

hallo PeterPawn,
vorab vielen Dank für Deine Arbeit im Zusammenhang mit modfs und "modfs-Starter"

bin bei modfs-0.3.2 auf folgenden Error gestoßen:

Code:

# ./modfs update FRITZ.Box_7490_Labor.113.06.51-32297.image
[COLOR=#ff0000]sh: 1: unknown operand[/COLOR]
Ermitteln der Hardware-Version ... OK
Prüfen, ob die Hardware-Version unterstützt wird ... OK
Suchen der Einstellung zur Umschaltung auf das alternative System ... OK
Prüfen der aktuell zu startenden Systemversion ... OK
Suchen der aktuellen Kernel-Partition ... OK
Suchen der alternativen Kernel-Partition ... OK
Vergleich der Systeme in den Kernel-Partitionen ... übersprungen
Suchen der aktuellen Dateisystem-Partition ... OK
Suchen der alternativen Dateisystem-Partition ... OK
Überprüfen des zur Verfügung stehenden Speicherplatzes im RAM ... OK
Überprüfen des freien Speicherplatzes für das Auspacken des Dateisystems ... OK

Das System erfüllt die Voraussetzungen zur Modifikation des root-Dateisystems.

Im Moment läuft auf der Box die Version: 113.06.51

Die Angabe einer Datei nach dem 'update'-Parameter unterbindet jede Versionprüfung.
Somit ist jeder selbst dafür zuständig, die Kompatibilität der vorhandenen Einstellungen
mit dem verwendeten System sicherzustellen, speziell wenn ein Downgrade ausgeführt wurde
oder ggf. die 'Werkseinstellungen' wiederherzustellen.

Die angegebene Datei '/var/media/ftp/USB-Stick-01/download/modfs-0.3.2/FRITZ.Box_7490_Labor.113.06.51-32297.image' wird als Quelle für die Aktualisierung genutzt.
Extrahieren des neuen Kernel-Images aus dem Firmware-Image ... OK
Extrahieren des Flash-Filesystems aus dem Firmware-Image ... OK
Extrahieren des Wurzeldateisystems aus dem Flash-Filesystem ... OK
Entpacken des root-Dateisystems für die Modifikationen ... OK

Das entpackte Dateisystem ist jetzt bereit für die Modifikationen.

Verzeichnis des root-Dateisystems : /var/media/ftp/USB-Stick-01/1455437139/squashfs-root


Die Modifikation 'own files' wird verarbeitet ...
Überprüfen der unterstützten Sprachen ... fallback to english
Soll die Modifikation 'own files' mit folgender Beschreibung
add/replace some binaries at the target system
angewendet werden ? (j/N) N

ich denke hier liegt ein Tippfehler in modfs Line 2493 vor

Code:

2491: debug "modfs: noversioncheck=$noversioncheck, update_file_provided=$update_file_provided"                                               
2492: [ $update_file_provided -eq 1 ] && debug "modfs: firmware_update_file=$firmware_update_file"                                             
2493: [ $create_image_[COLOR=#ff0000]ony[/COLOR] -eq 1 ] && debug "modfs: create_image_only=1, target_image_name=$target_image_name"

Nach Ändern von Line 2493 war Error weg.

Code:

[ $create_image_only -eq 1 ] && debug "modfs: create_image_only=1, target_image_name=$target_image_name"

ergänzend habe ich folgende Frage:
Gibt es einen Grund das mitgelieferte modscript mod_mount_by_label nicht zu benutzen ?

Code:

# ls -la modscripts/
-r-xr-xr--    1 root     root           834 Dec 18 08:01 copy_binaries
-r--r--r--    1 root     root          1764 Dec  9 00:00 dectcmds.modscript
-r-xr-xr--    1 root     root          3818 Sep 22  2014 edit_rcuser
-r--r--r--    1 root     root         11726 Feb  5 19:19 gui_boot_manager_v0.1
-r-xr-xr--    1 root     root         19665 Feb 13 15:30 gui_boot_manager_v0.2
-r-xr-xr--    1 root     root          1202 Dec 14 16:34 mod_enable_telnet
-r--r--r--    1 root     root          1594 Sep 22  2014 mod_mount_by_label
-r-xr-xr--    1 root     root          1349 Sep 22  2014 mod_profile
-r-xr-xr--    1 root     root          2251 Sep 22  2014 mod_rc_tail_sh
-rw-r--r--    1 root     root          5550 Dec 14 16:34 yourfritz_hooks
#

Hintergrund: mod_mount_by_label ist wg. fehlendem x-Bit für modfs Skript "unsichtbar".

Gruß
Splenditnet

PS: hab gerade gesehen, dass u.a. auch ein neues Skript copy_binaries hinzugekommen ist

Code:

# ./modfs update FRITZ.Box_7490_Labor.113.06.51-32297.image
SNIP
Die Modifikation 'own files' wird verarbeitet ...
Überprüfen der unterstützten Sprachen ... fallback to english
Soll die Modifikation 'own files' mit folgender Beschreibung
add/replace some binaries at the target system
angewendet werden ? (j/N) N

bei dem Binaries auf dem Zielsystem ersetzt werden können.
srcfile=files/binaries_7490_$version.tgz

EDIT: modfs-Zeilennummer von 2496 auf 2493 angepasst, da ich für Fehleranalyse 3 Zusatzzeilen eingebaut hatte und so die Nummerierung um +3 "verrutscht" war.

PeterPawn · 14 Feb 2016

@splenditnet:
Danke für den Hinweis, offenbar gibt mein Keyboard langsam den Geist auf - einige Keys liefern bei kurzem Kontakt in jüngster Zeit nicht immer ein Zeichen ... korrigiere ich gleich noch. Das war die letzte Änderung, das auch noch in die Debug-Ausgabe zu schreiben und die habe ich nicht einmal mehr getestet in diesem Modus - da das kein echter Syntax-Fehler ist, fällt das auch erst bei der Abarbeitung an dieser Stelle auf.

Das Skript "mod_mount_by_label" ist unter 06.50 nicht mehr erforderlich, denn dort gibt es bereits bei AVM die Möglichkeit, in der usb.cfg (Abschnitt usbhost) mit der Angabe von "volume_labels=yes;" einen etwas ausgefeilteren Mechanismus (mit mehr Prüfungen auf ungültige Zeichen usw., was mit meinem "Einzeiler" etwas schwierig ist) zu aktivieren. Das einzige, was so ein Patch bei der 06.50 machen könnte/sollte, wäre die Deaktivierung der Abfrage des Wertes aus der usb.cfg (einfach die Zeile 115 in der /etc/hotplug/udev-mount-sd auf "immer 'yes'" ändern), weil der leider immer wieder beim Übergang zu einer Version < 06.36 entfernt wird und der Standardwert nach dem Willen von AVM "no" ist - das kommt dann zum Tragen, wenn man den Wert nicht explizit setzt. Es gibt auch kein "ctlmgr"-Interface dafür - daher ist das auch nirgendwo in der Firmware bisher im GUI einzustellen, weil es einfach keinen "programmatischen Weg" gibt, den Wert in die usb.cfg zu schreiben.

Das mit dem "copy_binaries" war auch nicht beabsichtigt (das hat ja nicht einmal eine deutsche Beschreibung) ... das verwende(te) ich eigentlich nur bei mir für genau diesen Zweck des Kopierens von Binärdateien noch direkt in das neue Image, wenn der Weg über /var/custom für irgendwelche Zwecke nicht reicht (z.B. beim Ersetzen der Busybox oder anderer Kommandos im AVM-Image). Wenn es jetzt schon mal dabei ist ... c'est la vie, wie der Berliner sagt. Auch "yourfritz_hooks" lasse ich drin ... sind ja alle "deaktiviert" und so kann man das ggf. als Beispiel verwenden, wie man solche Änderungen umsetzen kann, wenn das "patch"-Kommando (was natürlich das einfachste wäre) auf der Box fehlt.

Wenn sich mal jemand aufraffen und ein Skript schreiben sollte, das Patch-Files z.B. mit der Hilfe des "sed" auf die Ausgangsdateien anwendet ("unified patch format" mit allen Schikanen, wenn möglich - auch "fuzzing" für den Aufsetzpunkt), dann findet er in mir einen dankbaren Abnehmer. Wobei ich irgendwann wohl doch dazu übergehen werden, einfach noch eine voll ausgestattete Busybox in Binärform mit in das "modfs"-Archiv zu packen - dann stellt sich so ein Problem auch nicht mehr.

splenditnet · 14 Feb 2016

PeterPawn schrieb:
Wenn sich mal jemand aufraffen und ein Skript schreiben sollte, das Patch-Files z.B. mit der Hilfe des "sed" auf die Ausgangsdateien anwendet ("unified patch format" mit allen Schikanen, wenn möglich - auch "fuzzing" für den Aufsetzpunkt), dann findet er in mir einen dankbaren Abnehmer.

hallo PeterPawn,
ich denke der Patch-Befehl läßt sich bei Fritzboxen leichter mit LUA als mit SED realisieren;

patch.lua - Patch utility to apply unified diffs
http://lua-users.org/wiki/LuaPatch

Gruß
Splenditnet

PeterPawn · 14 Feb 2016

splenditnet schrieb:
ich denke der Patch-Befehl läßt sich bei Fritzboxen leichter mit LUA als mit SED realisieren;

Funktioniert dieses Paket denn auch mit dem "einzigen Einstieg" in die "liblua.so", der meines Wissens unter einer AVM-Installation existiert?

Ich kenne außer der "/bin/luavar" kein anderes Binary und bin mir nicht so richtig sicher, daß darüber der komplette Sprachumfang zugänglich ist ... mir ist es ja auch noch nie gelungen, auf die Kommandozeilen-Argumente beim "luavar" zuzugreifen.

Ansonsten ist die Lua-Verarbeitung ja eher "embedded" im "ctlmgr" von AVM ... deshalb gibt es ja auch keine Möglichkeit, da den Prozessor für Lua-Dateien irgendwie durch einen eigenen Wrapper zu ersetzen beim Webserver.

Sollte das tatsächlich funktionieren, wäre es natürlich eine denkbare Lösung ... wenn man erst eine "richtige" Lua-Installation auf die Box bringen muß, kann man auch wieder gleich ein "binäres patch-Kommando" nehmen, das geht dann auch noch schneller als jede Skriptsprachen-/Interpreter-Lösung.

Am Ende halten mich eben Vorbehalte bzw. auch Schwierigkeiten (z.B. eben mit den Kommandozeilen-Argumenten) bisher generell eher davon ab, wirklich auf Lua als Skriptsprache für die Automatisierung auf der Box zu setzen ... ist ja auch nicht so richtig eine Domäne der "Basissprache" - ohne entsprechend nachgerüstete Lua-Pakete für alles mögliche ist das auch wieder nur eine "Rumpfsprache", der es eindeutig an "Bibliotheken" für viele Einsatzzwecke mangelt (auf der Box, im Netz gibt es dann wieder genug Material) und deren Möglichkeiten der Interaktion mit dem Dateisystem auch nicht besonders ausgeprägt sind.

handymaxe · 14 Feb 2016

@maulich
hellzyeah! das hat alles perfekt geklappt, rcuser enthält jetzt den LCR-Installationsaufruf (geprüft durch nochmaliges Aufrufen von edit_rcuser)

Jetzt werde ich die Box mal neustarten und hoffentlich taucht dann auch der LCR wieder auf.

Jedenfalls auch Dir ein megadickes Danke, ich bin echt begeistert von Eurer aller Hilfe.

palast · 14 Feb 2016

Hat mit dem neuen Script soweit geklappt.
Telnet war wie gewünscht aktiviert und ließ sich über einen Telefonbucheintrag ausschalten.
Allerdings einschalten lässt es sich nicht mehr.

PeterPawn · 14 Feb 2016

palast schrieb:
Allerdings einschalten lässt es sich nicht mehr.

Das habe ich inzwischen auch schon mehrfach gelesen ... vielleicht hat AVM da ja tatsächlich eine Sonderbehandlung eingeführt, die nunmehr nach der kompletten Abschaffung des telnetd zwar nicht mehr allzu relevant ist (wobei die Developer-Versionen ja wohl den Symlink nach wie vor enthalten), aber die vorher auf diesem Weg mögliche "heimliche" Aktivierung des Telnet-Zugangs aus dem LAN über HTTP-Zugriffe war ja auch ein Sicherheitsproblem an sich.

koyaanisqatsi · 14 Feb 2016

Moinsen

Das ist jetzt auch ein bischen allgemein ausgedrückt: "läßt es sich nicht mehr"

dialer.sh

Code:

#!/bin/sh
if [ ${#} -eq 2 ] ; then
/usr/bin/ctlmgr_ctl w telcfg settings/DialPort ${1}
/usr/bin/ctlmgr_ctl w telcfg command/Dial ${2}
echo -ne $(basename $0) $?': Dialing '${2}'\n'
else
/usr/bin/ctlmgr_ctl w telcfg command/Hangup 1
echo -ne $(basename $0) $?': Hangup!\n'
fi
#EOF

Bei mir gehts "über telefon" noch so...
sh dialer.sh 1 '#96*8*'
...für telnetd aus, und...
sh dialer.sh 1 '#96*7*'
...wieder an.

Allerdings nur in einer entsprechend vorher eingerichteten dropbear (SSH), oder auch in einer SIAB, Konsole.

PeterPawn · 14 Feb 2016

Wenn ich das jetzt auf die Schnelle richtig getestet habe, ist das sogar noch ganz anders ... der nachträgliche Start des per einmal #96*8* abgeschalteten Telnet-Daemons funktioniert gar nicht (bei mir), weder über die Wählhilfe noch über ein (DECT-)Telefon ... solange der bereits beim Start der Box (genauer des "telefon"-Daemons) aktiviert war.

Aber die Einstellung für den Start des Telnet-Daemons wird mit jedem #96*7* und #96*8* umgeschaltet, wie man leicht überprüfen kann:

Code:

# testvalue /var/flash/fx_conf 1 14466
1

Dabei steht "1" für einen aktivierten Telnet-Daemon und "255" für den deaktivierten.

Die Umschaltung des Wertes in der fx_conf findet bei mir immer statt, aber der Telnet-Daemon wird nur dann bei jedem "Anruf" richtig gestartet und beendet (ist eigentlich die Nachricht "telnetd ein" nur bei mir nicht mehr vorhanden?), wenn er nicht bereits beim Start des "telefon"-Daemons aktiviert wurde (also zu diesem Zeitpunkt Telnet schon eingeschaltet war).

Ansonsten wird zwar ein aktiver Telnet-Daemon noch beendet bei #96*8*, aber bei einem anschließenden #96*7* kein neuer Daemon gestartet. Das findet erst dann wieder statt, wenn man den "telefon"-Daemon neu startet ... einfach "killall telefon" und "telefon a127.0.0.1" nacheinander aufrufen. Natürlich hilft auch ein Reboot, weil dabei auch irgendwann mal der "telefon"-Daemon beendet und neu gestartet wird - das ist kaum verwunderlich.

Einen Unterschied in der Reaktion auf die Tastencodes per Telefon (MT-F) oder per Wählhilfe habe ich aber nicht feststellen können ... die große Frage ist es nun für mich, woran der erneute Start des Telnet-Daemons nach dem Beenden im "telefon"-Daemon am Ende scheitert und ob man das als Fehler an AVM melden sollte.

Peter78 · 14 Feb 2016

Download eines aktuellen Firmware-Images vom FTP-Server des Herstellers immer einen fehler.
Woran könnte das liegen?

Code:

[B]Das System erfüllt die Voraussetzungen zur Modifikation des root-Dateisystems.[/B]                                                                                                                
                                                                                                                                                                                              
Im Moment läuft auf der Box die Version: [B]113.06.50[/B]                                                                                                                                            

                                                                                                                                                                                              
Als Ausgangspunkt dieser Modifikationen wird ein SquashFS-Image benötigt.                                                                                                                     
Dafür stehen drei Möglichkeiten zur Auswahl:                                                                                                                                                  
                                                                                                                                                                                              
a - das root-Dateisystem des laufenden Systems benutzen                                                                                                                                       
b - ein neues root-Dateisystem aus einem Firmware-Download vom FTP-Server des Herstellers verwenden                                                                                           
c - ein an anderer Stelle im Dateisystem abgelegtes Image verwenden                                                                                                                           
q - keine Änderungen vornehmen                                                                                                                                                                
                                                                                                                                                                                              
Bitte den Buchstaben des gewünschten Punktes eingeben :[B] b[/B]                                                                                                                                     
                                                                                                                                                                                              
Download eines aktuellen Firmware-Images vom FTP-Server des Herstellers ...[B] Fehler[/B]

                                                                                                                                                                                              
Beim Versuch des Downloads einer frischen Kopie der aktuellen Firmware vom                                                                                                                    
FTP-Server des Herstellers ist ein Fehler aufgetreten.

PeterPawn · 14 Feb 2016

Die für diesen Modus (es ist offensichtlich kein Aufruf mit "update") erforderliche Firmware-Version 06.50 gibt es schlicht auf dem FTP-Server des Herstellers nicht mehr.

Peter78 · 14 Feb 2016

PeterPawn schrieb:
es ist offensichtlich kein Aufruf mit "update"

Danke, das war der entscheidende Hinweis

coco722 · 14 Feb 2016

Neue Version des modfs funktioniert.
Es gab lediglich eine Fehlermeldung beim Skript-Teil own_binaries ...
Verzeichnis des root-Dateisystems : /var/tmp/1455479615/squashfs-root

Die Modifikation 'own files' wird verarbeitet ...
Überprüfen der unterstützten Sprachen ... fallback to english
Soll die Modifikation 'own files' mit folgender Beschreibung
add/replace some binaries at the target system
angewendet werden ? (j/N) j
Überprüfen der Voraussetzungen für die Modifikation ... nicht unterstützt
Modifikation wird ausgeführt ... Fehler (3)
Unable to find binaries file for kernel version 3.10.73.

Die Modifikation 'own files' wurde angewendet, Fehlercode = 3.

Die Modifikation 'create edit_rcuser command' wird verarbeitet ...
Überprüfen der unterstützten Sprachen ... OK

Das GUI 0.2 ermöglicht die Auswahl für Neustart des aktuellen oder inaktiven Systems (wie die letze Version), die Option zur Auswahl des Brandings (bzw. eines Wechsels) fehlt leider, woran könnte das liegen ?
[h=4]Das oben ausgewählte System unterstützt nur das Branding "avme", dieses ist im Moment auch eingestellt.[/h]

coco722 · 14 Feb 2016

PeterPawn schrieb:
Ansonsten wird zwar ein aktiver Telnet-Daemon noch beendet bei #96*8*, aber bei einem anschließenden #96*7* kein neuer Daemon gestartet. Das findet erst dann wieder statt, wenn man den "telefon"-Daemon neu startet ... einfach "killall telefon" und "telefon a127.0.0.1" nacheinander aufrufen. Natürlich hilft auch ein Reboot, weil dabei auch irgendwann mal der "telefon"-Daemon beendet und neu gestartet wird - das ist kaum verwunderlich.

Einen Unterschied in der Reaktion auf die Tastencodes per Telefon (MT-F) oder per Wählhilfe habe ich aber nicht feststellen können ... die große Frage ist es nun für mich, woran der erneute Start des Telnet-Daemons nach dem Beenden im "telefon"-Daemon am Ende scheitert und ob man das als Fehler an AVM melden sollte.

Nach Installation des modfs 0.3.2. und manuellem reboot, war telnetd nicht automatisch an, liess sich über Wählhilfe #96*7* problemlos aktivieren, dann mit #96*8* problemlos wieder abschalten, dann wieder aktivieren und wieder abschalten ... das Ein- und Abschalten des telnetd funktioniert bei mir einwandfrei (4 x hintereinander ausprobiert).

PeterPawn · 14 Feb 2016

coco722 schrieb:
woran könnte das liegen ?

Screenshot bitte ... ich bin mir nicht sicher, ob Du da wirklich die neue Version verwendest. Die sollte immer (auch wenn es keine Auswahlmöglichkeit für den Benutzer gibt, weil das neue System nur ein einzelnes Branding unterstützt und das dann quasi zwangsweise geändert werden muß) wenigstens noch eine Information zum aktuellen bzw. benötigten Branding in der Anzeige bei der "reboot.lua" mit ausspucken und da sich auch der andere Text geändert hat, sind die beiden Versionen eigentlich ziemlich leicht auseinanderzuhalten. Insofern irritiert mich Deine Feststellung etwas ...

Der Fehler bei "copy_binaries" ist ja logisch ... solange Du Dir keine eigene Datei "binaries_7490_3.10.73.tgz" im "files"-Unterverzeichnis erstellt hast, kann da auch nichts ausgepackt werden. Deshalb heißt es ja auch "own files" ... das Skript ist eher versehentlich in das Archiv gerutscht (sieht man schon daran, daß da fix "7490" im Dateinamen erwartet wird - die Varianz im Dateinamen mit der Kernel-Version ist auch nur dem Übergang auf den neuen Kernel seitens AVM geschuldet, weil das ggf. unterschiedliche Ersetzungen je nach Kernel sein müssen) und dient eigentlich nur dazu, bestimmte Dateien immer automatisch (oder zumindest halbautomatisch) zu ersetzen, ohne in der "Wartephase" vor dem Packen des neuen Dateisystems das immer wieder von Hand machen zu müssen. Wer also eigene Dateien hat, die immer wieder in so ein neues Image kopiert werden müssen, der kann sich einfach ein passendes tar-File erstellen und das dann bei der Modifikation einfach auspacken lassen - mehr macht dieses Mini-"modscript" ja gar nicht.

coco722 · 14 Feb 2016

Screenshot.
Ein fritz.box/reboot.lua funktioniert nicht, da kommt ein: { "pid": "logout" }
Neustart-Link ist: http://192.168.178.1/?sid=b4f99eaeeff45532&lp=reboot

PeterPawn · 14 Feb 2016

Ja, reicht ... da steht doch aber auch drin, daß das ausgewählte System (das aktive) nur "avme" als Branding unterstützt und das auch eingestellt ist.

Wenn das inaktive System per Radiobutton ausgewählt wird (dazu braucht man nicht "neu starten" drücken), dann ändert sich der Text unten ebenfalls ... selbst dann, wenn das ebenfalls eine internationale Version mit nur einem Branding sein sollte, ist das für das inaktive System eine andere Formulierung.

coco722 · 14 Feb 2016

PeterPawn schrieb:
Wenn das inaktive System per Radiobutton ausgewählt wird (dazu braucht man nicht "neu starten" drücken), dann ändert sich der Text unten ebenfalls ... .

Das hatte ich probiert, Radiobutton-Auswahl des inaktiven Systems ändert auch nichts and dem Text unten; Dropdown-Menue mit Auswahlmöglichkeit ist leider nicht vorhanden.

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

Neuer User

IPPF-Urgestein

Neuer User

IPPF-Urgestein

Neuer User

IPPF-Urgestein

Neuer User

Neuer User

IPPF-Urgestein

IPPF-Urgestein

IPPF-Urgestein

Neuer User

IPPF-Urgestein

Neuer User

Neuer User

Neuer User

IPPF-Urgestein

Neuer User

IPPF-Urgestein

Neuer User

Statistik des Forums