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

[XJIOP]

Hi PeterPawn, thanks a lot for you help!
your modification work perfect with my 3490, now i have stable telnet :ziggi:

 

[PeterPawn]

@XJIOP:
Thanks for the feedback here.

Als Zusammenfassung des Geschehens für andere 3490-Besitzer:

Es gab bei dieser 3490 keine passende Firmware auf einem AVM-Server (3490, 06.20 int.) und so blieb für die permanente Aktivierung nur der Weg über das Modifizieren der bereits in der Box vorhandenen Firmware. Nachdem der Telnet-Start über ein Pseudo-Image funktioniert hatte, wurde das (meines Wissens vor dem Pseudo-Update geladene) modfs ausgeführt. Da die Box vorher noch "jungfräulich" war, existierte der "linux_fs_start"-Eintrag im Urlader-Environment noch nicht und mußte erst mit

echo linux_fs_start 0 >/proc/sys/urlader/environment

eingerichtet werden, damit die "dual boot"-Fähigkeit der Box "angezeigt" wurde. Dann kam selbstverständlich auch noch hinzu, daß das zweite Partition-Set noch gar keine Daten enthielt, deshalb mußte im ersten Anlauf mit modfs das aktive System in die inaktiven Partitionen kopiert und nach dem anschließenden Restart noch einmal von vorne begonnen werden.

Parallel zur Aufnahme der Hardware-Revision der 3490 hatte ich noch eine Änderung bei der Reaktivierung der debug.cfg/rc.user eingefügt, die den Telnet-Damon direkt startet, ohne auf den telefon-Daemon von AVM zu setzen (bei der 06.20i ist der Link für den telnetd ja noch vorhanden).

Die Erkenntnisse aus den Support-Daten und dem Test durch XJIOP werden in Kürze in das Skript einfließen, dabei will ich dann versuchen, auch Boxen ohne "native" Telefonie besser zu unterstützen beim Start des Telnet-Dienstes.

 

[XJIOP]

can't understand where add to startup my packages, /var/tmp/rc.user is only temporary file...

 

[PeterPawn]

Use the additional command "edit_rcuser", it will do all the special handling of TFFS character devices for you and offer an "vi" editor for the correct content. If you did not build the image including this tool, have a look at the related "modscript" to learn the commands executed there and enter these commands manually.

 

[XJIOP]

i have all included from this tools but edit_rcuser not found.
with editing files no problem, i installed ssh+sftp+busybox v1.21.1 and only need add this in startup update-rc.d or etc.

 

[PeterPawn]

i have all included from this tools but edit_rcuser not found.

I can't realize, why it's not available. If the modscript is run, a shell script will be created under /usr/sbin/edit_rcuser. Please check your path and look for this file, if it has only the wrong permissions (why?), you could call the shell with its path as parameter as a workaround.

If it's really missing, read some further writings here related to the nature of "TFFS nodes" as character devices to store FRITZ!Box settings and how to edit such a "file" the right way. The minor id of the device you have to edit is 98, the major id can be found at the /proc/devices pseudo file, look for the "tffs" device's major id.

 

[XJIOP]

sorry i found edit_rcuser in /usr/sbin I thought it will be launched globally)
i prepared autorun.sh script it is located on an external drive, how do correctly add it via edit_rcuser?

#!/bin/sh

PART='Samsung-M3Portable-02'
HDD="/var/media/ftp/$PART/src"
PASSWD='***'

while ! [ -d $HDD ] ; do sleep 5; done

echo "start ssh ..."

$HDD/busybox sed -e "/root:/s#^root:[^:]*:#root:$PASSWD:#" -i /var/tmp/shadow
$HDD/ssh/dropbear -p 22 -r $HDD/ssh/dropbear_rsa_host_key -d $HDD/ssh/dropbear_dss_host_key -0 -S $HDD/ssh/sftp-server

echo "OK"

$HDD/busybox sleep 3

cd $HDD/transmission
./transmission.sh start

$HDD/busybox sleep 3

cd $HDD/minidlna
./minidlna.sh start

exit 0

 

