[HowTo] Infos/Anleitung Freetz auf 7490 und 7590 flashen Stand 2019

[PeterPawn]

Das "Downgrade"-Problem (Link weiter vorne) ist durchaus real und seit der Umstellung der Speicherung von Versionsvariablen bei AVM (wo das jetzt in der "rc.conf" anstelle der "/etc/version" steht) auch nicht korrigiert, wenn mir nicht etwas entgangen sein sollte. Das hat mit der Frage "Laborversion oder nicht" oder auch "frisch oder nicht" aber gar nichts zu tun - das müßte (wenn ich mich richtig erinnere) seit 07.10 (bzw. 07.08 als Labor) bestehen und bekannt sein und sieben Monate sind für mich nicht mehr wirklich "frisch".

Dasselbe gilt für die Puma6-Installationen ... die Aussage, daß das alles erst beim Reboot installiert würde und man bis dahin einfach den Stecker ziehen könne, stimmte für die Installation bei diesen Boxen noch nie - denn die verwenden einen anderen Ablauf in der "/var/install", den Freetz gar nicht berücksichtigt. Da wird nicht erst die "/var/post_install" um die Kommandos zur Installation erweitert (wie bei anderen Modellen), da wird direkt in die entsprechenden eMMC-Partitionen geschrieben. Wer - wie AVM - verschiedene Plattformen unterstützen will, der muß halt auch die Unterschiede zwischen ihnen kennen und berücksichtigen - das gilt auch für Freetz(-Mod).

EDIT: Und der Verzicht auf die Verfolgung der Installation von Firmware (in der /var/flash/fwupdatetrace.cfg), der unmittelbar mit der Benutzung des Freetz-GUI zur Installation neuer Firmware-Images einhergeht (allerdings auch mit der Verwendung von "modfs", was mir "schwer im Magen liegt"), sollte vielleicht auch noch erwähnt werden ... es ist ja nicht so, daß AVM nicht bei der Protokollierung von Updates (oder zumindest ihres Ergebnisses) inzwischen auch nachgelegt hätte und daß der gesamte Update-Mechanismus seit Jahren unangetastet wäre - auch AVM bietet ja inzwischen (wenn auch nur unter eng begrenzten und vom JUIS gesteuerten Umständen) ein Downgrade auf eine vorhergehende Version an (allerdings immer noch mit Installation, anstatt einfach - wenn die Voraussetzungen stimmen - über die Umschaltung von "linux_fs_start").

 

[georg3003]

HAllo,

es passt indirekt hierher. Deshalb schreibe ich hierherein.

Ich versuche gerade eine FW für eine 7390 zu erstellen.
Ohne Signatur funktioniert die Erstellung scheinbar, jedoch bei Erstellung der Signatur kommt es zur Fehlermeldung.

Wo liegt der Fehler? oder kann mir jemand ein schlüsselpaar geben??

Danke

-----------------
STEP 1: UNPACK (SKIPPED)
detected firmware 7390_de 84.06.86 rev70974 (21.08.2019 18:46:01)
STEP 3: PACK/SIGN
WARNING: Modifications (STEP 2) and this step should never
ever be run with different configurations!
This can result in invalid images!!!
WARNING: firmware does not seem to be modified by the script
invoking custom script
forcing telefon daemon to run in in-house mode
patching ./filesystem/etc/init.d/rc.voip
restoring support for /var/flash/debug.cfg
patching ./filesystem/etc/init.d/rc.tail.sh
patching ./filesystem/etc/init.d/rc.tail.sh
checking for left over version-control-system files
packing var.tar
No image signing files found, generating them ...
ERROR: failed to generate image signing files, see console output or build/modified/generate_signing_key.log for details
make: *** [firmware-nocompile] Fehler 1
------------------------

