OpenVPN-Server(Bridge) auf 7560-IPClient (Fritz-OS 7.01-Freetz15014)

[PeterPawn]

2 (INSTALL_WRONG_HARDWARE)

Das sieht eher danach aus, daß Du da ein falsches Image versucht hast zu installieren.

hatte gedacht die config würde auch ohne laufender Daemon irgendwo liegen

Das rc-Skript (beim "openvpn-cgi"-Paket) baut die Konfigurationsdatei erst aus den verschiedenen Einstellungen zusammen ... daher KANN Dir auch niemand sagen, was bei Dir dort hinein muß und was nicht - es hängt absolut davon ab, was Du im GUI konfiguriert hast (und natürlich auch auf den Peers).

 

[CaptainMorgan]

7560_07.01-freetz-devel-15014.de_20190114-151717.image ist der Dateiname des Images. Das ich ein anderes hergenommen habe und es so umbenannt habe halte ich doch eher für unwahrscheinlich.

Die .config im Inneren enthält die Zeile "FREETZ_TYPE_7560=y".
Um auch die aus Versehen zu vertauschen wäre wohl ein mehrtägiges Delirium notwendig.

Das mit dem rc-Skript und dass die *.conf jedesmal neu erstell wird macht im Nachhinein natürlich Sinn.

Edit:
Habe ein neues Image erstellt ("7560_07.01-freetz-master-20190521-c48b69b4d.de_20190521-235728.image") , selbe Schoose. Wenn das darin endet das ich die Firmware wieder "flashen" muss kann es sein das ich eine Ecke rausbeiße...

 

[PeterPawn]

Keine Ahnung, warum die Installation des anderen Images nun nicht funktioniert ... das kann man ja entweder von Hand erledigen (man muß ja nur "kernel.image" und "filesystem.image" in die richtigen Partitionen schreiben) oder man muß sich halt mal nach dem Entpacken die "/var/install" vornehmen und darin ein "set -x" am Beginn setzen, bevor man das dann in der Telnet-Session aufruft.

Das dürfte jedenfalls sinnvoller sein, als die erwähnte Ecke rauszubeißen ... dadurch würde die andere Firmware ja auch nicht installiert, oder?

Dieser Fehler (das "WRONG_HARDWARE") tritt im originalen AVM-Skript "/var/install" jedenfalls genau in drei Fällen auf:

- falscher Annex
- falscher OEM
- falscher "install_type", der entweder direkt in der "/etc/version" steht (bis 07.08) oder in der "rc.conf" (als "CONFIG_INSTALL_TYPE")

Nun kannst Du Dir aussuchen, welcher dieser Werte jetzt nicht zu Deiner aktuell vorhandenen Box paßt ... einen anderen Grund, warum das install-Skript mit Fehler 2 enden sollte, kann ich (in diesem Skript jedenfalls) nicht erkennen - aber ich habe auch nur in das von der 07.10 geschaut, weil ich gar keine ältere Version für die 7560 habe (und auch nicht brauche, denn ich habe diese Box gar nicht).

-----------------------------------------------------------------------------------------------------------

Dieser "Umweg" über die ältere Version ist ggf. ja auch gar nicht erforderlich ... wenn Du beim "alten" GUI einfach mal eine TUN-basierte Verbindung konfigurierst (ohne IPv6) und diese funktioniert dann ebenso wie bei @feedzapper, dann wäre das ja schon mal ein deutlicher Fingerzeig. Die ältere FRITZ!OS-Version brauchst Du am Ende nur deshalb, weil Du Dir die vom Skript zusammengebaute Konfiguration aus dieser Version herauskopieren willst ... so habe ich das zumindest verstanden. Wenn das nicht notwendig ist, brauchst Du auch die andere Firmware-Version nicht ... entscheide Dich.

Was passiert denn, wenn Du eine neuere (bzw. dieselbe) Version installieren willst (ist ja offenbar eine 07.10) - kommt dann ebenfalls dieser Fehler?

 

[CaptainMorgan]

Von hinten nach vorne:

Was passiert denn, wenn Du eine neuere (bzw. dieselbe) Version installieren willst...?

Das funktioniert wunderbar. Hab die Images ja zwei Dutzend Mal durchgetauscht um die Interfaces zu wechseln.

Dieser "Umweg" über die ältere Version ist ggf. ja auch gar nicht erforderlich ... wenn Du beim "alten" GUI einfach mal eine TUN-basierte Verbindung konfigurierst (ohne IPv6) und diese funktioniert dann ebenso wie bei @feedzapper, dann wäre das ja schon mal ein deutlicher Fingerzeig.

Habe ich getan. Ich komme tatsächlich einen Sekundenbruchteil weiter. Habe meine alte tap Konfiguration einfach auf tun umgestellt, kein ipv6. Nun erscheint kurz in grün das OpenVPN gestartet wurde, weiter geht es allerdings immer noch nicht, die Box ist wieder im "Notlaufprogramm".

Nun kannst Du Dir aussuchen, welcher dieser Werte jetzt nicht zu Deiner aktuell vorhandenen Box paßt

Nun er passt. Es ist im Grunde die Konfiguration die ich damals auf die jungfräuliche Box gemacht habe. Es scheint eher so dass das Update auf 7.10, bzw das zugehörige Freetz-Release die Box in eine Identitätskrise gestürzt hat.

- falscher Annex
- falscher OEM

Dürfte sich ja eigentlich nicht sein, außer irgendwo hat irgendwas so richtig Mist gebaut.

- falscher "install_type", der entweder direkt in der "/etc/version" steht (bis 07.08) oder in der "rc.conf" (als "CONFIG_INSTALL_TYPE")

Nun ich denke das Wunschergebnis ist INSTALL_SUCCESS_REBOOT=1.

Aber:

nach dem Entpacken die "/var/install" vornehmen und darin ein "set -x" am Beginn setzen

Die Executive ist mir nicht klar. Ich beherrsche kein Shell-Skript.
Ich komme gerade so mit cd, ls, cp und cat durch die Gegend. Ich bin mir nicht sicher welche Variable ich worauf setzen muss.

 

[PeterPawn]

Wenn man ein Shell-Skript "tracen" will (also die ausgeführten Kommandos verfolgen möchte), kann man entweder beim Aufruf der Shell das Flag "-x" mit angeben (das gilt sowohl für die Form "/bin/sh -x <scriptname> <parameter>" auf der Kommandozeile als auch für die Angabe im "SheBang", wo man tatsächlich auch "#! /bin/sh -x" setzen kann) oder man kann dieses Flag nachträglich per "set"-Kommando an einer gewünschten Stelle im Skript erst setzen, dann beginnt die Ausgabe erst dann, wenn diese Stelle zum ersten Mal passiert wurde (falls das Skript da mehrfach vorbeikommt bei der Abarbeitung).

Hat man ein längeres Skript und will - rein aus Gründen der Übersichtlichkeit - nur einen Ausschnitt darin "verfolgen", dann setzt man vor die erste interessante Zeile einfach eine weitere mit dem Inhalt "set -x" und hinter die letzte interessante Zeile wieder ein "set +x" ... damit werden einem bei der Abarbeitung genau die Zeilen dazwischen auf STDERR angezeigt, BEVOR sie ausgeführt werden.

Wobei ich noch einmal daran erinnern will, daß der Umweg über die ältere Version von mir nur deshalb empfohlen wurde, weil Du Dir daraus die benötigte Konfigurationsdatei für das andere OpenVPN-GUI-Paket kopieren wolltest/solltest. Das sind also zwei verschiedene Paar Schuhe bzw. unterschiedliche Ziele, die hier verfolgt werden ... einmal die Suche nach der Problemursache unter 07.10 und einmal die Suche nach einer funktionierenden Konfigurationsdatei für das andere OpenVPN-GUI (openvpn-v2-gui).

Wenn Du bei einer TUN-Verbindung schon mal bis zu der Stelle kommst, wo Dir irgendwas im Freetz-Interface mit "grün" angezeigt wird, dann gab es ja schon sehr, sehr viele weitere Schritte, die nach dem Start des OpenVPN-Daemons noch ausgeführt wurden ... denn bis zur Aktualisierung im Freetz-GUI passiert da schon noch so einiges. Das mit dem "Sekundenbruchteil" mag also auf der t-Achse stimmen, sagt aber nur wenig darüber aus, was da im Hintergrund passiert.

------------------------------------------------------------------------------------------------------------