[PeterPawn]

There are other threads here describing the needed precautions ... it's not as easy as a single line to call your script, because it can/should be called only after mounting the device is completed and the time, when mounting is finished, may vary.

Therefore you have to implement a "wait logic" to ensure mounting is done, before you call the script. In most cases the debug.cfg file (I call it rc.user, but it's only a name, the data is stored in TFFS minor ID 98 and the name isn't relevant) is the wrong place to execute such "autorun.sh" scripts.

Modifying the /etc/hotplug/udev-mount-sd script with modfs again (so the changes are stored in the root file system) is the better way ... but you have to change it manually prior to packing the target file system with modfs and to understand the script logic at first, to be able to change it.

The mentioned udevd script is the right place, because the mount command is issued there and if such a command succeeds, it's time to look for an autostart script on the new volume. A good side effect is the possibility to execute the autostart script any time, if a volume is mounted and your USB storage may be even connected, after the system was started.

Starting a Linux system with udevd support makes the whole process of device initialization "event driven" and mounting a storage volume is part of udevd's system start ... the right way to execute an autostart script from a - non-deterministic mounted - volume is to wait for the appropriate event and execute the autostart script from "the event handler" (in your case the udev-mount-sd script).

 

[georgmelz]

Hallo PeterPawn,
tolles Script, erspart mir erst einmal die Mühe, mich mit Freetz zu beschäftigen (kommt sicher noch später). Eigentlich wollte ich auf meiner neuen Box (7490) ja nur den LCR ans Laufen bringen...
Eine Kleinigkeit habe ich beim Durchsehen gefunden:

2044 # FRITZ!Box language environment setting                                                            
2045 #                                                                                                   
2046 lang=$Language                                                                                      
2047 if [ ! -r $(localedir)/$lang ]; then                                                                
2048         lang=en                                                                                     
2049         echo "The localized messages file for '$lang' was not found, probing fallback to 'en'." 1>&2
2050 fi

Das echo in Zeile 2049 liefert nie eine aussagefähige Meldung, da $lang ja zu diesem Zeitpunkt schon 'en' enthält. Wenn mann die Zeilen 2048 und 2049 vertauscht, sieht es schon anders aus. Tut zwar technisch nicht weh, verwirrt aber vielleicht jemanden.

 

[PeterPawn]

Eine Kleinigkeit habe ich beim Durchsehen gefunden:

Danke für den Hinweis, wird bei der "nächsten Runde" (die bringt die Unterstützung der 06.35 bei der 7490) mit korrigiert.

Sollte Dir noch anderes auffallen, immer her damit ... da das dynamisch wächst und ich keinesfalls nach jeder Änderung wieder mit allen Tests beginnen kann (dazu fehlt einfach die Zeit), kann es solche Stellen schon noch mehrfach geben.

Hast Du das nur im "Trockentest" gefunden oder hast Du tatsächlich noch eine weitere Sprache verwendet und dabei "en" in der Fehlermeldung selbst erhalten?

Wenn andere Sprache ... das wird ja aus der "Language"-Einstellung der Firmware abgeleitet und die internationale Version habe ich selbst noch gar nicht damit behandelt, auch wenn es in der Theorie natürlich genauso funktionieren müßte ... welche war das dann und würdest Du ggf. ein angepaßtes Sprach-File bereitstellen können? :mrgreen:

 

[the.gangster]

@georgmelz
...und Willkommen im Forum!

 

[georgmelz]

Ist mir im Trockentest aufgefallen, wobei ich nicht systematisch gesucht habe. Die Stelle stach mir irgendwie ins Auge Mit einer neuen Sprache kann ich also leider nicht aufwarten. Aber ich bleibe dran, versprochen!

 

[PeterPawn]

Ist mir im Trockentest aufgefallen, wobei ich nicht systematisch gesucht habe.

Begeistert mich fast noch mehr ... bisher ist das Feedback von Leuten, die den Code dann auch mal kritisch beäugt und hinterfragt haben, eher Mangelware.