hier die Meldung im Log.
Found ^[[1;34mOpenSSL 1.0.1 14 Mar 2012^[[0m
Check ^[[1mgenrsa^[[0m command ... ^[[1;32mOK^[[0m
Generating random seed file from /dev/random (may take some time) ... ^[[1;31mFAILED^[[0m

 

[PeterPawn]

Davon ausgehend, daß da nichts anderes geschieht, als daß 16 * 16 Bytes aus der Datei "/dev/random" kopiert werden sollen (https://github.com/PeterPawn/YourFritz/blob/master/signimage/generate_signing_key#L197), würde ich mal raten, daß dieses Device entweder gar nicht existiert oder daß der verwendete Benutzer dort keine Leserechte hat(te).

Das ist in Zeiten von "/dev/urandom" oder "haveged" (https://linux.die.net/man/8/haveged) nicht immer ungewöhnlich und um die echte Ursache des Problems hier zu ermitteln, müßte man eben das "dd"-Kommando mal von Hand (unter exakt den gleichen Bedingungen) ausführen und nach der tatsächlichen Fehlermeldung schauen. Diese wird von mir ja extra unterdrückt (FD 2 wird nach /dev/null umgeleitet), damit die Skripte auf der Console eine "ordentliche Ausgabe" erzeugen können (hier halt das "FAILED", was i.d.R. auch noch "bunt" ist, um die Aufmerksamkeit zu erregen).

Ich kenne also die Ursache nicht, warum da keine Ausgangsdaten für den Zufallszahlengenerator erzeugt werden können ... nur muß das bei jedem anderen Freetz-Benutzer, der seine eigenen Images (zumindest mit meinen Skript-Dateien) signieren will, auch genauso ablaufen - das verwendete Modell spielt da keine Rolle (zumindest keine offensichtliche). Da stellt sich mir die Frage, warum das bei anderen nicht ebenso auftriit. Allerdings muß diese Datei tatsächlich nur einmal erzeugt werden (was auch vorher schon geschehen kann, siehe Doku) und sie findet auch nur bei der (i.d.R. einmaligen) Generierung des eigenen RSA-Keys Verwendung.

 

[georg3003]

Hallo Peter,

zuerst mal danke für deine antwort.

Hier ein paar weitere infos was ich gemacht habe.

auf dem uralt freetz system (ubuntu 12.04) in virtualbox die aktuellste freetz version geholt. früher svn heute git ... hat geklappt.

Dann make und menuconfig und mirror und tools durchlaufen lassen ,damit es schon mal funzt.

unter make menuconfig dann 7390 eingestellt no-freetz modus aktiviert und durchlaufen lassen. mit signatur.

danach ohne sig weil es nicht ging, es lief durch. weiß zwar nicht wo die image gelandet ist, jedoch nochmals mit sig versucht selber fehler.

jetzt fehler hier im forum gepostet.


/dev/random und urandom beide vorhanden und per cat /dev/random wird auch kauderwelsch auf der konsole ausgegeben.


vielleicht noch ein tip?

Danke
Georg

 

[PeterPawn]

Keine Ahnung, ob es vielleicht doch an der uralten Version von Ubuntu liegt ... ich könnte mir gerade noch vorstellen, daß Blockoperationen auf "/dev/random" fehlschlagen, weil der dazugehörige Treiber diese (in alten Kernel-Versionen) noch nicht unterstützte (da bin ich aber überfragt und müßte erst recherchieren, ob es wirklich so war).

Am Ende ist dieses "Erzwingen" einer halbwegs zufälligen Initialisierung für den Zufallszahlengenerator auch nur dem Umstand geschuldet, daß "embedded devices" da etwas schwach sein können und diese (Skript-)Dateien auch auf einer FRITZ!Box verwendbar sein sollten.

Wenn Du einfach mit

dd if=/dev/urandom of=~/.freetz.image_signing.rnd bs=1 count=256

die Datei vor dem "make" von Hand anlegst, sollte das Signieren auch funktionieren. Der Zufall aus "/dev/urandom" ist zwar "nicht so gut", wie der aus "/dev/random" (das erstere blockiert nicht, wenn nicht genug Entropie vorhanden ist), aber wenn man das nicht direkt nach dem Booten eines Systems macht, sollte das auch ausreichend sein.

 

[NDiIPP]

(ubuntu 12.04)

Aua. Das ist doch schon lange tot, oder? Da würde ich wohl erst einmal eine aktuellere Grundlage schaffen.

 

[gismotro]

Mit einer aktuellen VM wird das Image ohne Probleme gebaut

Spoiler: Log

STEP 3: PACK/SIGN
checking for left over version-control-system files
integrate freetz info file into image
packing var.tar
checking signature key files
adding public signature key file
creating filesystem image (SquashFS3-lzma)
SquashFS block size: 64 kB (65536 bytes)
merging kernel image
kernel image size: 14.6 MB, max 14.9 MB, free 0.2 MB (252928 bytes)
WARNING: Not enough free flash space for answering machine!
adding checksum to kernel.image
packing images/7390_06.86.ger_freetz-ng-16497_20200329-155504.image
packed image file size: 16.9 MB (17725440 bytes)
signing packed .image file
signed image file size: 16.9 MB (17725440 bytes)
source firmware: 7390_de 84.06.86 rev70974 {GER} (21.08.2019 18:46:01)
source image file size: 16.9 MB (17674240 bytes)
done.

FINISHED
freetz@freetz-linux:~/test$

 

[georg3003]

Mit einer aktuellen VM wird das Image ohne Probleme gebaut

OK ich gebe zu ich habe schon ewig nicht aktualisiert, weil (never change a running system) bisher funktionierte es auch.

Was wäre das neueste? System. Ich werde noch heute mal selber schauen, aber wenn die dd-Zeile von Peter funzt, versuche ich es so zuerst. Und in bälde ein neues system.

Geht auch apt-get update, upgrade etc. um das system auf Vordermann zu bringen? oder besser ein fertiges image verwenden?

-------
Ich habe es nochmals nach dem DD kommando noch einmal versucht, leider nicht geklappt.

No image signing files found, generating them ...
Copying /home/freetz/.freetz.image_signing.asc to /etc/avm_firmware_public_key9
creating filesystem image (SquashFS3-lzma)
SquashFS block size: 64 kB (65536 bytes)
merging kernel image
kernel image size: 14.7 MB, max 14.9 MB, free 0.2 MB (228352 bytes)
WARNING: Not enough free flash space for answering machine!
adding checksum to kernel.image
packing images/7390_06.86.de_20200329-192614.image
unsigned image file size: 16.8 MB (17664000 bytes
signing images/7390_06.86.de_20200329-192614.image
ERROR: signing of firmware image failed, see console output or build/modified/sign_image.log for details
make: *** [firmware-nocompile] Fehler 1


Found ^[[1;34mOpenSSL 1.0.1 14 Mar 2012^[[0m
Check ^[[1mdgst^[[0m command ... ^[[1;32mOK^[[0m
Check ^[[1mrsa^[[0m command ... ^[[1;32mOK^[[0m
Verify hash algorithm ^[[1mmd5^[[0m is supported ... ^[[1;32mOK^[[0m
Input file doesn't look like a TAR archive.

 

[gismotro]

Das mit dem Update das 1.4.1 hatte ich auch mal versucht, aber das wird nicht mehr gehen.

Nimm die VM aus der PN. Das ist aktuell und läuft.

oder hier lesen : https://www.ip-phone-forum.de/threads/buildumgebung-freetz-linux.199449/page-40

[...]
unter make menuconfig dann 7390 eingestellt no-freetz modus aktiviert und durchlaufen lassen.
[...]

Welche Freetz-Version benutzt Du zum bauen ?

Freetz:

git clone https://github.com/freetz/freetz.git trunk

Freetz-ng:

svn checkout https://svn.boxmatrix.info/freetz-ng/trunk trunk

 

[georg3003]

Habe ganz neu per git ausgecheckt

Freetz also

 

[gismotro]

OK, Ich hab zum Test das Freetz-ng genutzt. Dann schaue ich mir mal auch mal das git an. Nicht das es doch ein Freetz-Problem ist.

Edit:
Auch hier wurde das Image sauber gebaut.

 

[PeterPawn]

Auch für Freetz-NG würde ich ein anderes Repo empfehlen - es gab/gibt da ja offensichtlich Knatsch hinter den Kulissen (ich enthalte mich da jeder Bewertung - der Text hinter dem Link stellt halt nur den Standpunkt einer Seite dar und der Link wurde von mir nur angebracht, um das irgendwie "zu belegen", aber nicht um da Partei zu ergreifen ... für den Opponenten kenne ich nur keinen Link zu seinem Standpunkt) und wer den Stand aus dem SVN mit dem aus GitHub vergleicht (Freetz-NG bietet auch noch weitere Quellen an, die ich jetzt nicht angesehen habe), der sieht auch sofort (hoffentlich), daß die Stände nicht übereinstimmen:

peh@vidar:/tmp> svn info https://svn.boxmatrix.info/freetz-ng/trunk
Path: trunk
URL: https://svn.boxmatrix.info/freetz-ng/trunk
Relative URL: ^/trunk
Repository Root: https://svn.boxmatrix.info/freetz-ng
Repository UUID: 149334a1-2f27-0410-a3b9-fc62619ac1e6
Revision: 16497
Node Kind: directory
Last Changed Author: fda77
Last Changed Rev: 16497
Last Changed Date: 2020-01-24 15:51:06 +0100 (Fri, 24 Jan 2020)
peh@vidar:/tmp> git clone -q https://github.com/freetz-ng/freetz-ng.git freetz-ng
peh@vidar:/tmp> cd freetz-ng/
peh@vidar:/tmp/freetz-ng> git rev-list --max-count=10 --pretty HEAD
commit 405a637d4b29e0e0ce860c336ba6f35b543f6d13
Author: fda77 <[email protected]>
Date:   Sun Mar 22 01:43:38 2020 +0100

    avm-rules: make clear ist is really deprecated

commit f0ea9a9cbfb907bb2068393edd2c0e99c190742a
Author: fda77 <[email protected]>
Date:   Sun Mar 22 01:32:06 2020 +0100

    freetz_download: github as last mirror (quota)

commit 16535157f8473d48549c7573b1e42b67a7edf393
Author: fda77 <[email protected]>
Date:   Sun Mar 22 01:23:44 2020 +0100

    docs: update for last merge

commit 7b03aaaf18e9ce2c1b5778379e8f918e9c0e3978
Merge: 4a8386df0 59ba2a6fa
Author: fda77 <[email protected]>
Date:   Sun Mar 22 01:20:47 2020 +0100

    Merge upstream

commit 59ba2a6fa67f7dc93a4cdc51a67e22bdb2e00e80
Author: telsch <[email protected]>
Date:   Fri Mar 20 21:00:05 2020 +0100

    tor: bump version to 0.4.2.7 (#276)

    Changelog:
    https://gitweb.torproject.org/tor.git/plain/ChangeLog?h=tor-0.4.2.7
    (cherry picked from commit 55da5d559ddaa341431dab63e1f3976636470933)

commit 4a8386df039ba0369c2dd80252ea154279f9373e
Author: fda77 <[email protected]>
Date:   Wed Mar 18 17:00:04 2020 +0100

    add 6660 sources

commit b2bd659a653aa8ff6ea897053f8c14e4f3d89787
Author: fda77 <[email protected]>
Date:   Wed Mar 18 16:35:22 2020 +0100

    6591 has puma7

commit ebbe50129d37ba8c1feebdb9456242a80d086ae5
Author: fda77 <[email protected]>
Date:   Wed Mar 18 16:34:54 2020 +0100

    6490+6590 have no puma7

commit 3c785eb5db3f66ab8e21fc372c560a59b31f48e5
Author: fda77 <[email protected]>
Date:   Wed Mar 18 16:24:15 2020 +0100

    bump ccache

commit e9b3ae1c78e1b16f3d1f78f1ecc3c8ebc5b7947d
Author: fda77 <[email protected]>
Date:   Wed Mar 11 13:37:00 2020 +0100

    rename menuconfig symbol

peh@vidar:/tmp/freetz-ng>

Da fehlen also ca. zwei Monate im SVN-Repository und man sollte dann eher eines der anderen empfehlen (siehe Mirror-Liste in der "README.md").

EDIT:
@georg3003:
Jetzt scheitert es ja auch nicht länger an der Generierung des eigenen Schlüsselpaars ... nunmehr hat das Skript zum Signieren den Eindruck, daß die angebotenen "Eingangsdaten" kein passendes TAR-File wären: https://github.com/PeterPawn/YourFritz/blob/master/signimage/sign_image#L258

Dieser Test wurde von mir eingebaut, damit die Leute da nicht auf die Idee kommen, irgendwelche falschen Dateien "anzubieten" beim Signieren, denn das Skript verläßt sich weiter hinten darauf, daß es sich um ein solches TAR-File handelt ... und eine "ordentliche" Image-Datei, die mit dem BusyBox-Applet "tar" erzeugt wurde (was Freetz per se macht, es gibt ja auch einen Grund, warum da tatsächlich das Applet der BusyBox genutzt wird und nicht das GNU "tar" o.ä.), sollte an der geprüften Stelle (Offset 257, Länge 5) die Zeichenkette "ustar" enthalten (https://pubs.opengroup.org/onlinepubs/9699919799/utilities/pax.html#tag_20_92_13_06). Wenn nicht, ist irgendetwas in/mit der Datei faul.

Wobei mich die Tatsache, daß da schon wieder "dd" involviert ist, eher zu der Annahme verleitet, daß irgendetwas mit diesem Kommando auf Deinem System wohl nicht stimmen dürfte. Am Ende würde es wohl bereits ausreichen, daß dieses Kommando bei Dir nicht existiert (habe ich noch nie wirklich gesehen/gehört, daß ein Linux-System (oder *nix generell) ohne "dd" ausgekommen wäre), denn da wird nur auf "Erfolg" oder "Mißerfolg" getestet und auch ein "command not found" wäre halt ein Mißerfolg. Vielleicht überprüfst Du ja mal dieses Kommando und wenn das tatsächlich nicht vorhanden ist oder nicht aufgerufen werden kann, dann sollte man mal überlegen, wo das wohl abgeblieben sein mag. Es wäre allerdings denkbar, daß Freetz beim Verzicht auf das Signieren tatsächlich ohne "dd" auskäme (wenn's auch merkwürdig wäre, denn beim Zerlegen von Images würde ich das genauso verwenden - aber das ist nur "Bauchgefühl" und nicht kontrolliert von mir) und das daher nicht zu den "Voraussetzungen" gehört.

Andererseits könnte es auch sein, daß da irgendeine alte BusyBox oder eine andere Shell zum Einsatz kommt, die mit dem Teil, der die verwendbaren/verfügbaren "externen" Kommandos variabler gestalten soll(te): https://github.com/PeterPawn/YourFritz/blob/master/signimage/sign_image#L40 nicht klarkommt.

Das wären die denkbaren Fehlerquellen, die mir da "ins Auge springen" würden und wo das Problem am Ende nun tatsächlich liegt, kann ich remote ohnehin nicht selbst ermitteln - da bleiben nur "Denkanstöße" und die eigentliche Ursache mußt Du selbst suchen. Ich kann nur versichern, daß es auf anderen Installationen (auch auf anderen als meinen eigenen) funktioniert, weil es ansonsten deutlich mehr "Beschwerden" geben müßte.

 

[prisrak1]

habs mir schon seit langem gedacht, es brodelt irgendwo. schon schade

 

[georg3003]

Jetzt scheitert es ja auch nicht länger an der Generierung des eigenen Schlüsselpaars ... nunmehr hat das Skript zum Signieren den Eindruck, daß die angebotenen "Eingangsdaten" kein passendes TAR-File wären: https://github.com/PeterPawn/YourFritz/blob/master/signimage/sign_image#L258

Wobei mich die Tatsache, daß da schon wieder "dd" involviert ist, eher zu der Annahme verleitet, daß irgendetwas mit diesem Kommando auf Deinem System wohl nicht stimmen dürfte. Am Ende würde es wohl bereits ausreichen, daß dieses ...


Andererseits könnte es auch sein, daß da irgendeine alte BusyBox oder eine andere Shell zum Einsatz kommt, die mit dem Teil, der die verwendbaren/verfügbaren "externen" Kommandos variabler gestalten soll(te): https://github.com/PeterPawn/YourFritz/blob/master/signimage/sign_image#L40 nicht klarkommt.

Hallo Peter,
das Schlüsselpaar habe ich mit Hilfe deines DD Kommandos erstellt. Es wurde sofort an die richtige Stelle kopiert. Deshalb nicht mehr die "alte" Fehlermeldung.

Ja das mit dem TAR habe ich auch gesehen, aber da kann ich leider mangelnder Programmierkenntnisse nicht nachforschen. Du hast es wohl schon gefunden, nur deine Annahme DD existiert nicht, ist leider falsch.

Ich denke mir ubuntu hat bestimmt eine Bash?? und soweit läuft das alte System eigentlich gut.

Habe mal die freetz-ng ausprobiert, und da wird das image signiert, nur habe ich das Gefühl, da fehlt der Einbau der Modifikationen.

Danke für deine Hinweise und HILFE
DANKE

 

[PeterPawn]

Ich habe das nicht weiter verfolgt, aber es könnte sein, daß Freetz-NG mit eigener Implementierung signiert.

Aber wie oben schon geschrieben ... die eigentliche Ursache kann man nur auf dem System selbst ermitteln - ein "systematischer" Fehler sollte nicht vorliegen, denn es gibt (nachweislich) verschiedene Systeme, auf denen es klappt. Ob da allerdings auch solche "Veteranen" wie Ubuntu 12.04 dabei sind ... wer weiß. Außerdem hat Ubuntu 12.04 vor nunmehr drei Jahren (April 2017) schon das Ende des Supports erreicht - da testet wohl auch niemand mehr (weil's keinen interessiert), woran das nun wohl liegen könnte. Zumindest ich nicht ...

 

[R0cket]

Ich habe irgendwan, nachdem ich es verstanden hatte, dass man die images nun signieren muss, auch angefangen, die images signieren zu lassen.

Das war aber alles schon zu spät, da ich schon zu neue stock images hatte, und daher musste ich die von mir in Post #1 beschriebenen Weg gehen, und da ist es egal ob die firmware signiert wird oder nicht. Wenn einmal freetz drauf ist, ist alles OK.

Aber ich kann bestätigen, dass ich problemlos eine signierte freetz firmware in den jahre alten freetz-linux build in virtual box builden konnte. Ein upgrade habe ich nie gemacht, das würde stunden dauern.

Freetz-NG ist aber damals fehlgeschlagen, weil in den damaligen turnk irgendetwas schief lief. Das habe ich dann nicht weiter verfolgt.

Also der einfachtse weg ist wie von mir in Post #1 beschrieben.

 

[gismotro]

Aber ich kann bestätigen, dass ich problemlos eine signierte freetz firmware in den jahre alten freetz-linux build in virtual box builden konnte. Ein upgrade habe ich nie gemacht, das würde stunden dauern.

Kannst ja mal die VM aus dem Link testen : https://www.ip-phone-forum.de/threa...etz-kompilieren-fuer-7490.306097/post-2363767