Gerade weil Du - nach eigener Einschätzung - so wenig Erfahrung hast, würde ich an Deiner Stelle zuerst mal unter 07.01 versuchen, eine funktionsfähige Konfiguration für das neuere OpenVPN-GUI zu erstellen (schließlich hast Du diesen "Wunsch" des Wechsels des GUI ja in #80 deutlich zum Ausdruck gebraucht), weil man dort eben weiß, daß es (zumindest bei anderen) noch funktioniert. Danach erst würde ich mich mit genau dieser Konfiguration auf eine 07.10 stürzen ... nach den jüngsten Ergebnissen halte ich es jedenfalls für extrem wahrscheinlich, daß das Problem gar nicht durch den OpenVPN-Daemon direkt verursacht wurde, sondern eher durch das "brctl addif", was vom rc-Skript bei einer Verbindung mit einem TAP-Device aufgerufen wird.

Allerdings kann man das ja auch wieder sehr gut testen, indem man aus dem regulären rc-Skript genau dieses Kommando entfernt (einfach mit einem Editor vor dem Build-Aufruf die vier Zeilen (https://github.com/Freetz/freetz/blob/master/make/openvpn-cgi/files/root/etc/init.d/rc.openvpn#L40) löschen) und dann - bei konfigurierter TAP-Verbindung, die man zuvor unter 07.01 auch auf korrekte Funktion getestet hat - das "brctl addif lan tapX" einfach von Hand aufruft. Dann sollte das System - wenn die angenommene Ursache stimmt - eben erst bei dieser manuellen Eingabe abstürzen.

Es ist auch nicht so vollkommen unerwartet und unwahrscheinlich, daß bei einem "brctl" für das Interface "lan" (über das u.a. auch eine Telnet- oder SSH-Session läuft) die Bridge noch einmal (über entsprechende Callback-Routinen) von der AVM-Firmware neu initialisiert wird - da hat sich (zumindest darf man das auch aufgrund anderer Probleme beim WLAN vermuten) wohl durch das Mesh einiges an den inneren Zusammenhängen bei AVM geändert - was auch nicht wirklich verwunderlich wäre, wenn man bedenkt, daß beim Mesh auch schon mal etwas getrickst wurde und wird, wenn man einen Client ohne entsprechende Fähigkeiten (mit den passenden Erweiterungen des WLAN-Standards) partout auf ein anderes Interface "zwingen" will - da wird dann auch schon mal die Anmeldung an dem einen verweigert (obwohl sie eigentlich richtig wäre) oder auch mal ein Interface kurz stillgelegt - allerdings weiß ich nicht, ob das in den neuesten Versionen immer noch so ist.

------------------------------------------------------------------------------------------------------------

Warum Du nun nicht mehr von der 07.10 auf eine 07.01 downgraden kannst unter Freetz-Bedingungen, kann ich Dir jedenfalls auch nicht so aus dem Stand sagen ... ich gehe mal davon aus, daß Freetz das "/var/install"-Skript auch mit dem korrekten Parameter (das wäre in diesem Falle ein "-d") aufruft? Mich hat dieser Mechanismus der Installation in Freetz nie wirklich interessiert, daher kenne ich dort den aktuellen Stand auch nicht (früher gab es jedenfalls auch mal ein Protokoll des Aufrufs von "/var/install"?).

Aber mit der Labor-Reihe 07.08 hat AVM eben auch selbst diesen neuen Downgrade-Mechanismus etabliert und der hat auch Auswirkungen auf die "/var/install" (habe ich mal ganz am Beginn der Labor-Reihe - inzwischen vermutlich vor über einem halben Jahr - im IPPF aufgeschrieben) und sollte auch irgendwelche Änderungen in Freetz nach sich ziehen.

Ich bin mir nicht mal sicher, ob bei AVM die "/var/install" jetzt noch in jedem Falle sauber arbeitet, wenn man diese nur mit "-f" aufruft. Warum? Weil da gleich bei der Feststellung, daß als Parameter ein "-f" angegeben wurde (was von der Bedeutung her ein Downgrade mit Werkseinstellungen ist, im Gegensatz zum "-d", wo die Einstellungen erhalten bleiben), die bisherigen Einstellungen gelöscht werden und zwar schon zu einem Zeitpunkt, wo noch nicht einmal geprüft wurde, daß die neuen Dateien für Kernel und Dateisystem tatsächlich vorhanden und gültig sind (die könnten ja - zumindest theoretisch - auch durch mangelnden Platz beim Entpacken nur partiell den richtigen Inhalt haben).

Dann kommt noch hinzu, daß i.d.R. der "ctlmgr" ja auch beim Herunterfahren des Systems noch die eine oder andere Einstellung (quasi als "Abschluß") schreibt ... und wenn der noch läuft und irgendetwas Neues schreibt, macht er die Bemühungen zum Löschen der alten Einstellungen gleich wieder zunichte. Das erscheint mir - zumindest wenn meine Annahmen noch stimmen, die ja i.d.R. auf der Beobachtung älterer Versionen beruhen - zu wenig getestet ... auch weil es bei AVM (außer über TR-069, bei TR-064 weiß ich es nicht) wohl gar nicht mehr so ohne weiteres auszulösen ist, daß die "/var/install" mit "-f" als Parameter aufgerufen wird vom "firmwarecfg"-Binary.

------------------------------------------------------------------------------------------------------------

Generell zum Freetz und zur Installation neuer Firmware:

Wobei eben auch in Freetz inzwischen viel Bullshit passiert, wenn man sich das tatsächlich ausgeführte Update-Skript mal genauer ansieht: https://github.com/Freetz/freetz/blob/master/make/mod/files/root/usr/lib/mww/do_update_handler.sh

Das geht bei Zeile 88 los, wo für ein "Downgrade" gerade mal noch die "/etc/version" durch eine andere ersetzt wird, die eine uralte Versionsnummer vorgaukelt. Vom Löschen irgendwelcher Einstellungen, wie es bei AVM bei einem echten Downgrade mit "-f" geschieht, ist da weit und breit nichts zu sehen.

Zwar wird auch von Freetz dann (wie vom originalen "firmwarecfg") noch das "prepare_fwupgrade" aufgerufen, welches tatsächlich einen Teil der Dienste von AVM beendet, aber das ersatzlose Löschen der "/var/post_install" von AVMin Zeile 170 ist auch deutlich "old school" und reichlich kühn, wenn man sich die aktuellen "/var/install" von AVM ansieht:

# next: prepare_update
#! /bin/sh
##################################################################################
# prepare install
##################################################################################
# do no longer overwrite/remove /var/post_install
if [ ! -f /var/post_install ] ; then
# create, if not present
  echo "#! /bin/sh" >/var/post_install
fi
# append sequence to /var/post_install
echo 'echo $0: start' >>/var/post_install

und das steht da nicht erst seit FRITZ!OS 7 drin.

In der originalen "/var/post_install" werden halt viele Dienste noch einmal sauber (oder zumindest sauberer) beendet, die sich in "prepare_fwupgrade" nicht so ohne weiteres beenden ließen und trotzdem vor dem "harten Reboot" noch einigermaßen vernünftig beendet werden sollten.

Am Ende wäre meine Einschätzung, daß man in Freetz das Installieren einer anderen Firmware (egal ob mit oder ohne Downgrade und hier auch noch, ob mit oder ohne Verlust der bisherigen Einstellungen) mal dringend überarbeiten müßte ... für jeden dieser Fälle bieten die (aktuellen) Skripte von AVM die passende Option an und irgendwelche Kunstgriffe sind da gar nicht (mehr) notwendig. Ebenso ist die Annahme (bzw. die Aussage im Text), man könne auch nach dem Abarbeiten der "/var/install" das alles noch in jedem Falle wieder ungeschehen machen, indem man einfach den Stecker zieht, lange nicht mehr für alle Modelle richtig - die Abläufe bei der Installation sind ganz unterschiedlich, je nach Architektur und Freetz täte (in meinen Augen jedenfalls) gut daran, sich bei der Installation auf die Erfahrungen der AVM-Leute zu verlassen. Wenn diese zu der Einschätzung gelangen, daß man die Vorgänge auf unterschiedlichen Modellen auch unterschiedlich ablaufen lassen sollte, würde ich mich nur dann wagen, dieser Einschätzung zu widersprechen, wenn ich es tatsächlich - zumindest auf empirischer Basis - besser weiß. Bis dahin würde ich einfach meine Images signieren und über das Datei-Update von AVM einspielen ... der "firmwarecfg" sollte auch in aktueller Firmware wissen, wie er mit einem Update umgehen muß.

Schon das Löschen der "/var/post_install" vor dem Aufruf der "/var/install" durch Freetz ist jedenfalls ein Schritt, der in vielen Fällen tatsächlich keine Auswirkungen haben mag, weil sich z.B. alle Dienste sauber beenden lassen.

Ist das aber mal bei einem nicht der Fall und werden deshalb z.B. gepufferte Schreibzugriffe auf den USB-Speicher (oder auch auf den internen) nicht mehr ausgeführt, hat man sich schneller irgendein Dateisystem oder irgendeine wichtige Datei zerschossen, als man es wahrhaben will. Anders als die ganz frühen FRITZ!Boxen, wo das Steckerziehen noch ein probates Mittel gewesen sein mag und wo seitens AVM für die Einstellungen (als einzige zu beschreibende Stelle) entsprechende Transaktionssicherheit durch das TFFS gewährleistet wurde, gibt es heute in den Boxen schon mit der originalen Firmware und erst recht mit Freetz genug denkbare Stellen, wo Dateien über lange Zeit offengehalten werden und wo - schon aus Gründen der Performance, aber bei Flash-Speicher auch aus Gründen der Lebensdauer - solche Schreiboperationen gepuffert werden.

Dann kann man sich aber mit dem "Power-Reset" auch schnell mal etwas kaputtmachen an Daten ... das sollte man immer im Hinterkopf haben und dort, wo es noch irgendwie machbar ist, das System immer zuerst zu einem definierten Reboot veranlassen - zumindest sollte man es nach Kräften versuchen und auch die ganzen Kopfstände, die von AVM so nach und nach in die "/var/post_install" gepackt wurden, basieren sicherlich nicht nur auf einem "it would be nice to have it", sondern wohl eher auf Erfahrungen, die man mit FRITZ!Boxen in Grenzfällen gesammelt hat.

 

[CaptainMorgan]

Das gerät zwar jetzt langsam Off-Topic, aber ich befürchte es lohnt nicht dafür einen eigenen Thread aufzumachen, und es verweißt "vielleicht" auf einen Fehler in den neuesten Freetz-Versionen:
Meine Priorität den ganzen Nachmittag und Abend war also erstmal auf 7.01 downzugraden um eine funktionierende Konfiguration zu extrahieren (oder es im Zweifelsfall einfach so zu lassen bis Version anno dazumal, "never touch a running system" gilt halt am Ende doch, ich Idiot....).
Ich habe ein wenig in den Skripten rumgestochert, aber wirklich ohne Sinn und Verstand. Um so etwas selbst zu machen braucht man entweder solide Grundlagen in Linux oder eine Schritt für Schritt Anelitung.
Trotzdem vielen Dank PeterPawn.
Dann habe ich versucht das alte, funktionale Image wieder mit den EVA-Tools auf die Box zu bekommen. Zugegeben der Holzhammer, aber bewährt.
Aber:

DEBUG: Sent
UNSETENV kernel_args_tmp
================
DEBUG: Response:
501 environment variable not set

Mache ich hier mal wieder etwas falsch?
Muss ich jetzt erst über die originale Recover.exe von AVM?
Dann wären die meisten Freetz-Einstellungen ja auch erstmal weg. Oder kann man den gemachten Backups vertrauen?
Ich fühl mich nach der Woche mittlerweile ganz schön verloren in der Thematik und hätte eigentlich bis heute Abend ein funktionierendes VPN gebraucht.

 

[PeterPawn]

Die einzige Stelle, wo tatsächlich mal ein "UNSETENV" vorkommt, ist der Versuch nach einem Fehler beim Upload eines Images, die zuvor gesetzten Parameter wieder zu entfernen, ohne daß der Benutzer dafür die Box wieder neu starten muß: https://github.com/PeterPawn/YourFritz/blob/master/eva_tools/EVA-FTP-Client.ps1#L314 - daher muß/darf man wohl hier darauf schließen, daß Du mit "eva_tools" die PowerShell-Versionen meinst.

Ich weiß nicht, wie der bei Dir auf dieser Zeile ankommt ... normalerweise passiert das genau dann, wenn man mit einem falschen Image versucht, die Box zu starten und anstelle der erwarteten Antwort "226" vom FTP-Server eine Zeile mit "553" erhält, weil der Bootloader mit den übertragenen Daten nichts anfangen kann.

Du magst das ja nicht lesen wollen, aber vielleicht überprüfst Du ja doch einfach mal die Firmware, die Du da auf die Box bringen willst. Wenn unter Freetz-Bedingungen ein Fehlercode 2 ausgegeben wird (die "Übersetzung" in "WRONG_HARDWARE" hast Du ja mitbekommen) und auch beim versuchten Upload über "EVA-FTP-Client.ps1" ein Problem auftaucht, spätestens dann sollte man einfach mal innehalten und nachsehen (man kann so ein Image ja auch entpacken), ob man sich nicht doch bei irgendwelchen früheren Aktionen beim Umbenennen und/oder Speichern vertan hat.

Für die Analyse, was sich in einer Image-Datei am Ende tatsächlich verbirgt (immer unter der Annahme, daß es sich tatsächlich um ein Firmware-Image im TAR-Format handelt), kann man - wenn man das nicht von Hand beherrscht - auch ein paar Skript-Dateien aus dem YourFritz-Repository benutzen, nur stehen die in einem anderen Branch: https://github.com/PeterPawn/YourFritz/tree/signimage_database/signimage/database

Eigentlich sind die dazu gedacht, alle in einem bestimmten Unterverzeichnis versammelten Images zu untersuchen, denn der Haupteinsatzzweck ist das Zusammenstellen einer Datenbank mit den von AVM für das Signieren der Firmware verwendeten Schlüsseln. Trotzdem kann man sie auch verwenden (nachdem man den richtigen Branch in seinem Git-Clone ausgecheckt hat), um Informationen über den Inhalt der Dateien in einem Verzeichnis zu erhalten.

Das sähe dann in etwa so aus:

peh@vidar:~> git clone --recurse-submodules -b signimage_database https://github.com/PeterPawn/YourFritz.git yf1
Cloning into 'yf1'...
remote: Enumerating objects: 200, done.
remote: Counting objects: 100% (200/200), done.
remote: Compressing objects: 100% (94/94), done.
remote: Total 2815 (delta 121), reused 174 (delta 102), pack-reused 2615
Receiving objects: 100% (2815/2815), 3.83 MiB | 5.45 MiB/s, done.
Resolving deltas: 100% (1737/1737), done.
Submodule 'bin' (https://github.com/PeterPawn/yf_bin.git) registered for path 'bin'
Submodule 'first_aid' (https://github.com/PeterPawn/first_aid.git) registered for path 'first_aid'
Cloning into '/home/peh/yf1/bin'...
remote: Enumerating objects: 87, done.
remote: Counting objects: 100% (87/87), done.
remote: Compressing objects: 100% (18/18), done.
remote: Total 429 (delta 4), reused 85 (delta 3), pack-reused 342
Receiving objects: 100% (429/429), 25.63 MiB | 10.05 MiB/s, done.
Resolving deltas: 100% (88/88), done.
Cloning into '/home/peh/yf1/first_aid'...
remote: Enumerating objects: 34, done.
remote: Total 34 (delta 0), reused 0 (delta 0), pack-reused 34
Submodule path 'bin': checked out '9b31eec9563705e472493fb7cf390ef7d93ede49'
Submodule path 'first_aid': checked out 'ce0c9048aff117625ce398b1096e645c0da7d5f3'
peh@vidar:~> mkdir /tmp/firmware_7560
peh@vidar:~> cd /tmp/firmware_7560/
peh@vidar:/tmp/firmware_7560> wget http://ftp.avm.de/fritzbox/fritzbox-7560/deutschland/fritz.os/FRITZ.Box_7560-07.10.image
--2019-05-23 01:10:31--  http://ftp.avm.de/fritzbox/fritzbox-7560/deutschland/fritz.os/FRITZ.Box_7560-07.10.image
Resolving ftp.avm.de (ftp.avm.de)... 212.42.244.9, 212.42.244.7, 212.42.224.71, ...
Connecting to ftp.avm.de (ftp.avm.de)|212.42.244.9|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 27453440 (26M) [application/octet-stream]
Saving to: ‘FRITZ.Box_7560-07.10.image’

FRITZ.Box_7560-07.10.image                                  100%[==============================================================>]  26.18M  11.9MB/s    in 2.2s

2019-05-23 01:10:33 (11.9 MB/s) - ‘FRITZ.Box_7560-07.10.image’ saved [27453440/27453440]

peh@vidar:/tmp/firmware_7560> cd ~/yf1/signimage/database/
peh@vidar:~/yf1/signimage/database> l unsquashfs4-*
lrwxrwxrwx 1 peh users 46 May 23 01:09 unsquashfs4-be -> ../../../yf_bin/squashfs/x86_64/unsquashfs4-be
lrwxrwxrwx 1 peh users 46 May 23 01:09 unsquashfs4-le -> ../../../yf_bin/squashfs/x86_64/unsquashfs4-le
peh@vidar:~/yf1/signimage/database> ln -sf ../../bin/squashfs/x86_64/unsquashfs4-be
peh@vidar:~/yf1/signimage/database> ln -sf ../../bin/squashfs/x86_64/unsquashfs4-le
peh@vidar:~/yf1/signimage/database> l unsquashfs4-*
lrwxrwxrwx 1 peh users 40 May 23 01:12 unsquashfs4-be -> ../../bin/squashfs/x86_64/unsquashfs4-be*
lrwxrwxrwx 1 peh users 40 May 23 01:12 unsquashfs4-le -> ../../bin/squashfs/x86_64/unsquashfs4-le*
peh@vidar:~/yf1/signimage/database> ./extract_filesystems /tmp/firmware_7560 process_filesystem extract_version_values
Model="Fritz_Box_HW221"
Product="FRITZ!Box 7560"
Date="15.04.2019 13:00:13"
Version="149.07.10"
Subversion="-67825"
Buildnumber="67825"
Buildtype="1"
Brandings="1und1 avm"
Release="1"
BetaRelease="0"
LaborName=""
DirtyBuild=""
PublicKey1="00dfbff8337342fb8e5ae2e90d16f8e4df9ac20644f9fd6faf4d9d139c354a1f0e10c799bd3eef9cb91f286aa74e05c69dd1c4706a7f9498eb6e959e72e13e8d9ff725aaed8636e3da17d7577b60c094c7f378acb795ef6ce9b0437553f6c940c121dcf428bcbb4ba1d3767b444ae866ff8d1e21b4960e3b9ce8fbb7aff62aa5cb"
HWRevision='221' VersionMajor='149' Model='FRITZ!Box 7560' Name='avm_firmware_public_key1' Source='vendor' Modulus='00dfbff8337342fb8e5ae2e90d16f8e4df9ac20644f9fd6faf4d9d139c354a1f0e10c799bd3eef9cb91f286aa74e05c69dd1c4706a7f9498eb6e959e72e13e8d9ff725aaed8636e3da17d7577b60c094c7f378acb795ef6ce9b0437553f6c940c121dcf428bcbb4ba1d3767b444ae866ff8d1e21b4960e3b9ce8fbb7aff62aa5cb' Exponent='010001'
PublicKey2="00e0a6cfa8f51dc0c28d215f2032f5c11694214b5bf3cbdf4eea39da22868908c38b81c359b042b7edae02fda4c019a16b714e9bcd8edb1f1a96ea3713faae374b5c8bb8cc40ce6b7470ebd560856a695d24c42c0de0c0be4dbb3a2620daa7940813733dcccd2b0c4fd512c6e3ce3ae92536f45243f818ae16ff178e76f59cf7d1"
HWRevision='221' VersionMajor='149' Model='FRITZ!Box 7560' Name='avm_firmware_public_key2' Source='vendor' Modulus='00e0a6cfa8f51dc0c28d215f2032f5c11694214b5bf3cbdf4eea39da22868908c38b81c359b042b7edae02fda4c019a16b714e9bcd8edb1f1a96ea3713faae374b5c8bb8cc40ce6b7470ebd560856a695d24c42c0de0c0be4dbb3a2620daa7940813733dcccd2b0c4fd512c6e3ce3ae92536f45243f818ae16ff178e76f59cf7d1' Exponent='010001'
PublicKey3="00f2ee9ffd8556211f5644da48a252b107124b330d4c20dcf3b9bac892924cabaa4df4f53e1c62e3f2aa12a23eb1d770df1520a998078738407e6a71b077f73ba976363836b880b0dd88741bc3b83ab061691226e823404b7fc88ed278d8130fe5336eb925c78f2f8ad7cb87d9586286f768ab3236fa8fb51ae7c4bbe1e041d849"
HWRevision='221' VersionMajor='149' Model='FRITZ!Box 7560' Name='avm_firmware_public_key3' Source='vendor' Modulus='00f2ee9ffd8556211f5644da48a252b107124b330d4c20dcf3b9bac892924cabaa4df4f53e1c62e3f2aa12a23eb1d770df1520a998078738407e6a71b077f73ba976363836b880b0dd88741bc3b83ab061691226e823404b7fc88ed278d8130fe5336eb925c78f2f8ad7cb87d9586286f768ab3236fa8fb51ae7c4bbe1e041d849' Exponent='010001'
peh@vidar:~/yf1/signimage/database>

Das ist nur ein (noch unfertiges) Angebot, wie man in eine unbekannte Image-Datei "hineinsehen" kann ... man kann es annehmen, aber man muß nicht. Dem aktuellen Status ist es auch geschuldet, daß man erst mal die Links für die beiden "unsquashfs"-Programme noch anpassen muß, nachdem man das Repo geklont hat. Ich habe hier einfach mal ein AVM-Image für die 7560 direkt vom AVM-Server geladen für das Beispiel.

Wenn das Image dann am Ende tatsächlich die erwarteten Daten enthält, kann/muß man weiter suchen, wo das Problem liegt ... aber einem Phantom-Fehler hinterherzujagen, nur weil man sich nicht vergewissert hat, was eine Image-Datei tatsächlich enthält, wäre einigermaßen unklug - erst recht dann, wenn zwei - eigentlich unterschiedliche - Fehler auf verschiedenen Wegen auf dasselbe Problem hinweisen.

Das KANN zwar immer noch eine falsche Interpretation der bisherigen Ergebnisse sein ... aber es kostet max. 5 Minuten, das zu verifizieren. Natürlich muß dann beim eigenen Versuch der Analyse einer Firmware in dem Verzeichnis auch nicht die Datei vom AVM-Server liegen, sondern die eigene ... aber das versteht sich ja von selbst, wenn man die Abläufe oben verstanden hat.

------------------------------------------------------------------------------------------------------------------------------------

Ob Du das jetzt noch durchziehst oder nicht, kann ich nicht beeinflussen ... trotzdem wäre ich natürlich neugierig, wo das Problem wirklich liegt. Denn wenn sich am Ende tatsächlich herausstellen sollte, daß Du irgendwo beim Umbenennen/Speichern der alten Images einen Fehler gemacht hast, relativiert sich natürlich der ganze Aufwand, den Du bisher getrieben hast, deutlich.

Ich weiß auch nicht so genau, wie man das:

Ich fühl mich nach der Woche mittlerweile ganz schön verloren in der Thematik und hätte eigentlich bis heute Abend ein funktionierendes VPN gebraucht.

jetzt verstehen soll ... Dir wird ja nicht vollkommen entgangen sein, daß ein guter Teil der Probleme bei Dir "hausgemacht" zu sein scheint.

Bei anderen funktioniert OpenVPN auch ohne LKM, mit dem "openvpn-v2-gui"-Paket und diese anderen brauchen daher auch kein Downgrade (mal vollkommen unabhängig davon, woher das Problem dabei nun wirklich kommt, denn ich will ein neu eingeschlepptes durch das neue Downgrade auch für AVM-Firmware ja gar nicht komplett ausschließen - nur kann da auch niemand außerhalb von AVM etwas dafür) auf eine frühere Version, bei der sie möglichst auch noch die alten Einstellungen beibehalten wollen und wo sie aber nicht einfach durch das Umschalten von "linux_fs_start" wieder auf die letzte funktionierende Konfiguration kommen.

Denn auch das wäre natürlich eine Option (gewesen) ... nur müßte man dann beim Installieren einer neuen Firmware eben auch selbst die Disziplin aufbringen, diese Installationen immer so vorzunehmen, daß eine garantiert funktionierende Firmware in dem anderen Satz von Partitionen erhalten bleibt.

Niemand zwingt Dich dazu, die ältere Version zu installieren ... die brauchst DU (und niemand anderes) letzten Endes genau dafür, daß Du dort die bisher verwendete OpenVPN-Konfiguration extrahieren kannst und - wenn man es richtig macht - bis zu einer funktionierenden 07.10 als Fallback-Version, auf die man bei Problemen dann wieder zurückgehen kann. Das sind aber alles "Aufgabenstellungen", deren Erledigung ausschließlich in Deinem eigenen Einflußbereich liegt - wenn es da also "Versäumnisse" und/oder Fehler + Irrtümer gab, ist daran am Ende auch niemand anderes schuld.

 

[CaptainMorgan]

Ja ich habe die Powershell Version verwendet, da ich keine native Linux Installation unterhalte.
Das mit dem falschen Image kann ich aber Sicher ausschließen. Keines der archivierten (F!OS 7.01) Images funktioniert, weder über das WebIF noch mit dem EVA-FTP-Client.

Ich habe das sehr wohl gelesen, mehrmals..
Aber Innehalten und auf das "/var/install" Skript starren bringt einen nicht weiter, wenn man die "Programmiersprache" nicht versteht.
Deshalb halbe ich die Images mit 7Zip geöffnet und mir die .config angesehen: Sie sind für eine 7560. Das habe ich auch schon #82 kundgetan. Was man da jetzt von Hand noch mehr machen sollte weiß ich nicht, und wenn es da noch mehr gibt, dann "beherrsche" ich es nicht.
Ich habe 4-5 archivierte Versionen mit 7560 im Namen, von der ToolChain autmatisch generiert, die alle diesen Fehler ausbringen. Das ich sie alle vertauscht oder umbenannt habe eher ist unwahrscheinlich.
Aber auch das ist eine Wiederholung.
Ich habe eine Variante mit aktuellem Freetz und F!OS 7.01 in einem frischen Ordner meiner Linux VM angefertigt, selbes Resultat.
Zum Signieren verwende ich seit jeher den gleichen Schlüssel.

Auch extract_filesystems aus deiner Repo scheint das zu bestätigen.
Wenn wir mal davon ausgehen dass das Programm gefundene Images alphabetisch bearbeitet und/oder etwas Ausschlussverfahren anwenden sind das hier die Ergebnisse, in dieser Reihenfolge, für die 7.10 plus Freetz die ich geladen habe, dann die 7.01 + Freetz die ich gerne laden würde, und dann die Referenz 7.10 vom AVM-Server, um gegenzuprüfen ob ich das gleiche Ergebniss erhalte wie du:

freetz@Freetz-Server:~/yf1/signimage/database$ ./extract_filesystems /home/freetz/tmp/firmware_7560 process_filesystem extract_version_values
./extract_filesystems: Zeile 69: [: /roo: Ganzzahliger Ausdruck erwartet.
Model="Fritz_Box_HW221"
Product="FRITZ!Box 7560"
Date="15.04.2019 13:00:13"
Version="149.07.10"
Subversion="-67825"
Buildnumber="67825"
Buildtype="1"
Brandings="1und1 avm"
Release="1"
BetaRelease="0"
LaborName=""
DirtyBuild=""
PublicKey1="00dfbff8337342fb8e5ae2e90d16f8e4df9ac20644f9fd6faf4d9d139c354a1f0e10c799bd3eef9cb91f286aa74e05c69dd1c4706a7f9498eb6e959e72e13e8d9ff725aaed8636e3da17d7577b60c094c7f378acb795ef6ce9b0437553f6c940c121dcf428bcbb4ba1d3767b444ae866ff8d1e21b4960e3b9ce8fbb7aff62aa5cb"
HWRevision='221' VersionMajor='149' Model='FRITZ!Box 7560' Name='avm_firmware_public_key1' Source='vendor' Modulus='00dfbff8337342fb8e5ae2e90d16f8e4df9ac20644f9fd6faf4d9d139c354a1f0e10c799bd3eef9cb91f286aa74e05c69dd1c4706a7f9498eb6e959e72e13e8d9ff725aaed8636e3da17d7577b60c094c7f378acb795ef6ce9b0437553f6c940c121dcf428bcbb4ba1d3767b444ae866ff8d1e21b4960e3b9ce8fbb7aff62aa5cb' Exponent='010001'
PublicKey2="00e0a6cfa8f51dc0c28d215f2032f5c11694214b5bf3cbdf4eea39da22868908c38b81c359b042b7edae02fda4c019a16b714e9bcd8edb1f1a96ea3713faae374b5c8bb8cc40ce6b7470ebd560856a695d24c42c0de0c0be4dbb3a2620daa7940813733dcccd2b0c4fd512c6e3ce3ae92536f45243f818ae16ff178e76f59cf7d1"
HWRevision='221' VersionMajor='149' Model='FRITZ!Box 7560' Name='avm_firmware_public_key2' Source='vendor' Modulus='00e0a6cfa8f51dc0c28d215f2032f5c11694214b5bf3cbdf4eea39da22868908c38b81c359b042b7edae02fda4c019a16b714e9bcd8edb1f1a96ea3713faae374b5c8bb8cc40ce6b7470ebd560856a695d24c42c0de0c0be4dbb3a2620daa7940813733dcccd2b0c4fd512c6e3ce3ae92536f45243f818ae16ff178e76f59cf7d1' Exponent='010001'
PublicKey3="00f2ee9ffd8556211f5644da48a252b107124b330d4c20dcf3b9bac892924cabaa4df4f53e1c62e3f2aa12a23eb1d770df1520a998078738407e6a71b077f73ba976363836b880b0dd88741bc3b83ab061691226e823404b7fc88ed278d8130fe5336eb925c78f2f8ad7cb87d9586286f768ab3236fa8fb51ae7c4bbe1e041d849"
HWRevision='221' VersionMajor='149' Model='FRITZ!Box 7560' Name='avm_firmware_public_key3' Source='vendor' Modulus='00f2ee9ffd8556211f5644da48a252b107124b330d4c20dcf3b9bac892924cabaa4df4f53e1c62e3f2aa12a23eb1d770df1520a998078738407e6a71b077f73ba976363836b880b0dd88741bc3b83ab061691226e823404b7fc88ed278d8130fe5336eb925c78f2f8ad7cb87d9586286f768ab3236fa8fb51ae7c4bbe1e041d849' Exponent='010001'
PublicKey9="00b893eea7aa022932f2c49377bf74203a4071a3192a23fea24b9e3b1da2fb5e3723ef8eeec1674a5e6138e9762e094459db3ad462978afb6bf4da18b80fee150c3348f02648bceb32afb0469058b48248a8c8b04452e278ecda60c0caac15bc1c471259b64ecc34f9c63f993155fd45dfc2749126ae4974688789114347fc83c9"
HWRevision='221' VersionMajor='149' Model='FRITZ!Box 7560' Name='avm_firmware_public_key9' Source='vendor' Modulus='00b893eea7aa022932f2c49377bf74203a4071a3192a23fea24b9e3b1da2fb5e3723ef8eeec1674a5e6138e9762e094459db3ad462978afb6bf4da18b80fee150c3348f02648bceb32afb0469058b48248a8c8b04452e278ecda60c0caac15bc1c471259b64ecc34f9c63f993155fd45dfc2749126ae4974688789114347fc83c9' Exponent='010001'
./extract_filesystems: Zeile 69: [: /roo: Ganzzahliger Ausdruck erwartet.
Model="Fritz_Box_HW221"
Product="FRITZ!Box 7560"
Date="27.09.2018 12:11:56"
Version="149.07.01"
Subversion="-61760"
Buildnumber="61760"
Buildtype="1"
Brandings="1und1 avm"
Release="1"
BetaRelease="0"
LaborName=""
DirtyBuild=""
PublicKey1="00dfbff8337342fb8e5ae2e90d16f8e4df9ac20644f9fd6faf4d9d139c354a1f0e10c799bd3eef9cb91f286aa74e05c69dd1c4706a7f9498eb6e959e72e13e8d9ff725aaed8636e3da17d7577b60c094c7f378acb795ef6ce9b0437553f6c940c121dcf428bcbb4ba1d3767b444ae866ff8d1e21b4960e3b9ce8fbb7aff62aa5cb"
HWRevision='221' VersionMajor='149' Model='FRITZ!Box 7560' Name='avm_firmware_public_key1' Source='vendor' Modulus='00dfbff8337342fb8e5ae2e90d16f8e4df9ac20644f9fd6faf4d9d139c354a1f0e10c799bd3eef9cb91f286aa74e05c69dd1c4706a7f9498eb6e959e72e13e8d9ff725aaed8636e3da17d7577b60c094c7f378acb795ef6ce9b0437553f6c940c121dcf428bcbb4ba1d3767b444ae866ff8d1e21b4960e3b9ce8fbb7aff62aa5cb' Exponent='010001'
PublicKey2="00e0a6cfa8f51dc0c28d215f2032f5c11694214b5bf3cbdf4eea39da22868908c38b81c359b042b7edae02fda4c019a16b714e9bcd8edb1f1a96ea3713faae374b5c8bb8cc40ce6b7470ebd560856a695d24c42c0de0c0be4dbb3a2620daa7940813733dcccd2b0c4fd512c6e3ce3ae92536f45243f818ae16ff178e76f59cf7d1"
HWRevision='221' VersionMajor='149' Model='FRITZ!Box 7560' Name='avm_firmware_public_key2' Source='vendor' Modulus='00e0a6cfa8f51dc0c28d215f2032f5c11694214b5bf3cbdf4eea39da22868908c38b81c359b042b7edae02fda4c019a16b714e9bcd8edb1f1a96ea3713faae374b5c8bb8cc40ce6b7470ebd560856a695d24c42c0de0c0be4dbb3a2620daa7940813733dcccd2b0c4fd512c6e3ce3ae92536f45243f818ae16ff178e76f59cf7d1' Exponent='010001'
PublicKey3="00f2ee9ffd8556211f5644da48a252b107124b330d4c20dcf3b9bac892924cabaa4df4f53e1c62e3f2aa12a23eb1d770df1520a998078738407e6a71b077f73ba976363836b880b0dd88741bc3b83ab061691226e823404b7fc88ed278d8130fe5336eb925c78f2f8ad7cb87d9586286f768ab3236fa8fb51ae7c4bbe1e041d849"
HWRevision='221' VersionMajor='149' Model='FRITZ!Box 7560' Name='avm_firmware_public_key3' Source='vendor' Modulus='00f2ee9ffd8556211f5644da48a252b107124b330d4c20dcf3b9bac892924cabaa4df4f53e1c62e3f2aa12a23eb1d770df1520a998078738407e6a71b077f73ba976363836b880b0dd88741bc3b83ab061691226e823404b7fc88ed278d8130fe5336eb925c78f2f8ad7cb87d9586286f768ab3236fa8fb51ae7c4bbe1e041d849' Exponent='010001'
PublicKey9="00b893eea7aa022932f2c49377bf74203a4071a3192a23fea24b9e3b1da2fb5e3723ef8eeec1674a5e6138e9762e094459db3ad462978afb6bf4da18b80fee150c3348f02648bceb32afb0469058b48248a8c8b04452e278ecda60c0caac15bc1c471259b64ecc34f9c63f993155fd45dfc2749126ae4974688789114347fc83c9"
HWRevision='221' VersionMajor='149' Model='FRITZ!Box 7560' Name='avm_firmware_public_key9' Source='vendor' Modulus='00b893eea7aa022932f2c49377bf74203a4071a3192a23fea24b9e3b1da2fb5e3723ef8eeec1674a5e6138e9762e094459db3ad462978afb6bf4da18b80fee150c3348f02648bceb32afb0469058b48248a8c8b04452e278ecda60c0caac15bc1c471259b64ecc34f9c63f993155fd45dfc2749126ae4974688789114347fc83c9' Exponent='010001'
Model="Fritz_Box_HW221"
Product="FRITZ!Box 7560"
Date="15.04.2019 13:00:13"
Version="149.07.10"
Subversion="-67825"
Buildnumber="67825"
Buildtype="1"
Brandings="1und1 avm"
Release="1"
BetaRelease="0"
LaborName=""
DirtyBuild=""
PublicKey1="00dfbff8337342fb8e5ae2e90d16f8e4df9ac20644f9fd6faf4d9d139c354a1f0e10c799bd3eef9cb91f286aa74e05c69dd1c4706a7f9498eb6e959e72e13e8d9ff725aaed8636e3da17d7577b60c094c7f378acb795ef6ce9b0437553f6c940c121dcf428bcbb4ba1d3767b444ae866ff8d1e21b4960e3b9ce8fbb7aff62aa5cb"
HWRevision='221' VersionMajor='149' Model='FRITZ!Box 7560' Name='avm_firmware_public_key1' Source='vendor' Modulus='00dfbff8337342fb8e5ae2e90d16f8e4df9ac20644f9fd6faf4d9d139c354a1f0e10c799bd3eef9cb91f286aa74e05c69dd1c4706a7f9498eb6e959e72e13e8d9ff725aaed8636e3da17d7577b60c094c7f378acb795ef6ce9b0437553f6c940c121dcf428bcbb4ba1d3767b444ae866ff8d1e21b4960e3b9ce8fbb7aff62aa5cb' Exponent='010001'
PublicKey2="00e0a6cfa8f51dc0c28d215f2032f5c11694214b5bf3cbdf4eea39da22868908c38b81c359b042b7edae02fda4c019a16b714e9bcd8edb1f1a96ea3713faae374b5c8bb8cc40ce6b7470ebd560856a695d24c42c0de0c0be4dbb3a2620daa7940813733dcccd2b0c4fd512c6e3ce3ae92536f45243f818ae16ff178e76f59cf7d1"
HWRevision='221' VersionMajor='149' Model='FRITZ!Box 7560' Name='avm_firmware_public_key2' Source='vendor' Modulus='00e0a6cfa8f51dc0c28d215f2032f5c11694214b5bf3cbdf4eea39da22868908c38b81c359b042b7edae02fda4c019a16b714e9bcd8edb1f1a96ea3713faae374b5c8bb8cc40ce6b7470ebd560856a695d24c42c0de0c0be4dbb3a2620daa7940813733dcccd2b0c4fd512c6e3ce3ae92536f45243f818ae16ff178e76f59cf7d1' Exponent='010001'
PublicKey3="00f2ee9ffd8556211f5644da48a252b107124b330d4c20dcf3b9bac892924cabaa4df4f53e1c62e3f2aa12a23eb1d770df1520a998078738407e6a71b077f73ba976363836b880b0dd88741bc3b83ab061691226e823404b7fc88ed278d8130fe5336eb925c78f2f8ad7cb87d9586286f768ab3236fa8fb51ae7c4bbe1e041d849"
HWRevision='221' VersionMajor='149' Model='FRITZ!Box 7560' Name='avm_firmware_public_key3' Source='vendor' Modulus='00f2ee9ffd8556211f5644da48a252b107124b330d4c20dcf3b9bac892924cabaa4df4f53e1c62e3f2aa12a23eb1d770df1520a998078738407e6a71b077f73ba976363836b880b0dd88741bc3b83ab061691226e823404b7fc88ed278d8130fe5336eb925c78f2f8ad7cb87d9586286f768ab3236fa8fb51ae7c4bbe1e041d849' Exponent='010001'
freetz@Freetz-Server:~/yf1/signimage/database$

Die für mich ersichtlichen Sachen passen. Gleiches "Model", "Product" und "Branding". Bei der Sache mit den PublicKeys fällt mir auf das die beiden selbst erstellten einen zusätzlichen Public-Key 9 haben.

Ich weiß auch nicht so genau, wie man das [...] jetzt verstehen soll ... Dir wird ja nicht vollkommen entgangen sein, daß ein guter Teil der Probleme bei Dir "hausgemacht" zu sein scheint.
[...]
Denn auch das wäre natürlich eine Option (gewesen) ... nur müßte man dann beim Installieren einer neuen Firmware eben auch selbst die Disziplin aufbringen, diese Installationen immer so vorzunehmen, daß eine garantiert funktionierende Firmware in dem anderen Satz von Partitionen erhalten bleibt.

Niemand zwingt Dich dazu, die ältere Version zu installieren ... die brauchst DU (und niemand anderes) letzten Endes genau dafür, daß Du dort die bisher verwendete OpenVPN-Konfiguration extrahieren kannst und - wenn man es richtig macht - bis zu einer funktionierenden 07.10 als Fallback-Version, auf die man bei Problemen dann wieder zurückgehen kann. Das sind aber alles "Aufgabenstellungen", deren Erledigung ausschließlich in Deinem eigenen Einflußbereich liegt - wenn es da also "Versäumnisse" und/oder Fehler + Irrtümer gab, ist daran am Ende auch niemand anderes schuld.

Der letzte Satz sollte Frustration zum Ausdruck bringen, die wie du richtig feststellst hausgemacht ist. In Schriftform kann so vermieden werden dass eventuell aufkommende Wortkargheit und abgehackte Sätze als Affront aufgefasst werden statt als Galgenhumor. Aber das nur unter uns Vulkaniern.

Ich habe mich in die missliche Lage gebracht scheinbar relativ weit in einem Thema vorzurücken von dem ich offensichtlich nichts verstehe.
Das mit den Partitionen von vorneherein zu beachten um immer einen Fallback zu haben wäre im Nachhinein sicherlich cleverer gewesen.

Was die echte Problemlösung anfängt drehen wir uns leider im Kreis.
Zusammendfassend was mein Stand seit ~#70 ist:
-die "v1-gui" oder auch "openvpn-cgi" funktioniert mit 7.10 nicht
-ohne funktionierende v1-gui kein Konfigurations-Extraktion
-Troubleshooting der v1-gui setzt vorraus zu Überprüfen ob nicht einfach meine Konfiguration Mist ist
-ob die "Downgrade-Fehlfunktion" allgemeingültig oder hausgemacht ist wissen wir ja so noch nicht, hat ja auch sonst noch keiner bestätigt das es ginge
-ohne Downgrade keine funktioniernde Konfigurationsextraktion

Ich perönlich, mit meinen Kenntnissen und Fähigkeiten halte das, vorläufig, für einen Zirkelschluss. Außer natürlich ich mach alles platt. Aber dann ist meine Konfiguration ja vermutlich auch weg. Ich habe mal eines der Freetz-Bakcups geöffnet und von OpenVPN scheint da nichts drin zu sein. Weder die "Klick-Einstellungen" geschweige denn eine komplette "config".

 

[PeterPawn]

Zwei Sachen zuerst mal:

Ich kann mit Galgenhumor leben, solange ich ihn als solchen erkennen kann. Dank der "erweiterten Beschreibung" gehe ich nun davon aus, daß Du in jedem Falle das notwendige Stehvermögen aufbringen wirst, um die Sache weiter zu betreiben. Sicherlich verstehst Du auch, warum das wiederum für mich wichtig ist?

Ansonsten gibt es noch eine Unklarheit beim Einsatz von "extract_filesystems" ... das Problem in Zeile 69 ist Dir sicherlich auch aufgefallen. Da im Anschluß trotzdem noch die Verarbeitung weitergeht, kann es sich eigentlich nur um ein Formatproblem in der Ausgabe von "tar" handeln ... daher bitte ich Dich, einfach mal diese beiden Kommandos auszuführen, bei dem mit dem "--file" ist dieser Teil durch den Pfad zu einer der drei Image-Dateien zu ersetzen:

peh@vidar:~> tar --version
tar (GNU tar) 1.31
Copyright (C) 2019 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by John Gilmore and Jay Fenlason.
peh@vidar:~> tar --list --verbose --file="FRITZ.Box_7560-07.10.image" --wildcards ./var/tmp/\*.image
-rw-r--r-- 0/0         4753672 2019-04-15 13:00 ./var/tmp/kernel.image
-rw-r--r-- 0/0        22077448 2019-04-15 13:00 ./var/tmp/filesystem.image
peh@vidar:~>

Das hat nichts mit der Gültigkeit Deiner Images zu tun, es geht hier nur um unterschiedliche TAR-Versionen, die offenbar unterschiedliche Ausgabeformate produzieren.

----------------------------------------------------------------------------------------------------------------

Zurück zu den Versuchen, Dein Problem zu lösen ... kannst Du mal bitte die gesamte PS-Session hier zeigen, die Du verwendest, wenn Du die Installation über den Bootloader versuchst? Wenn das Image die richtigen Daten enthält, der Bootloader erreichbar ist und Du keine Fehler beim Aufruf eines Skripts machst, dann muß das auch funktionieren. Den ersten Punkt haben wir nunmehr geklärt (und zwar sicher, was schon noch mal eine andere Qualität/Aussage ist, als das, was Du zuvor geschrieben hast - denn da war iirc auch nur von einem und nicht von drei Images die Rede und da wäre ein Irrtum immer noch eine valide Annahme gewesen), der zweite ist durch die Tatsache, daß da eine Antwort von der Box kommt (mit dem "501 environment variable not set"), ebenfalls geklärt, also bleibt, bis sie widerlegt wird, nur die Annahme übrig, daß Du beim Aufruf etwas falsch machst ... z.B. das "originale" Image an das "BootDeviceFromImage" verfütterst anstelle des (richtigen) "in-memory"-Images.

----------------------------------------------------------------------------------------------------------------

Außerdem bleibt Dir ja noch die Ausgabe von "/var/install" unter Freetz-Bedingungen, auf die ich Dich in #85 versucht habe aufmerksam zu machen:

früher gab es jedenfalls auch mal ein Protokoll des Aufrufs von "/var/install"?

Was steht denn dort drin? Dem Inhalt von "/var/install" nach, sollte es entsprechende Ausgaben produzieren, die dann unter Freetz im GUI sichtbar sein sollten, denn dort wird ja STDERR zusätzlich noch nach STDOUT umgeleitet (https://github.com/Freetz/freetz/bl...es/root/usr/lib/mww/do_update_handler.sh#L178) und letztere sollte nach den ganzen anderen Umleitungen (https://github.com/Freetz/freetz/bl...les/root/usr/lib/mww/do_update_handler.sh#L29) am Ende irgendwie in der HTML-Seite landen. Ich habe zwar im Moment keine 07.01 für die 7560 zum direkten Nachlesen, was dort passiert, die brauche ich aber m.E. im Moment auch noch nicht - das unterschied sich m.W. nicht so sehr von den Abläufen bei der 7580, für die ich die Firmware sehr wohl habe.

Das "/var/install"-Skript ist jedenfalls mit "echo"-Kommandos durchsetzt. Irgendetwas MUSS dort also ausgegeben werden und das hätte ich dann gerne - und zwar von Anfang bis Ende und nicht nur die letzten zwei, drei Zeilen (unter der Annahme, daß es mehr als diese sind in der Ausgabe) - hier gelesen ... und zwar parallel zu den anderen Bemühungen, die ältere Firmware zu installieren.

Also ist es vielleicht am schlauesten, wenn Du den Versuch mit "Freetz" als erstes machst ... gelingt Dir (nach dem Hinweis auf das benötigte "in-memory"-Image) vielleicht doch das Downgrade über den Bootloader, wäre die Möglichkeit, das Update von genau dieser Version aus mit Freetz-Mitteln erneut zu versuchen, ja dahin, denn dabei wird (zumindest ohne weitere Vorbereitungen) ja die aktive Version überschrieben.

Wie man aus einem "normalen" Image auch ohne eine Linux-Installation das notwendige Image für den Bootloader erzeugen kann, habe ich - als es die Diskussion um die Inhouse-Images zur 07.08-Reihe und den neuen Key von AVM für deren Signatur gab - irgendwo hier in einem anderen Thread (detailliert, also mit Beispiel) beschrieben. Der Thread heißt irgendwas mit "Installation der neuen Inhouse-Images" oder so ähnlich - meinem Prinzip, nicht für andere zu suchen, bleibe ich vorerst treu und daher müßtest Du bitte selbst danach schauen.

----------------------------------------------------------------------------------------------------------------

EDIT:
Nun bin ich meinen Prinzipien doch untreu geworden, obwohl die Xenforo-Suche natürlich für mich genauso beschissen arbeitet (man muß es auch mal benennen und zwar ohne Sternchen bzw. "beep"), wie für alle anderen .... ich war halt mal wieder neugierig, wie leicht bzw. schwer das am Ende zu finden ist.

Das Erstellen einer Datei für den Bootloader aus einem AVM-Image (das gilt natürlich für ein Freetz-Image genauso) habe ich hier: https://www.ip-phone-forum.de/threa...rsionen-ab-version-07-08.301683/#post-2306398 beschrieben vor einem halben Jahr.

 

[CaptainMorgan]

Die "Zeile 69" tritt nur bei zwei von den drei Images auf, und tatsächlich gibt es einen Unterschied nach dem Entpacken.
(Die beiden Freetz-Images sind die mit den gekürzten Dateinamen.)

freetz@Freetz-Server:~$ tar --version
tar (GNU tar) 1.29
Copyright © 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL Version 3 oder später <http://gnu.org/licenses/gpl.html>
Dies ist freie Software: Sie dürfen sie ändern und weiter verbreiten.
Es gibt KEINERLEI GARANTIE, so weit das Gesetz es erlaubt.

Geschrieben von John Gilmore und Jay Fenlason.
freetz@Freetz-Server:~$ tar --list --verbose --file="/home/freetz/tmp/firmware_7560/FRITZ.Box_7560-07.10.image" --wildcards ./var/tmp/\*.image
-rw-r--r-- 0/0         4753672 2019-04-15 13:00 ./var/tmp/kernel.image
-rw-r--r-- 0/0        22077448 2019-04-15 13:00 ./var/tmp/filesystem.image
freetz@Freetz-Server:~$ tar --list --verbose --file="/home/freetz/tmp/firmware_7560/7560_07.10.image" --wildcards ./var/tmp/\*.image
-rw-r--r-- root/root   4753672 2019-05-15 17:31 ./var/tmp/kernel.image
-rw-r--r-- root/root  23904264 2019-05-15 17:31 ./var/tmp/filesystem.image
freetz@Freetz-Server:~$ tar --list --verbose --file="/home/freetz/tmp/firmware_7560/7560_07.01.image" --wildcards ./var/tmp/\*.image
-rw-r--r-- root/root   4236040 2019-01-14 15:17 ./var/tmp/kernel.image
-rw-r--r-- root/root  24789000 2019-01-14 15:17 ./var/tmp/filesystem.image

Warum tar noch zwei Versionen zurück ist weiß ich nicht, ich gehe eigentlich vor jedem Verwenden durch apt-get update, upgrade -d und upgrade -y.

----------------------------------------------------------------------------------------------------------------

z.B. das "originale" Image an das "BootDeviceFromImage" verfütterst anstelle des (richtigen) "in-memory"-Images

Ich kann nicht fassen dass ich das vergessen habe.
Aus welchem Grund auch immer ist in meinem Hirn hängen geblieben, dass man das in-memory.image nur beim ersten Mal erstellen muss.
Stimmt ja auch solange man über das WebIF weiter updatet und die Signatur stimmt.
Ich weiß nicht wie viel Aufwand es ist ein in-memory.image automatisiert zu erkennen und der Sache eine eigene Fehlermeldung zu spendieren, aber eventuell kann sich der Nettogesamtaufwand reduzieren wenn nicht Hinz und Kunz jedesmal nachfragen warum es nicht klappt. Ich selbst bin glaube ich nun schon zweimal in diese Bärenfalle getappt, das erste Mal war zugegebenermaßen das erste Image, und die ToolChain-Standardeinstellungen wurden kurz zuvor umgestellt. Dennoch, keine Entschuldigung für mein Versagen....
Werde es mit einem korrekten Image zeitig nochmal versuchen, wenn es dann nicht klappt kommt auch die komplette PS-Session.

----------------------------------------------------------------------------------------------------------------

Und dann noch für all die Freetz-Entwickler, wenn auch ~Off-Topic, hier das -v -v -v zum fehlgeschlagenen Downgrade:

Firmware extrahieren, Update vorbereiten
Downgrade vorbereiten ...

/etc/version: line 17: syntax error: unexpected ";;" (expecting "fi")
Downgrading ... done.
Fake firmware version:

ERLEDIGT

Firmware-Archiv extrahieren ...

./var/
./var/regelex
./var/chksum
./var/tmp/
./var/tmp/kernel.image
./var/tmp/filesystem.image
./var/info.txt
./var/version
./var/.packages
./var/.config
./var/install
./var/signature

ERLEDIGT

Ausführen des Firmware-Installationsskripts /var/install ...

install: have Kernel 3.10.104 - set kversion '3.10' and FlashUpdateTool ''
install: check and install new firmware ...
OEM=
ANNEX=B
testing acceptance for device Fritz_Box_HW221 ...
/etc/version: line 17: syntax error: unexpected ";;" (expecting "fi")
testing acceptance for device Fritz_Box_HW221 done
error: installype not korrket
set INFO led to off (modul=7, state=1)

ERLEDIGT – Rückgabewert des Installationsskripts: 2 (INSTALL_WRONG_HARDWARE)

Von /var/post_install generierter Inhalt:

Fehler: Nach-Installationsskript nicht gefunden oder nicht ausführbar.

Edit:
Für ein Image mit aktuellerem Freetz sieht die Fehlermeldung genauso aus, lässt man den Haken für Downgrade weg fehlt einfach nur der erste Kasten "Downgrade vorbereiten".

Edit 2:
Also, es war eine kleine Tortur, aber ich bin nun ein Stück weiter.
Ich konnte mein archiviertes Image mithilfe von PeterPawn's Repo noch in ein in-memory image konvertieren. Gott sei Dank hatte ich auch noch die alten Einstellungen als *.tar backup, denn bei dem Downgrade über den Bootloader ist irgendetwas übrig geblieben was sowohl einen "langsamen" Bootloop als auch den bekannten OpenVPN Crash verursacht hat, und das obwohl ich den Patch geladen hatte. Nach einigen Resets und Reboots war ich letzendlich soweit und hatte wieder ein funktionierendes OpenVPN unter 7.01 (dev tap, proto udp6).
Diese Einstellungen habe ich jetzt in die "cgi-v2" übertragen.
Zwei Zeilen musste ich dafür entfernen, weil ich gewarnt wurde das /var/tmp/openvpn nicht existieren würde.

cd /var/tmp/openvpn
chroot /var/tmp/openvpn

Es scheint auch ohne diese zu funktionieren. Unsicher bin ich mir natürlich ob aus fremden Netzwerken heraus auch wirklich Datendurchsatz erfolgt, aber das kann wohl erst der Feldversuch zeigen.

Ich persönlich würde gerne mithelfen auch die "cgi-v1 (?)" wieder ans Laufen zu bekommen.
Mit OpenVPN 2.4.7 ist dort offensichtlich auch die Option wieder erschienen zusätzliche Konfigurationen zu starten. Wer einmal ernüchtert wurde das Android Geräte die tap-Bridge nicht unterstützen weiß warum das nützlich ist.

Das ich in meiner Box rumstocher nützt natürlich nur was wenn am anderen Ende auch jemand was mit den Daten anfangen kann.

 

[PeterPawn]

Ich weiß nicht wie viel Aufwand es ist ein in-memory.image automatisiert zu erkennen und der Sache eine eigene Fehlermeldung zu spendieren, aber eventuell kann sich der Nettogesamtaufwand reduzieren wenn nicht Hinz und Kunz jedesmal nachfragen warum es nicht klappt.

Die Erkennung ist nicht so ganz trivial, außer man beschränkt sich auf die ganz, ganz groben Fehler, wo jemand direkt das TAR-File hochladen will (und auch das ist unter Windows, wo es eben kein "file"-Kommando gibt, was eine Datei etwas eingehender analysiert, nicht so ganz einfach zu erkennen).

Alles andere - vom reinen Kernel ohne Dateisystem über das Dateisystem ohne Kernel bis zu den richtigen Dateien, aber mit den Prüfsummen am Ende und daher mit falschem Alignment - ist zwar auch irgendwie zu ermitteln (unter Windows dann wieder nur mit deutlich größerem Aufwand), aber das ist eigentlich nicht die Aufgabe dieser Skript-Dateien. Ich bin mir nur einigermaßen sicher (rein aus der Erfahrung), daß auch ein Skript für die automatische Erkennung der verschiedenen Formate eher selten genutzt würde, wenn man es gesondert aufrufen soll/müßte.

Das "Zusammenfassen" der Schritte, wie es "push_firmware" aus dem "freetz-n(on-)g(enuine)"-Fork vormacht (da kann/muß man ja das komplette TAR-File angeben), ist für mich jedenfalls auch keine Option ... denn dann funktionieren meine Skripte nämlich nicht mehr mit den selbsterstellen Images, die ich u.a. in "first_aid" bereithalte bzw. für die ich entsprechende Skript-Dateien zum Erstellen eigener Images für weitere Modelle in "toolbox" bereitstelle.

Das ist bei mir also nicht nur "Unlust" ... ich habe mir schon den einen oder anderen Gedanken gemacht beim Entwurf der Skriptdateien und habe - neben "zuwenig Zeit für Verbesserungen" - oft auch meine Gründe (die ich auf Nachfragen dann auch gerne erläutere), warum ich etwas genau so mache, wie ich es mache und nicht "irgendwie anders".

---------------------------------------------------------------------------------------

Ansonsten ist das mit dem Problem bei der Installation über Freetz nicht verwunderlich, wenn man dort "Downgrade" wählt ... wie ich hier vorher schon mal angetextet habe, wird bei Freetz dieses Downgrade durch einen Kunstgriff versucht, indem die "/etc/version" so modifiziert wird, daß sie als aktuelle Version irgendeine ganz kleine Nummer ausgibt - der korrekte Weg wäre eben auch hier die Verwendung der "-d"- und "-f"-Parameter beim Aufruf, selbst wenn man den Verlust von Einstellungen bei "-f" schlucken muß. Da lag ich also mit meiner Vermutung schon einigermaßen richtig, daß hier der Freetz-Mechanismus für das Downgrade "der Böse" ist.

Denn was passiert, wenn innerhalb von "/usr/bin/prepare-downgrade" die aktuelle "/etc/version" durch das Skript "bearbeitet" wird? Das hier (Leerzeilen habe ich mal entfernt, weil die vom "nl" auch keine Nummer kriegen):

vidar:/home/FritzBox/FB7560/153.07.10 $ sed 's/\({CONFIG_VERSION_MAJOR}\).*/\1.01.01/' etc/version | nl
     1  #!/bin/sh
     2  SILENT=y
     3  . /etc/init.d/rc.conf
     4  if [ -z "$1" ]
     5  then
     6      echo "${CONFIG_VERSION_MAJOR}.01.01
     7      exit 0
     8  fi
     9  for i in "$@"
    10  do
    11      case $i in
    12          -v | --version)
    13              echo "${CONFIG_VERSION_MAJOR}.01.01
    14              ;;
    15          -vsub | --subversion)
    16              echo "$CONFIG_SUBVERSION"
    17              ;;
    18          --project)
    19              if [ "$CONFIG_BUILDDIRTY" = "1" ]
    20              then
    21                  echo "${CONFIG_BUILDNUMBER}M"
    22              else
    23                  echo "${CONFIG_BUILDNUMBER}"
    24              fi
    25              ;;
    26          -vcvc | --cvcversion)
    27              echo "$CVC_FIRMWARE_VERSION"
    28              ;;
    29          -d | --date)
    30              stat -c '%y' /etc/version | \
    31                  sed 's/^\([0-9]\{4\}\)-\([0-9]\{2\}\)-\([0-9]\{2\}\) \(.\+\)\..*/\3.\2.\1 \4/g'
    32              ;;
    33          --install=${CONFIG_INSTALL_TYPE})
    34              echo "korrekt install type: ${CONFIG_INSTALL_TYPE}"
    35              ;;
    36          *)
    37              echo "install type not korrekt: ${CONFIG_INSTALL_TYPE}"
    38              exit 1
    39              ;;
    40      esac
    41  done
vidar:/home/FritzBox/FB7560/153.07.10 $

Wie man sieht, wird in Zeile 6 die Ersetzung nicht richtig ausgeführt, daher kommt dann auch der angezeigte Fehler in Zeile 17 (das "fi" in Zeile 8 ist wegen des fehlenden Endes der Zeichenkette in Zeile 6 nicht erkannt worden und in Zeile 17 tritt dann erst der nächste Syntaxfehler auf).

Im Ergebnis kann das "/var/install"-Skript dann die Version nicht mehr korrekt abfragen und da das dann auch (mit der "--install"-Option in Zeile 33) für die Erkennung der passenden Hardware genutzt wird, kommt am Ende dieses "WRONG_HARDWARE" dabei heraus. Ohne das "Downgrade" würde aber das Einspielen einer 07.01 von einer 07.10 aus wieder an der Versionsnummer scheitern, wenn man die "/var/install" nicht einfach mit "-d" aufruft.

Ansonsten sieht man noch, daß beim Aufruf von "/var/install" offenbar keine OEM-Variable im Environment gesetzt ist ... da das Skritpt dann die Prüfung des Brandings ausläßt, geht das sogar gut bei der Installation. Allerdings eröffnet es gleichzeitig wieder den Weg für neue Fehler ... denn wenn jemand eine "avme"-Firmware auf einem "avm"-Gerät installiert (ohne die notwendigen Anpassungen), dann kracht es beim nächsten Start garantiert. Da hat vermutlich auch schon seit Urzeiten niemand mehr einen genaueren Blick auf diese Installation geworfen (oder er kannte die Klippen nicht) ... da ich (mehrfach erwähnt) gar kein Freetz-GUI verwende, interessieren mich Probleme an dieser Stelle auch nur dann, wenn eine Lösung direkt ins Auge springt bzw. erkennbar mit wenig Aufwand zu finden ist.

Ich habe aber derzeit keinen Bock, das irgendwie in Freetz als Änderung vorzuschlagen - vor allem, weil das mit dem Wahren der Kompatibilität mit den älteren Versionen (noch bei der 07.01 sieht die "/etc/version" eben anders aus) wieder PITA wird. Du solltest also eine passende Issue im GitHub für dieses Problem eröffnen ... mal sehen, ob sich dann jemand der Sache annimmt (vielleicht packt es mich dann sogar, man weiß das ja nie so genau).

EDIT:

Warum tar noch zwei Versionen zurück ist weiß ich nicht

Ich habe mein eigenes Linux-System (openSuSE Tumbleweed) und da kann so ein Unterschied schon mal vorkommen ... was aber noch nicht erklärt, warum mein "expr"-Aufruf dann nicht funktioniert, wenn dort die Namen für den Benutzer und die Gruppe stehen und nicht die jeweiligen IDs.

 

[CaptainMorgan]

Ganz frech wäre natürlich wenn ich einfach nur ein Issue "Downgrade broken" aufmache und auf #91 verlinke.
------------------------------------------------------------------
Was OpenVPN angeht wird es jetzt skuril.
Jetzt funktioniert scheinbar alles, auch unter 7.10, außer den zusätzlichen Konfigurationen.
Sogar ein Tap Device mit der neuen cgi unter 7.10.
Ich kann es auch nicht wirklich erklären.
Wenn mir jemand sagt was ich machen kann um es für die Leute zu klären, bin ich gerne dazu bereit.
Ich bin fast versucht zu schauen ob jetzt vsftpd auf GRX Boxen klappt...

 

[PeterPawn]

Ganz frech wäre natürlich wenn ich einfach nur ein Issue "Downgrade broken" aufmache und auf #91 verlinke.

Absolut legitim ... ich will das nur nicht selbst machen, weil ich mich eben normalerweise nicht für das Freetz-GUI und die damit zusammenhängenden Probleme interessiere und daher auch (sofern ich es nicht selbst "bearbeiten" wollte) nichts weiter zur Lösung beitragen kann und erst recht nicht der Richtige bin, wenn es ums Testen von Änderungen im Rahmen dieses Problems geht.

 

[feedzapper]

Hm , um das Thema noch einmal aufzugreifen was openvpn angeht.
Irgendwie gehen bei mir auch merkwürdige Dinge von statten. Ich beobachte schon seit einiger Zeit einen ständigen Speicherschwund des /tmp/flash Speichers für die Freetz Konfig Dateien.
Eine nähere Betrachtung der Files dort führte zu dem Ergebnis, dass die /tmp/flash/users/passwd Datei ständig wächst und
mit folgendem Eintrag ständig geflutet wird :

root:x:0:0:root:/mod/root:/bin/sh
app63:$1$ewegzny$YX3wI.ZUxkJqsO7wrV.dC1:1100:0:box user:/home-not-used:/bin/sh
app63int:$1$qwranmo$YxKDrZyT9KgOerry656qj.:2100:0:box user:/home-not-used:/bin/sh
openvpn:x:101:1001:openvpn:/home/openvpn:/bin/false
app63:$1$vpoemdc$ZnimIoSkAJAdA1aO5aQ4D1:1100:0:box user:/home-not-used:/bin/sh
app63int:$1$crccmzu$AeC4IXKZII8EaV5g8T.fM1:2100:0:box user:/home-not-used:/bin/sh
app63:$1$sfxaklh$/SpUDW0czHfn/C1sjNmYP0:1100:0:box user:/home-not-used:/bin/sh
app63int:$1$ikdgqsh$R2ozJKw9sVlUUuYwhJ7z60:2100:0:box user:/home-not-used:/bin/sh
app63:$1$xyosxyo$8Z8xFGn8hyPxz47EIdY100:1100:0:box user:/home-not-used:/bin/sh
app63int:$1$hbpokxm$scHKjsGvufDimtd1eEskY1:2100:0:box user:/home-not-used:/bin/sh
nobody:x:100:1000:nobody:/home/nobody:/bin/false
openvpn:x:101:1001:openvpn:/home/openvpn:/bin/false
openvpn:x:101:1001:openvpn:/home/openvpn:/bin/false
openvpn:x:101:1001:openvpn:/home/openvpn:/bin/false
openvpn:x:101:1001:openvpn:/home/openvpn:/bin/false
openvpn:x:101:1001:openvpn:/home/openvpn:/bin/false
openvpn:x:101:1001:openvpn:/home/openvpn:/bin/false
openvpn:x:101:1001:openvpn:/home/openvpn:/bin/false
openvpn:x:101:1001:openvpn:/home/openvpn:/bin/false

Schreibt man die Freetz config über das WebGUI oder mit "modsave" in den Flash, ist der Freetz config Speicher dann irgendwann voll, weil die passwd Datei irgendwann RIESIG ist. Welcher Prozess schreibt da denn ständig diese Zeilen rein ?
Openvpn läuft ja hier wie bereits früher schon einmal erwähnt mit der NEUEN GUI.
In der Openvpn config, benutze ich die Einträge "user openvpn" und "group openvpn"
Diese hatte ich damals nur hinzugefügt weil sie in der "ALTEN GUI" config fest integriert waren.
Somit dachte ich sie wären nach wie vor erforderlich ....
Weiterhin ist auch der Pfad /home/openvpn ja überhaupt nicht existent ..
Werden die rechte überhaupt benötigt in der Openvpn config ? (user openvpn + group openvpn) ?
Adhoc habe ich "user openvpn und group openvpn" in der openvpn config zunächst erst einmal entfernt.
Nun scheinen auch die ständigen Einträge in die "passwd" zunächst gestoppt. Es scheint auch keine
negativen Auswirkungen auf den Betrieb von openvpn zu haben ...

 

[PeterPawn]

Ich denke mal, da stimmt irgendwas mit den Rechten für die "/etc/passwd" (bzw. der tatsächlichen Datei in "/var/tmp", weil unter "/etc" nur ein Symlink liegt) nicht ... auch die wiederholten Einträge für UID 1100 und 2100 sehen ja komisch aus und da hoffentlich jedes Programm vor dem Hinzufügen eines neuen Eintrags erst mal prüft, ob diese UID bereits in Benutzung ist, klappt da vermutlich das Auslesen schon nicht ... und zwar nicht nur für OpenVPN.

Ausgehend davon, daß da schon originale AVM-Einträge (die "appNN"-Einträge sind für über TR-064 eingerichtete Apps) doppelt auftreten und von den OpenVPN-Skripts nur "Freetz-Libraries" für den Zugriff auf diese Infos benutzt werden ("/usr/bin/modusers" und "/etc/init.d/modlibrc"), würde ich das Problem nicht direkt mit OpenVPN assoziieren, selbst wenn dessen "modlib_add_user_and_group openvpn" offenbar immer wieder aufgerufen wird - schon das sollte allerdings nicht passieren, wenn die Datei "/var/tmp/.openvpnfirstrun" angelegt und danach gefunden wird.

Es ist also auch denkbar, daß dem Benutzer, unter dem das "rc.openvpn" ausgeführt wird, ein paar Rechte fehlen (sonst sollte er diese Datei sowohl anlegen als auch später wiederfinden können) und damit auch den von dort gestarteten Kindsprozessen - eigentlich sollte das aber "root" sein? Die Angaben in der Konfigurationsdatei gelten ja erst dann, wenn der Daemon bereits läuft und seinerseits die "root"-Rechte droppt.

Das wirkt tatsächlich etwas komisch, aber ich würde - bis zum Beweis des Gegenteils jedenfalls - nicht irgendwo beim OpenVPN-Paket (auch nicht beim GUI) mit der Suche beginnen (wenn UID/GID des aufrufenden Prozesses erst mal geprüft wurden).

Die Untersuchung der Libraries (modusers + modlibrc) erscheint mir da erst einmal vielversprechender, denn da sollte spätestens das Hinzufügen doppelter Einträge geblockt werden (es gibt da ein "grep" nach dem Namen).

Angesichts der Tatsache, daß sich das originale Freetz und "freetz-ng" aber auch und gerade bei den Dateien, die den Freetz-Mod bilden, durchaus unterschiedlich entwickeln:

Files /tmp/trunk/make/mod/files/root/bin/onlinechanged.sh and /tmp/freetz/make/mod/files/root/bin/onlinechanged.sh differ
Files /tmp/trunk/make/mod/files/root/etc/default.avm/avm.cfg and /tmp/freetz/make/mod/files/root/etc/default.avm/avm.cfg differ
Files /tmp/trunk/make/mod/files/root/etc/default.mod/mod.cfg and /tmp/freetz/make/mod/files/root/etc/default.mod/mod.cfg differ
Files /tmp/trunk/make/mod/files/root/etc/default.mod/motd and /tmp/freetz/make/mod/files/root/etc/default.mod/motd differ
Files /tmp/trunk/make/mod/files/root/etc/init.d/modlibrc and /tmp/freetz/make/mod/files/root/etc/init.d/modlibrc differ
Files /tmp/trunk/make/mod/files/root/etc/init.d/rc.dsld and /tmp/freetz/make/mod/files/root/etc/init.d/rc.dsld differ
Files /tmp/trunk/make/mod/files/root/etc/init.d/rc.external and /tmp/freetz/make/mod/files/root/etc/init.d/rc.external differ
Files /tmp/trunk/make/mod/files/root/etc/init.d/rc.ftpd and /tmp/freetz/make/mod/files/root/etc/init.d/rc.ftpd differ
Files /tmp/trunk/make/mod/files/root/etc/init.d/rc.mod and /tmp/freetz/make/mod/files/root/etc/init.d/rc.mod differ
Files /tmp/trunk/make/mod/files/root/etc/init.d/rc.multid and /tmp/freetz/make/mod/files/root/etc/init.d/rc.multid differ
Files /tmp/trunk/make/mod/files/root/etc/init.d/rc.rextd and /tmp/freetz/make/mod/files/root/etc/init.d/rc.rextd differ
Files /tmp/trunk/make/mod/files/root/etc/init.d/rc.smbd and /tmp/freetz/make/mod/files/root/etc/init.d/rc.smbd differ
Files /tmp/trunk/make/mod/files/root/etc/inittab.shutdown and /tmp/freetz/make/mod/files/root/etc/inittab.shutdown differ
Files /tmp/trunk/make/mod/files/root/etc/services and /tmp/freetz/make/mod/files/root/etc/services differ
Files /tmp/trunk/make/mod/files/root/usr/bin/get_ip and /tmp/freetz/make/mod/files/root/usr/bin/get_ip differ
Files /tmp/trunk/make/mod/files/root/usr/bin/kernel_args and /tmp/freetz/make/mod/files/root/usr/bin/kernel_args differ
Files /tmp/trunk/make/mod/files/root/usr/bin/modsave and /tmp/freetz/make/mod/files/root/usr/bin/modsave differ
Files /tmp/trunk/make/mod/files/root/usr/bin/modusers and /tmp/freetz/make/mod/files/root/usr/bin/modusers differ
Files /tmp/trunk/make/mod/files/root/usr/bin/prepare-downgrade and /tmp/freetz/make/mod/files/root/usr/bin/prepare-downgrade differ
Files /tmp/trunk/make/mod/files/root/usr/bin/wrapper/rextd and /tmp/freetz/make/mod/files/root/usr/bin/wrapper/rextd differ
Files /tmp/trunk/make/mod/files/root/usr/lib/cgi-bin/conf.avm/20-multid.sh and /tmp/freetz/make/mod/files/root/usr/lib/cgi-bin/conf.avm/20-multid.sh differ
Files /tmp/trunk/make/mod/files/root/usr/lib/cgi-bin/conf.avm/20-websrv.sh and /tmp/freetz/make/mod/files/root/usr/lib/cgi-bin/conf.avm/20-websrv.sh differ
Files /tmp/trunk/make/mod/files/root/usr/lib/cgi-bin/conf.avm/30-websrv.sh and /tmp/freetz/make/mod/files/root/usr/lib/cgi-bin/conf.avm/30-websrv.sh differ
Files /tmp/trunk/make/mod/files/root/usr/lib/cgi-bin/mod/box_info.cgi and /tmp/freetz/make/mod/files/root/usr/lib/cgi-bin/mod/box_info.cgi differ
Files /tmp/trunk/make/mod/files/root/usr/lib/cgi-bin/mod/conf/40-external.sh and /tmp/freetz/make/mod/files/root/usr/lib/cgi-bin/mod/conf/40-external.sh differ
Files /tmp/trunk/make/mod/files/root/usr/lib/cgi-bin/mod/conf/70-get_ip.sh and /tmp/freetz/make/mod/files/root/usr/lib/cgi-bin/mod/conf/70-get_ip.sh differ
Files /tmp/trunk/make/mod/files/root/usr/lib/cgi-bin/mod/conf.webcfg/10-webcfg.sh and /tmp/freetz/make/mod/files/root/usr/lib/cgi-bin/mod/conf.webcfg/10-webcfg.sh differ
Files /tmp/trunk/make/mod/files/root/usr/lib/cgi-bin/mod/logs.cgi and /tmp/freetz/make/mod/files/root/usr/lib/cgi-bin/mod/logs.cgi differ
Files /tmp/trunk/make/mod/files/root/usr/lib/cgi-bin/mod/logs_avm.cgi and /tmp/freetz/make/mod/files/root/usr/lib/cgi-bin/mod/logs_avm.cgi differ
Files /tmp/trunk/make/mod/files/root/usr/lib/cgi-bin/mod/mounted.cgi and /tmp/freetz/make/mod/files/root/usr/lib/cgi-bin/mod/mounted.cgi differ
Files /tmp/trunk/make/mod/files/root/usr/lib/libmodmount.sh and /tmp/freetz/make/mod/files/root/usr/lib/libmodmount.sh differ
Files /tmp/trunk/make/mod/files/root/usr/lib/mod/cgi/page.sh and /tmp/freetz/make/mod/files/root/usr/lib/mod/cgi/page.sh differ
Files /tmp/trunk/make/mod/files/root/usr/lib/mod/reg-status and /tmp/freetz/make/mod/files/root/usr/lib/mod/reg-status differ
Files /tmp/trunk/make/mod/files/root/usr/lib/mww/cgi/help.sh and /tmp/freetz/make/mod/files/root/usr/lib/mww/cgi/help.sh differ
Files /tmp/trunk/make/mod/files/root/usr/lib/mww/do_update_handler.sh and /tmp/freetz/make/mod/files/root/usr/lib/mww/do_update_handler.sh differ
Files /tmp/trunk/make/mod/files/root/usr/lib/mww/page.d/file/handler.sh and /tmp/freetz/make/mod/files/root/usr/lib/mww/page.d/file/handler.sh differ
Files /tmp/trunk/make/mod/files/root/usr/mww/cgi-bin/exec.d/linux_fs_start.sh and /tmp/freetz/make/mod/files/root/usr/mww/cgi-bin/exec.d/linux_fs_start.sh differ
Files /tmp/trunk/make/mod/files/root/usr/mww/cgi-bin/freetz.cgi and /tmp/freetz/make/mod/files/root/usr/mww/cgi-bin/freetz.cgi differ
Files /tmp/trunk/make/mod/files/root/usr/mww/cgi-bin/system.cgi and /tmp/freetz/make/mod/files/root/usr/mww/cgi-bin/system.cgi differ
Files /tmp/trunk/make/mod/files/root/usr/mww/cgi-bin/system_lfs.cgi and /tmp/freetz/make/mod/files/root/usr/mww/cgi-bin/system_lfs.cgi differ
Files /tmp/trunk/make/mod/files/root/usr/mww/cgi-bin/update/firmware.cgi and /tmp/freetz/make/mod/files/root/usr/mww/cgi-bin/update/firmware.cgi differ
Files /tmp/trunk/make/mod/files/root/usr/share/images/cuma/edge_b.png and /tmp/freetz/make/mod/files/root/usr/share/images/cuma/edge_b.png differ
Files /tmp/trunk/make/mod/files/root/usr/share/images/cuma/edge_l.png and /tmp/freetz/make/mod/files/root/usr/share/images/cuma/edge_l.png differ
Files /tmp/trunk/make/mod/files/root/usr/share/images/cuma/edge_lb.png and /tmp/freetz/make/mod/files/root/usr/share/images/cuma/edge_lb.png differ
Files /tmp/trunk/make/mod/files/root/usr/share/images/cuma/edge_lt.png and /tmp/freetz/make/mod/files/root/usr/share/images/cuma/edge_lt.png differ
Files /tmp/trunk/make/mod/files/root/usr/share/images/cuma/edge_r.png and /tmp/freetz/make/mod/files/root/usr/share/images/cuma/edge_r.png differ
Files /tmp/trunk/make/mod/files/root/usr/share/images/cuma/edge_rb.png and /tmp/freetz/make/mod/files/root/usr/share/images/cuma/edge_rb.png differ
Files /tmp/trunk/make/mod/files/root/usr/share/images/cuma/edge_rt.png and /tmp/freetz/make/mod/files/root/usr/share/images/cuma/edge_rt.png differ
Files /tmp/trunk/make/mod/files/root/usr/share/images/cuma/edge_t.png and /tmp/freetz/make/mod/files/root/usr/share/images/cuma/edge_t.png differ
Files /tmp/trunk/make/mod/files/root/usr/share/skin/cuma/skin.sh and /tmp/freetz/make/mod/files/root/usr/share/skin/cuma/skin.sh differ
Files /tmp/trunk/make/mod/files/root/usr/share/skin/legacy/skin.sh and /tmp/freetz/make/mod/files/root/usr/share/skin/legacy/skin.sh differ
Files /tmp/trunk/make/mod/files/root/usr/share/skin/newfreetz/skin.sh and /tmp/freetz/make/mod/files/root/usr/share/skin/newfreetz/skin.sh differ
Files /tmp/trunk/make/mod/files/root/usr/share/skin/phoenix/skin.sh and /tmp/freetz/make/mod/files/root/usr/share/skin/phoenix/skin.sh differ
Files /tmp/trunk/make/mod/files/root/usr/share/style/cuma/base.css and /tmp/freetz/make/mod/files/root/usr/share/style/cuma/base.css differ
Files /tmp/trunk/make/mod/files/root/usr/share/style/mod/daemons.css and /tmp/freetz/make/mod/files/root/usr/share/style/mod/daemons.css differ

(das sind 55 Dateien, die sich alleine unter "make/mod/files" unterscheiden und das liegt nicht nur am anderen Namen des Projekts), solltest Du aber auch noch dazuschreiben, um welches Projekt es sich handelt.

Denn daraus leitet sich dann sicherlich auch ab, wer sich selbst "in der Verantwortung" sehen könnte, Dir bei der Fehlersuche zu helfen.

 

[feedzapper]

Ich habe im Moment "freetz-ng" rev 15673 am laufen.
Leider bin ich da auch erst einmal etwas überfordert im Moment, da ich auch nicht nachvollziehen kann, seitwann dieses Problem
hier auftritt b.z.w. evtl. ab welcher Freetz-ng Revision.
Es fiel mir irgendwie auch erst auf, als der verfügbare Speicher im laufenden Betrieb immer mehr schrumpfte.
(passwd unter /var/tmp) im RAM Speicher immer größer wurde und es irgendwann dann zu einem REBOOT wegen "Out of Memory" der Box kam...
Wie bereits im letzten Post beschrieben, war es dann zu einem bestimmten Zeitpunkt auch nicht mehr möglich die "passwd" Datei mit "modsave" fest ins flash nach /tmp/flash/users Schreiben zu lassen, weil der Flash Speicher nicht mehr ausreichte.

 

[feedzapper]

(das sind 55 Dateien, die sich alleine unter "make/mod/files" unterscheiden und das liegt nicht nur am anderen Namen des Projekts), solltest Du aber auch noch dazuschreiben, um welches Projekt es sich handelt.
Denn daraus leitet sich dann sicherlich auch ab, wer sich selbst "in der Verantwortung" sehen könnte, Dir bei der Fehlersuche zu helfen.

Das ganze müsste ja dann von hier aus seinen Ursprung nehmen, dass in die PASSWD Datei ständig diese Einträge erfolgen :

Auszug freetz-ng / 15673 :
/etc/init.d/rc.openvpn :

#!/bin/sh

scriptname=$0
CONF_ENABLED=OPENVPN_ENABLED
[ -z "$OPENVPN_ENABLED" ] && OPENVPN_ENABLED=no
DAEMON=${scriptname##*/rc.}
daemon="$(echo $DAEMON | tr [A-Z-] [a-z_])"
if [ $DAEMON == "openvpn" ]; then
        TITLE=OpenVPN
        keypath=/tmp/flash/openvpn/
else
        keypath=/tmp/flash/openvpn/${daemon}/
        TITLE=${2-$DAEMON}
fi

. /etc/init.d/modlibrc

mypidof() {
        ps -w | sed -n "/\/m[o]d\/etc\/${1}.conf/ s/^[ ]*\([0-9]*\)[ ].*/\1/ p"
}


if [ ! -e /var/tmp/.openvpnfirstrun ]; then
        touch /var/tmp/.openvpnfirstrun
        modlib_add_user_and_group openvpn
        if [ -e /tmp/flash/openvpn/configs ]; then
                for config in $(cat /tmp/flash/openvpn/configs); do
                        /mod/etc/default.openvpn/generate_virtual_pkg $config
                done
        fi
fi

[ -x /mod/sbin/$DAEMON ] || ln -s /usr/sbin/openvpn /mod/sbin/$DAEMON


config() {
        if [ "$OPENVPN_LOAD_TUN" == "yes" ]; then
                modprobe tun 2>/dev/null
                modprobe yf_patchkernel 2>/dev/null
        fi

        modlib_config
}


start() {
        modlib_startdaemon ${DAEMON} --config /mod/etc/${DAEMON}.conf --writepid /var/run/${DAEMON}.pid --daemon
}

stop() {
        echo -n "Stopping ${DAEMON} ... "
        PID=$(mypidof $DAEMON)

        if [ -z "$PID" ]; then
                echo "not running."
                return 1
        fi

        kill $PID > /dev/null 2>&1
        exitval=$?

        if [ "$exitval" -eq 0 ]; then
                echo 'done.'
        else
                echo 'failed.'
                exit $exitval
        fi

        rm -f /mod/etc/${daemon}.conf
        rm -f /var/run/${daemon}.pid
}

case $1 in
        ""|load)
                modreg cgi "${DAEMON}" "${TITLE-$DAEMON}"
                modreg daemon ${DAEMON}
                modreg file ${DAEMON} 'box_crt' 'Box Cert' 0 "box_crt"
                modreg file ${DAEMON} 'box_key' 'Private Key' 0 "box_key"
                modreg file ${DAEMON} 'ca_crt' 'CA Cert' 0 "ca_crt"
                modreg file ${DAEMON} 'crl_pem' 'CRL' 0 "crl_pem"
                modreg file ${DAEMON} 'dh_pem' 'DH Param' 0 "dh_pem"
                modreg file ${DAEMON} 'static_key' 'Static Key' 0 "static_key"
                modreg file ${DAEMON} 'script1' 'Script 1' 0 "script1"
                modreg file ${DAEMON} 'script2' 'Script 2' 0 "script2"
                modreg file ${DAEMON} 'script3' 'Script 3' 0 "script3"

                modlib_start "${OPENVPN_ENABLED}"
                ;;
        unload)
                stop
                modunreg file ${DAEMON}
                modunreg daemon ${DAEMON}
                modunreg cgi ${DAEMON}
                ;;
        start)
                modlib_start
                ;;
        stop)
                modlib_stop
                ;;
        restart)
                modlib_restart
                ;;
        reload)
                if [ -r "/var/run/${daemon}.pid" ]; then
                        kill -HUP $(cat /var/run/${daemon}.pid)
                fi
                ;;
        status)
                modlib_status
                ;;
        *)
                echo "Usage: $0 [load|unload|start|stop|restart|reload|status] [GUI-Title]" 1>&2
                exit 1
                ;;

