fwmod 7390 6.51

[PeterPawn]

Da hätte ich aber auch gar keine "Schmerzen" mit ... das "modfs" könnte man ja theoretisch auch (wenn man einige Tests/Einstellungen vom laufenden System auf vorgegebene Werte umstellt) auf einem x86-Host als Lösung verwenden - da es das "fwmod" ja lange genug schon gab, habe ich aber in dieser Richtung keine Weiterentwicklung für notwendig erachtet.

"modfs" ist ganz klar nur für die Leute gedacht (und eigentlich auch immer noch ein "Lösungsvorschlag"), die sich keine ausgewachsene Linux-Umgebung für die Verwaltung der Freetz-Toolchain für's Cross-Compile zulegen wollen oder können. Ansonsten empfehle ich ausdrücklich jedem, der mit Freetz "klarkommt", sich seine Binärkomponenten selbst zu erstellen und im Zuge dessen dann auch "fwmod" zu verwenden, um das eigene Image zu erstellen.

Jetzt fehlt in meinen Augen auch nur noch irgendeine Lösung (ich weiß aber auch nicht, wie die konkret aussehen sollte), um die "modscripts" ggf. auch noch in "fwmod" irgendwie (halbautomatisch) so einzubinden, daß der "all_no_freetz"-Abschnitt (oder ein zusätzlicher) die Skript-Dateien mit den passenden Parametern (die müßten in der Freetz-Umgebung alle bekannt sein) aufruft und dabei ggf. so etwas in der Art der Datei "custom_modscripts" berücksichtigt, wenn es darum geht, welche Änderungen konkret übernommen werden sollen.

Wobei diese Skript-Dateien eben - anders als die Freetz-Patches - in erster Linie auf die neueren Versionen ausgerichtet sind, gar keine Rücksicht auf ältere Versionen nehmen und eigentlich auch keinen wirklichen Mechanismus zur "Selektion" einzelner Dateien bieten, der nur im Ansatz mit dem Kconfig-Ansatz von Freetz kompatibel wäre.

---

-Die letzte Hürde auf dem Weg zur Installation des ersten eigenen Images auch aus Freetz heraus, nehmen wir irgendwann auch noch - seitdem AVM keine unsignierte Firmware mehr installieren mag, ist das ja für viele "Neulinge" immer noch eine Einstiegshürde bei den Modellen, die auf NAND-Speicher basieren und kein direktes Beschreiben von Kernel- und Dateisystempartition über den Bootloader zulassen.

Das ist aber auch kein größeres Problem - ich bin auch erst letztens in Freetz zufällig darüber gestolpert, daß es mit "recover-eva" ja schon sehr lange eine (Perl-basierte) Lösung gäbe, die man - ähnlich wie "push_firmware" auch nur etwas anpassen müßte, damit man damit das AVM-Recovery-Programm auch problemlos nachbilden und auf diesem Weg dann die erste eigene Freetz-Version installieren kann. Ob man das dann auf Basis der POSIX-Shell (mit ein paar zusätzlichen Netzwerk-Tools), der MS-PowerShell oder eben mittels Perl machen will, liegt wieder "im Auge des Betrachters" und wenn es in der Freetz-Toolchain schon definitiv eine Perl-Umgebung gibt, dann kann man die (aus Freetz heraus) ja auch verwenden.

 

[Mr.I]

https://freetz.org/wiki/help/howtos/common/install -> Manuelles Installieren eines Images

https://freetz.org/wiki/FAQ -> Wie installiere ich das Freetz-Image?

die Funktionalität an sich gibt es eigentlich schon seit Juni 2016, aber dokumentiert habe ich es erst gestern. Selbst nicht getestet, da keine 7390 im Besitz. Feedback ist willkommen.