Deshalb habe ich sogar schon in Erwägung gezogen, das von Shell-Code auf eine andere Basis zu stellen, da gerade solche Sachen wie Modularisierung und Wiederverwendbarkeit dann sicherlich einfacher sind und solange niemand wirklich prüfen will, was da passiert, ist das dann auch noch performanter. Nur meine eigene Abneigung gegen fremde Binaries hält mich davon ab ... obwohl hier ja schon zwei solche Kröten enthalten sind.

 

[koyaanisqatsi]

Abend

Papperlapapp

Du, PeterPawn bist nur deiner Zeit etwas vorraus.

(Acrylglaskugel elektrostatisch auflad)
In 1 bis 2 Jahren werden sich die Leute um dein Skriptwerk schlagen reissen.
Und dann kannste dich vor Feedback nicht mehr retten.

Apropos perfomanter...
Manipulier den Kernel doch noch mit rdev und lass ihn eine initrd laden.
...viel perfomanter gehts meines Erachtens nicht mehr.
Und so eine initrd ist auch schwupsdiwups wieder entsorgt.

 

[RAMler]

Kurze Zwischenfrage, hoffe das ist ok.

Habe ich es richtig verstanden, dass ein Recover bei der 7490 einfach den aktiven Kernel und FS neu schreibt, so wie die Config zurücksetzt. Der inaktive Kernel und das FS bleibt also unangetastet?

Anders gefragt:
Was macht die Recover.exe bei einer 7490 genau?

PS:
Danke an PeterPawn für die vielen sehr interessanten Freds und Postings hier im Forum! Lese die letzten Tage vieles nach und das hätte ich mal lieber etwas früher machen sollen. So hätte ich noch so manches sichern können was nun im Update Nirvana gelandet ist.

 

[PeterPawn]

Was macht die Recover.exe bei einer 7490 genau?

Herbst 2014 - Unterforum Modifikationen

Ich habe das mal untersucht und auch die diversen Irrtümer an dieser Stelle dokumentiert (durch Streichungen) - den Thread findest Du selbst.

Ansonsten wird genau ein Kernel und ein Filesystem in die Box (in den Hauptspeicher) geladen und dort gestartet. Wie das Flashen dann läuft, kannst Du in einer laufenden 7490 unter /wrapper/sbin/flash_update nachlesen.

 

[koyaanisqatsi]

Moins

Was eine Recovery anders macht?
Das zeigt sie in ihrer Dialogbox sogar an.
Sie löscht ein oder zwei MTDs komplett.
Und wenn die Recovery ein Update des Bootloaders hat,
dann kann sie auch einen Bootloader updaten.

Aber eine Recovery hält sich an die Werte des EVA/ADAM2 Environments.
Steht da als Branding 1und1 dann bleibt die Box auch eine 1und1 Box.
Ist ein provider additive vorhanden, wird auch nicht recovert.

 

[RAMler]

War am überlegen das provider flag zu entfernen und die recover drüber zu ziehen, mit dem Hintergedanken den dual-boot als failsafe zu nutzen, falls mir das recovern die Provisionierung komplett zerlegt.
Wenn "nur" kernel+FS vollständig überschrieben werden, das inaktive System aber unangetastet bleibt, sollte das ja eigentlich klappen. Sofern ich keinen Denkfehler habe oder etwas wichtiges übersehe?!

Dann hätte ich auch die Option das inaktive System zu booten, wo die Provisionierung ja noch gehen sollte und von dort dann wieder auf das "recover system" kernel + fs zurück zu flashen, also das recover ungeschehen zu machen.

Falls ich was übersehen sollte, wäre es nett, wenn ihr mich drauf stoßen würdet.


@PeterPawn:

War das ein Thread von dir oder nur Postings von dir in anderem Thread? Bin aktuell wohl blind.


---
Bin wirklich blind, finde weder Post noch Fred zur recovery einer 7490. :-[

 

[PeterPawn]

http://www.ip-phone-forum.de/showthread.php?t=272403&p=2032598&viewfull=1#post2032598

 

[RAMler]

Vielen Dank, erneut und mal wieder.