esac

exit 0

Fürs erste habe ich die Einträge "user openvpn und group openvpn" aus der openvpn.diff entfernt. Damit ist die Flut der Einträge in die passwd zunächst gestoppt.

 

[feedzapper]

Funktioniert nun wieder alles - Danke !

Gefixxt in freetz-ng / 15692 ..
Fehler tritt/trat ab OS 7.10 auf !

https://trac.boxmatrix.info/freetz-ng/changeset/15692/freetz-ng

 

[CaptainMorgan]

EDIT: Vielleicht kann ja mal jemand bei AVM nach 07.10-Quellen fragen ... ich habe das Gefühl, daß meine Mails an "[email protected]" (das ist die Adresse, an die man sich wenden soll) eher im Spam-Filter hängenbleiben.

Weil meine Anfrage hier ihren Anfang genommen hat.
Eben kam tatsächlich eine Antwort.

.....
vielen Dank für Ihre Anfrage an den AVM Support.
Entschuldigen Sie vielmals die arg verspätete Antwort. Da scheint unser System einen Schluckauf gehabt zu haben.
Wir haben den Upload soeben gestartet. Im Verlaufe dieses Tages sollte die Datei (7.11) also hier zu finden sein:

https://osp.avm.de/fritzbox/fritzbox-7560/
....

Ob man den Schluckauf glaubt oder nicht, sei dahingestellt. Aber gemeldet haben sie sich noch, nach zwei Monaten, das will ich ihnen lassen.
Ich nehme an diese E-Mail werden heute noch mehrere bekommen die danach fragten, aber bevor es untergeht dachte ich ich leite es hier hin weiter.
Momentan ist noch nichts online, und 7.01 und 7.10 werden wohl übersprungen, aber die 7.11 wollen sie wohl im Laufe des Tages hochladen.