Hallo allerseits,
nachdem ich bisher "stiller Mitleser" war und erfolgreich eine FW 6.51 inkl. Telnet-Zugang erstellt habe, möchte ich meine 7390 jetzt auch gerne auf die FW-Version 6.80 bringen. Ich hänge vermutlich an der gleichen Stelle wie bspw. ManfredR fest, denn ich bekomme bei Hochladen der veränderten Firmware die Meldung, dass meine FW nicht signiert ist.

Wenn ich es richtig verstehe, ergeben sich 2 Varianten:

1. Die von PeterPawn genannte Möglichkeit, mit push_firmware aus dem tools-Verzeichnis des freetz-trunk. Kann das bitte nochmal jemand erklären? Reicht es eine unsignierte FW-Datei zu haben, die man mit push_firmware hochlädt?

2. er13 verweist auf eine Doku, mit der man eine signierte Firmware erstellt. Das habe ich (glaube ich) soweit verstanden. Wenn ich jetzt eine FW-Datei mit meinem "eigenen" Schlüssel erstellt habe, wie bekomme ich diese Datei denn auf die Box? Da ich ja mit der FW 6.51 einen Telnet-Zugang habe, könnte ich den Schlüssel wie beschrieben "drüber mounten", zumindest scheint mir das die praktikabelste Methode (ansonsten müsste ich zurück auf 6.30, da dies noch eine unsignierte Firmware ist, richtig?). Wie mounte ich denn meinen Schlüssel temporär auf die Box, so dass meine Firmware als originale Firmware erkannt wird?

Fragen über Fragen...

Danke im voraus für eure Unterstützung.

Gruß,
Mr.I

 

[Shirocco88]

Wie mounte ich denn meinen Schlüssel temporär auf die Box, so dass meine Firmware als originale Firmware erkannt wird?

IMHO: die Date Freetz-VM:${HOME}/.freetz.image_signing nach fritz.box:/var/flash/etc_avm_firmware_public_key9 kopieren und per "/bin/mount --bind /var/flash/etc_avm_firmware_public_key9 /etc/avm_firmware_public_key32 mounten.

- - - Aktualisiert - - -

Korrektur: "/bin/mount --bind /var/flash/etc_avm_firmware_public_key9 /etc/avm_firmware_public_key3"

 

[er13]

1. Reicht es eine unsignierte FW-Datei zu haben, die man mit push_firmware hochlädt?

Mittels push_firmware lässt sich auch ein unsigniertes Firmware-Image hochladen.

2. Da ich ja mit der FW 6.51 einen Telnet-Zugang habe, könnte ich den Schlüssel wie beschrieben "drüber mounten"... Wie mounte ich denn meinen Schlüssel temporär auf die Box, so dass meine Firmware als originale Firmware erkannt wird?

• Dein Public-Key in dem von AVM erwarteten Format ist auf Deinem Build-System unter ~/.freetz.image_signing.asc zu finden. Der Inhalt der Datei sieht in etwa so aus (hier als Beispiel eines der AVM-Schlüssel):
  

  00cbdcfcc6ac9a1657a1c6f197e3056f1d68b8bb7deb480249e5f0ded677c54fde10be5a14b1e6a395483bd4bee608c09d385b1e90564ca84b9272926c45bfd328d7da876567e3e15f719800a53ecc21af583431d0c40806ca89f6f958e188ec69572df09e24de71eaa0782c01877158f286afd95037e7eb059367c466095944e1
  010001

• Man kopiere diese Datei auf die Box, z.B. unter /var/tmp/my_public_key. Alternativ erzeuge man diese Datei mittels vi /var/tmp/my_public_key (der Inhalt der Datei ist ein Text bestehend aus zwei Zeilen).
• Man mounte nun diese Datei über eines der AVM-Schlüssel (z.B. über den "dritten", i.e. mit 3 am Ende): mount -o bind /var/tmp/my_public_key /etc/avm_firmware_public_key3
• Nun soll sich das eigene mit dem soeben kopierten Schlüssel signierte Image über das reguläre AVM-Web-Interface flashen lassen.

 

[oelidoc]

Hallo,

die Funktionalität an sich gibt es eigentlich schon seit Juni 2016, aber dokumentiert habe ich es erst gestern. Selbst nicht getestet, da keine 7390 im Besitz. Feedback ist willkommen.

hier also mein Feedback: ich habe mit der Methode von er13 mittels freetz und fwmod_custom eine selbst signierte 6.80 mit telnet Zugang und debug.cfg für die 7390 erstellt und diese dann mittels push_firmware auf die 7390 geflasht. Hat alles auf Anhieb geklappt. Nur die Installation des LCR per telnet war dann ein bißchen frickelig - ich musste mehrmals den Stecker ziehen, um Neustarts auszulösen. Aber jetzt läuft alles automatisch - auch nach einem Neustart der Box.
Gruß
oelidoc

 

[BurningCrash]

Nur die Installation des LCR per telnet war dann ein bißchen frickelig - ich musste mehrmals den Stecker ziehen, um Neustarts auszulösen. Aber jetzt läuft alles automatisch - auch nach einem Neustart der Box.
Gruß
oelidoc

Da hänge ich bei einer 7390 und einer 7360 dran das der LCR sich nicht in die debug.cfg einträgt. Im Freetz-Menü hab ich ausgewählt ,debug.cfg reaktiveren, und nach einem Neustart muss ich den LCR neu einrichten.

Any Hints?

 

[oelidoc]

Dann versuch es doch mal mit fwmod im "no-freetz Modus" (siehe #80). Telnet, scripts und debug.cfg in fwmod_custom einkommentieren und dann "make"
Gruß
oelidoc

 

[BurningCrash]

Kurze Frage:

Die Zeilen mit telnetd und debug.cfg sind mir ja klar aber welches von den mittleren noch?

# restore telnet support, the user still needs to activate it via the phone code (#96*7*)        
#      ln -sf ../../bin/busybox ./filesystem/usr/sbin/telnetd


        # source freetz-helper-functions and freetz .config
        # only necessary if freetz patch-scripts are used for modifications
#       . "$(dirname $0)"/tools/freetz_functions
#       . "$(dirname $0)"/.config


        # restore debug.cfg support (using Freetz script)
#        FILESYSTEM_MOD_DIR=./filesystem . ../../patches/scripts/114-debug_cfg_support.sh

Konnte eine FW bauen damit wo Telnet-Login geht aber LCR trägt sich nicht in debug.cfg ein und auch debug.cfg lässt sich nicht öffnen mit nvi.

 

[PeterPawn]

Die beiden "dot"-Kommandos müssen einkommentiert werden, wenn das Skript aus "patches" verwendet werden soll. Dort werden u.a. ein paar Kommandos definiert (z.B. "modsed") und die Konfigurationsvariablen aus der Freetz-Konfiguration eingelesen ... ohne diese funktioniert das "114-debug_cfg_support.sh" nicht richtig.

 

[Mr.I]

Dein Public-Key in dem von AVM erwarteten Format ist auf Deinem Build-System unter ~/.freetz.image_signing.asc zu finden.

Hallo,
und vielen Dank für die schnelle Antwort. Leider war ich ab Dienstag beruflich unterwegs, so dass ich erst ab jetzt dazu komme hier weiter zu machen.

Könntest Du mir bitte noch einen Hinweis geben, so diese Datei zu finden ist? Ich habe sowohl im "Putty-Fenster" gesucht, als auch mit Filezilla per FTP. Ich finde nicht eine Datei mit der Endung *.asc oder mit "signing" im Dateinamen. Mich hat des Gefühl beschlichen das ich auf der falschen Fährte bin, habe auch mit Google keine Hilfestellung finden können...

Dank und Gruß,
Mr. I

 

[Shirocco88]

Könntest Du mir bitte noch einen Hinweis geben, so diese Datei zu finden ist? Ich habe sowohl im "Putty-Fenster" gesucht, als auch mit Filezilla per FTP. Ich finde nicht eine Datei mit der Endung *.asc oder mit "signing" im Dateinamen. ...habe auch mit Google keine Hilfestellung finden können...

siehe http://trac.freetz.org/wiki/help/howtos/development/sign_image

 

[BurningCrash]

Die beiden "dot"-Kommandos müssen einkommentiert werden, wenn das Skript aus "patches" verwendet werden soll. Dort werden u.a. ein paar Kommandos definiert (z.B. "modsed") und die Konfigurationsvariablen aus der Freetz-Konfiguration eingelesen ... ohne diese funktioniert das "114-debug_cfg_support.sh" nicht richtig.

Danke für die Info. Also bei Versuch gestern haben noch führte leider wieder dazu:

#nvi /var/flash/debug.cfg
cat: can't open '/var/flash/debug.cfg': No such file or directory

Die Box auf der ich das gemacht habe ist eine 7360v1.

Also im Output vom Terminal is mir beim zusammenbauen der Firmware nix angezeigt worden.

 

[Joe_57]

Normalerweise steht die debug.cfg als Caracter-Device in /var/flash/
Mach zuerst mal ein

touch /var/flash/debug.cfg

und versuch es dann nochmal mit dem nvi.

Joe

 

[Shirocco88]

#nvi /var/flash/debug.cfg
cat: can't open '/var/flash/debug.cfg': No such file or directory

Hier fehlt c-device file.
die Fingerübung um dies zu fixen:

ls -la /var/flash/debug.cfg
major=$(grep tffs /proc/devices)
tffs_major=${major%%tffs}
mknod /var/flash/debug.cfg c $tffs_major
ls -la /var/flash/debug.cfg

Richtig wäre:

FB7490# ls -la /var/flash/debug.cfg
[B][COLOR=#0000ff]c[/COLOR][/B]rw-r--r--    1 root     root      243,  98 May 11  2016 /var/flash/debug.cfg
FB7490#

 

[BurningCrash]

Hier fehlt c-device file.

# mknod /var/flash/debug.cfg c $tffs_major
BusyBox v1.20.2 (2014-09-26 13:25:19 CEST) multi-call binary.


Usage: mknod [-m MODE] NAME TYPE MAJOR MINOR


Create a special file (block, character, or pipe)


        -m MODE Creation mode (default a=rw)
TYPE:
        b       Block device
        c or u  Character device
        p       Named pipe (MAJOR and MINOR are ignored)


# ls -la /var/flash/debug.cfg
-rw-r--r--    1 root     root             0 Mar  4 16:51 /var/flash/debug.cfg

Das kriege ich als Output raus.

Hast du da eine Idee?

Die 7360v1 ist auf 06.30

 

[PeterPawn]

Schau besser noch einmal im erzeugten Image nach ... die "rc.tail.sh" sollte das Anlegen des char-Devices bereits enthalten, wenn die Änderung durch den Patch korrekt umgesetzt wurde. Ist das bereits fehlgeschlagen, nutzt auch jede nachträgliche Anstrengung zum Editieren der Datei nichts mehr - die wird dann ja trotzdem nicht beim nächsten Systemstart "abgearbeitet".

 

[Mr.I]

siehe http://trac.freetz.org/wiki/help/howtos/development/sign_image

Hatte ich bereits gelesen...
In meinem Home-Verzeichnis sind lediglich drei Verzeichnisse:
freetz
ftp
lost+found

 

[PeterPawn]

Das sind ja "dot files" ... der Punkt am Beginn des Dateinamens sorgt dafür, daß die in einer "normalen" Auflistung eigentlich nicht enthalten sind.

Wenn man das also mit irgendeinem FTP-Client auslesen will, muß man sich etwas anstrengen ... das kann von sehr vielen Faktoren (beginnend beim FTP-Server bis zum -Client und den dort jeweils möglichen Einstellungen) beeinflußt werden. Da würde ich ganz simpel hingehen und in einer Shell-Session die Datei (so sie vorhanden ist) direkt in als "avm_public_key_irgendwas" umbenennen kopieren, wenn ich sie über einen FTP-Client herauskopieren will - das spart jede Menge Sucherei nach passenden FTP-Einstellungen.

Erst dann, wenn da wirklich auch in einer Shell-Session im Home-Verzeichnis diese Dateien nicht zu finden sind (bei Verwendung der "a"-Option für das "ls"-Kommando), erst dann würde ich beginnen, mir Sorgen zu machen und genauer zu erforschen, wo diese geblieben sein könnten.

PS: Ist aber tatsächlich wieder "Linux-Basiswissen", das man sich schon (bzw. ohnehin) "draufschaffen" sollte ... wenn es wirklich daran liegen sollte, daß es halt "dot files" sind.

 

[Mr.I]

Den Gedanken, dass es sich um versteckte Dateien handelt hatte ich schon.
Und habe selbstverständlich mit dem Schalter -a auch die versteckten Dateien angezeigt.
Also neben den oben genannten 3 Verzeichnissen wird man dann auch "." und ".." angezeigt. Das war's.

Ich war mir zunächst unsicher ob ich das "richtige" Home-Verzeichnis anzeige. => Nachdem ich mich mit Putty im Terminal "draufgeschaltet" habe, 1x mit "cd .." ein Verzeichnis höher wechseln; das ist das "richtige" Home-Verzeichnis, oder?

Ich werde gleich mal ein weiteres Image mit der Anleitung von Seite 3 bauen. Ich bin mir zwar sicher, nach "make menuconfig" im Menü "Firmware packaging (fwmod) options" auch "Sign image" angehakt zu haben und ein eigenes Passwort vergeben zu haben. Ich hoffe, das war soweit schon mal richtig. Das mache ich gleich nochmal Schritt für Schritt um einen Fehler in der Vorgehensweise meinerseits möglichst auszuschließen. Hoffentlich ist danach die "Signing-Datei" auch geschrieben worden.

Ansonsten würde ich mir erlauben, hier nochmal dumme Fragen zu stellen...

So long,
Mr.I

 

[PeterPawn]

Wenn Du die Option zum Signieren aktiviert hast, werden die Dateien für die Schlüsselverwaltung ja automatisch erstellt, wenn sie noch nicht existieren (passiert alles in "fwmod", ab Zeile 1547).

Das ergibt dann auch die entsprechenden Ausschriften beim "make" - die Nachrichten gehen als "echo0" raus, sollten also auch bei jeder beliebigen Einstellung für "verbosity" sichtbar sein.

Als Speicherort für die Dateien (bzw. als Präfix für die Namen) wird (nach Patch in Freetz) "$HOME/.freetz.image_signing" verwendet ... da könnte also nur noch die Variable "$HOME" irgendwo in die Wüste zeigen (die gibt es aber nach der POSIX-Spezifikation eigentlich in so ziemlich jeder Shell). Was da gerade eingestellt ist, läßt sich ja mit "echo $HOME" anzeigen.

Wenn das alles nicht hilft und tatsächlich in der Konfiguration das Signieren aktiviert war, dann gehen mir auch die Ideen aus ... dann wäre das Protokoll mit Verbosity=2 (am besten per "fmake" erstellt, siehe Freetz-Wiki) die nächste Anlaufstelle.

- - - Aktualisiert - - -

Wenn man mit der "Zusatzinformation" in der Frage nach "cd .." dann die vorhergehenden Fragen noch einmal liest, drängt sich der Eindruck auf, daß Du unter "/home" suchst und nicht unter "/home/freetz" - mit Home-Directory ist natürlich das für den jeweiligen Benutzer gemeint und das ist (wenn man die Freetz-VM benutzt) nun mal "/home/freetz" und damit findet man die Datei (wenn alles funktioniert hat) als "/home/freetz/.freetz.image_signing.asc".