AVM-Watchdog - kann man den guten gewissen deaktivieren?

[PeterPawn]

Die Abfrage für "ds_off" kannst Du ja trotzdem vor den Aufruf von "/bin/busybox" setzen. Das "chmod" bräuchte es eigentlich auch nicht (das verhindert auch den direkten Aufruf, wenn man es wegläßt), weil bei dieser Form des Aufrufs sogar das SheBang (und die x-Flags) der "rc.mod" uninteressant sind.

Zumindest ist damit dann offensichtlich der Freetz-Start vom Start-Watchdog weg, wenn ich das richtig lese ... und wieviele Sekunden da noch übrig sind, spielt ja nicht die entscheidende Rolle, solange es nur genug sind, damit der "init"-Watchdog nicht zum Neustart führt. Zuviele sollten es halt auch nicht sein (AVM wird da schon getestet haben und die Zahlen haben garantiert schon von sich aus einen ausreichenden Sicherheitsaufschlag - auch bei den GRX-Boxen), damit bei "echten" Problemen und dem Hängenbleiben der Initialisierung ein Neustart nicht ewig braucht, bis er eingeleitet wird.

Wenn man die Ausgabe "live" auf "/dev/console" will, muß man halt am Beginn der "rc.mod" das schon erwähnte "tail -f ... &" anwerfen, das dann in ein "sed ... /var/log/mod.log > /dev/console" per Pipe die neu geschriebenen Zeilen in der "/var/log/mod.log" schubst und wo man die dann mit dem "sed" entsprechend umformen kann, damit da wieder das mit dem "[...] RCMOD:" davor ausgegeben wird - wie schon erwähnt, kann man dann auch gleich ANSI-Sequenzen für diesen "Zeilenbeginn" verwenden und den einfärben, so daß man ihn (wenn man die Ausgaben auf "/dev/console" live sieht) auf Anhieb zwischen den ganzen anderen Zeilen findet. Das "tail" kann man dann am Ende der "rc.mod" wieder abräumen oder man läßt es sogar durchlaufen - falls noch andere Prozesse diese "/var/log/mod.log" als (einziges) Ziel benutzen, wird das auch weiterhin entsprechend ausgegeben.

Den Zusammenhang zum "untrustedd" sehe ich da aber auch nicht ... vor allem erklärt mir das noch nicht, warum der (nach dem, was ich dazu bisher gelesen habe) nur bei Boxen mit GRX-Chipset abstürzen sollte und z.B. auf der 7490 problemlos läuft - offenbar ja auch dann, wenn da ein Freetz-NG-Image im Einsatz ist. Da bleibe ich - bis zum Beweis des Gegenteils, daß das auch mit AVM-Werkseinstellungen noch auftritt - erst einmal bei der Vermutung, daß es mit irgendwelchen Mesh-Diensten und/oder anderen Geräten zusammenhängt und ggf. sogar mit der originalen Firmware in diesen Fällen (deren genaue Umstände man dann eben herausarbeiten müßte) auftreten würde.

 

[fda89]

Auf meiner 7590 lief der untrustedd 2 Wochen ohne Absturz, nicht wie bei joker. Er hat aber scheinbar viel user-cpu verbraucht seit 7.20, wie ich in rrdstats sehe. Die 2 asec Dateien sind bei mir leer, auch auf der 7490. Es wurde aber wohl der watchdog getriggert, da der untrusredd nicht mir dem fertig wurde was er versuchte beim Start.

Werkseinstellungen bedeuten, dass ich alle Dect und Mesh Geräte neuverbinden muss, ich glaub das ist nicht im Export

Das Loggen könnte man in die rc.mod wie bei external in der log() machen, dann würde aber jeder Aufruf geloggt, nicht nur der Systemstart. Ich glaub deshalb hatte ich das deshalb so gemacht.
Wie wäre es so?

--- patches/scripts/115-patch-ds_off.sh
+++ patches/scripts/115-patch-ds_off.sh
@@ -12,7 +12,7 @@ fi

 # Emergency stop switch for execution of Freetz as a whole
 [ ! -e "$dsfile" ] && echo '#!/bin/sh' > "$dsfile" && echo1 "adding ${dsfile#$FILESYSTEM_MOD_DIR}"
-echo '[ "$ds_off" == "y" ] || . /etc/init.d/rc.mod 2>&1 | tee /var/log/mod.log | sed "s/^/[FREETZ] RCMOD: /g"' >> "$dsfile"
+echo '[ "$ds_off" == "y" ] || nohup /etc/init.d/rc.mod 2>&1 </dev/null | tee /var/log/mod.log | sed "s/^/[FREETZ] RCMOD: /g" &' >> "$dsfile"
 chmod +x "$dsfile"

Das "sh" hatte ich drin gelassen, da es vorher mit "." gesourced wurde. Vielleicht ist es überflüssig, vielleicht hatte es auch einen Grund...? Eine Änderung würde Auswirkungen auch auf die uralten Geräte haben

Wenn man die Console einfärbt, solle man es gleich für die alle Scripte machen

 

[olistudent]

Vermutlich wird doch die rc.mod genau aus dem Grund Watchdog gesourced? So dass die Box neu startet, wenn einer der Freetz-Dienste beim Start hängen bleibt.

Ich kann mich aber auch nicht mehr richtig daran erinnern, wie das mit den Zombie-Prozessen und der rc.custom (oder war es die debug.cfg) war? Hier wurden ja teilweise Prozesse gekillt, obwohl sie geforkt wurden!? Hat das hiermit überhaupt was zu tun? Vielleicht sollte ich den Thread auch mal lesen...

Gruß,
Oliver

 

[fda89]

Es ist noch nicht bekannt weshalb der untrustedd den watchdog auslöst der rebootet. Aktuell wird der eine entfernt oder der andere deaktiviert. Aber das Problem der 7590 dürfte mit dem Start von rcmod nichts zu tun haben. Am Anfang dieses Threads war aber noch nicht ganz klar warum der watchdog rebootet.
Durch Sourcen wird der Prozesss nicht im Hintergrund gestartet, sondern zB nachfolgende Befehle können Funktionen aus rc.mod verwenden. Die Zeit die das Starten vom mod inklusiver aller installierter Packages braucht verringert die Zeit die der Watchdig maximal der Box zum Booten erlaubt (2 oder 4 Minuten), so wie es aktuell und schon lange ist.
An die Zombies hab ich nur noch ganz dunkle Erinnerungen, eigentlich mag ich am Startprozess nichts ändern
@PeterPawn: Einwände gegen #83 ?

 

[PeterPawn]

@fda89:
Die Änderung kann man halt nicht erkennen - daher ist sie mir auch weder aufgefallen, noch habe ich damit gerechnet.

Wenn "nohup" sicher existiert (auch ohne daß die BusyBox mit "prefer applets" erzeugt wurde und "nohup" in den "required applets" enthalten ist - AVM hat m.W. dafür mittlerweile das eigene "detach" in der Firmware und könnte "nohup" aus der eigenen BusyBox werfen) und das mit dem "tee" + "sed" auch sauber arbeitet, sollte die "Idee" stimmen - soweit ich das beurteilen kann.

Angesichts der Konfigurationsoptionen in Freetz würde ich halt explizit (so, wie ich es auch mache, wobei ich zusätzlich nicht zwingend davon ausgehen kann, daß eine eigene BusyBox verwendet wird und mich auch darauf verlasse, daß AVM das "nohup" nicht ausbaut - aber gleichzeitig auch dafür sorge, daß ein fehlender Symlink für "/bin/nohup" nicht zum entscheidenden Problem wird, was man bei Freetz natürlich gleich passend korrigieren kann) die BusyBox aufrufen und ob man da dann noch ein "sh" davor setzt oder sich auf das "x"-Flag der Datei und den richtigen SheBang verläßt, ist wohl auch eher Geschmackssache. Solange das Verzeichnis ohnehin nicht im Suchpfad steht, spielt es auch (fast) keine Geige, ob das ohne das "sh" davor aufgerufen werden kann (nur dafür sorgt das "chmod" da ja noch) oder nicht.

Da ist noch ein Punkt, wo ich nicht vollkommen sicher bin, ob das mit dieser Pipeline aus drei Programmen auch tatsächlich so funktioniert, wie man das zunächst mal vermuten würde. Denn eigentlich wird hier nur die "rc.mod" mit dem "nohup" gestartet (denke ich zumindest, müßte ich auch erst prüfen für Gewißheit) und die anderen Prozesse in der Pipeline "erben" gar nicht die File-Deskriptoren des ersten Prozesses in der Pipeline (außer natürlich jeweils auf STDIN, wo sie STDOUT ihres Vorgängers vorgesetzt bekommen), sondern (wie gesagt: vermutlich) zumindest für STDERR auch den von der Instanz, die gerade die "99-zzz-rcmod" abarbeitet und der eigentlich am Ende des Skripts geschlossen werden müßte.

Wie gesagt - ich würde es erst mal testen. Eine Schleife von 10 Minuten in der "rc.custom", die eine weitere Abarbeitung der "rc.mod" aufschiebt (und diese damit nicht schnell zum Ende kommen läßt), ist zum Test der "richtigen Entkopplung" ja schnell eingebaut - rein theoretisch sollten die anderen zwei Programme in der Pipeline auch (wenn sie erst einmal laufen) nichts mehr nach STDERR ausgeben wollen, wenn das "tee" irgendwann ein sauberes EOF beim Lesen kriegt.

Ob und wie sich die Abarbeitung der "99-zzz-rcmod" auch dann sauber beendet (das ist ja das Signal, welches der "supervisor" hier kriegen soll), wenn da noch zwei Kindprozesse ausstehen (bzw. ob die Parallelisierung (&) da tatsächlich die gesamte Pipeline vom "controlling terminal" abkoppelt, wenn der erste Prozess ein "nohup" ist - was ich eher nicht erwarte), muß man halt testen (oder sehr genau nachsehen/nachlesen, wobei das hier bis in die Kernel-Sourcen bzw. bis ins "init" gehen würde, wo die beendeten Prozesse abgeräumt werden). Aus dem Kopf weiß ich es jedenfalls auch nicht definitiv genug, um da zu sagen, daß das so nicht funktioniert - auch wenn ich leichte Zweifel habe.

Das kann vom Warten auf das Ende der beiden "children" bis zum Abbruch für diese reichen, wenn das Ende der "99-zzz-rcmod" erreicht ist ... und ein Abbruch in der Pipeline könnte auch wieder einen Abbruch für den mit "nohup" gestarteten Prozess bedeuten (oder irgendwann dessen Warten auf das Leeren der Buffer seines STDOUT-Deskriptors, wobei ein SIGPIPE wohl auch einen per "nohup" gestarteten Prozess beenden sollte), wenn die "sink" für STDOUT abhanden gekommen ist, weil das "tee" abgewürgt wurde.

EDIT:
Wenn sich Freetz tatsächlich dagegen absichern will, daß irgendwelche Prozesse hängenbleiben, dann sollte das mit eigenen Watchdogs realisiert werden. Wie das geht, kann man sich in den OSS-Paketen von AVM ansehen (irgendwo war da auch ein Programm zum Testen der Watchdog-Funktionen dabei, das man dann lesen kann) - notfalls setzt man ein eigenes Programm ein, was (am besten dann auch optional) den "init"-Watchdog von AVM nacherfindet, am Beginn der "rc.mod" (parallel) gestartet wird und - wenn es normal beendet wird am Ende der Freetz-Initialisierung - den Watchdog-Timer sauber abräumt.

Ich würde jedenfalls nicht sagen, daß ein Problem beim Start von Freetz (oder eines dort gestarteten Services - erst recht nicht ein "Benutzer-Fehler" in der "rc.custom" oder der "debug.cfg", wenn letztere unterstützt ist, der den Start verzögert oder sogar danach liegende Teile komplett blockiert, weil es gar nicht weiter geht) die Box in eine Boot-Schleife schicken sollte - da finden die wenigsten Benutzer dann von alleine wieder raus.

 

[olistudent]

Und der Crash vom untrustedd passiert nur, wenn rc.mod geladen wird? Nicht dass es an OpenSSL liegt?

root@FritzBox7490:/usr/bin$ ldd /usr/bin/untrustedd
        libwdt.so.1 => /lib//libwdt.so.1 (0x7725d000)
        libasecutils.so => /usr/lib//libasecutils.so (0x7721e000)
        libminneapolis.so => /usr/lib//libminneapolis.so (0x77203000)
        libatomic.so.1 => /lib//libatomic.so.1 (0x771ee000)
        libbacktrace.so.1 => /lib//libbacktrace.so.1 (0x771d3000)
        libsvctl.so => /lib//libsvctl.so (0x771c1000)
        liburcu.so.6 => /usr/lib//liburcu.so.6 (0x771a9000)
        liburcu-common.so.6 => /usr/lib//liburcu-common.so.6 (0x77195000)
        libz.so.1 => /usr/lib//libz.so.1 (0x77170000)
        libcrypto.so => /lib//libcrypto.so (0x7701d000)
        libc.so.0 => /lib//libc.so.0 (0x76f1c000)
        ld-uClibc.so.1 => /lib/ld-uClibc.so.0 (0x77270000)

 

[PeterPawn]

Das ist ja eher kein Crash, sondern ein Timeout eines abgelaufenen Watchdogs.

Die von "untrustedd" verwendete "asecdb" (ich vermute mal, daß das der Inhalt des TFFS-Node 240 ist, vielleicht ist es aber auch nur der Speicher für einen einmal generierten Key) braucht aber u.U. eine Menge Entropie (oder "Zufall") bei der Initialisierung (das kann man in "eip123/char.c" einigermaßen sehen) und ich weiß nicht, ob das nur einmalig (quasi zum Erstellen der DB-Strukturen) der Fall ist oder da bei jedem Booten auch ein neuer Key abgeleitet werden soll, der von diesem Moment an dann verwendet wird.

Auch dessen Zweck ist ja nur geraten, aber es wäre zumindest logisch, wenn da Daten, die von anderen Geräten im LAN eingesammelt wurden, nicht einfach nur "plain" gespeichert sind, sondern etwas besser gesichert werden. Einiges bei dieser "derive_asecdbkey()"-Funktion ist ja auch statisch in den Quelltext-Dateien abgelegt - daher würde ich eher auf einmalige Initialisierung tippen ... und die ist bei dem einen ggf. schon durch die "plain firmware" von AVM erledigt, wenn das erste Freetz-Image da aufgespielt wird und bei anderen nicht.

Auf alle Fälle könnte das auch erklären, warum das Phänomen bisher wohl nur bei GRX-Boxen beobachtet wurde - die anderen haben schlicht den HW-RNG nicht und müssen die Entropie irgendwie anders erzeugen (und nehmen ggf. auch schlechtere Werte in Kauf). Ich bin auch noch nicht komplett durch die AVM-Quellen durch - aber wenn da "/dev/random" (das ja dann blockiert, wenn nicht genug Entropie verfügbar ist - eine Abfrage über "/proc/sys/kernel/random/entropy_avail" kann man ja auch mal machen (lassen) - AVM wartet beim Start ja, bis mind. 896 Bit Entropie verfügbar sind) von Freetz ausgelesen/benutzt wird (bzw. von einem dort gestarteten Service) und damit für den "untrustedd" nicht rechtzeitig genug wieder ausreichend (echte) Entropie erzeugt werden kann, dann könnte das natürlich auch zu einem zu langen Warten führen.

Ob beim Freetz-Start (auch mit einem Minimal-Image, denn da tritt das ja auch auf, afaik) jetzt irgendwelche Entropie "verbraucht" wird, weiß ich nicht - in Frage kommt da aber sicherlich einiges und im schlechtesten Fall sorgt schon die andere BusyBox-Version durch ein Lesen aus "/dev/urandom" beim Start der ersten Instanz dafür, daß die "echte Entropie" auch erschöpft wird. Denn m.W. greift auch "/dev/urandom - was z.B. in der BusyBox verwendet wird, um UUIDs zu generieren und dabei 16 Byte = 128 Bit schon mal bräuchte - erst mal auf denselben Entropie-Pool wie "/dev/random" zu und liefert erst dann "schlechtere Werte", wenn die Entropie nicht ausreicht und trotzdem "non-blocking behavior" gefordert ist.

Deshalb ja die in diesem Thread auch mehrfach aufgeworfene Fragestellung, ob das mit der originalen Firmware auch auftritt - ist das tatsächlich eine einmalige Initialisierung (bzw. wird nur bei "leerer" "asecdb" ausgeführt, was natürlich auch nach einem Werksreset der Fall wäre), kann es schon ausreichen, da einfach mal mit einer AVM-Firmware (allerdings auch einer passenden Version) die Box zu starten, damit das erst mal abgehakt ist und beim nächsten Versuch mit Freetz nicht erneut erforderlich wird (so die Theorie "einmalig" korrekt sein sollte).

Das wäre zumindest auch eine (für mich sogar plausible) Theorie, die sowohl die Abhängigkeit von Freetz als auch vom GRX5-Chipset mit dem RNG in Hardware erklären könnte - oder sie liegt auch (wie das nun mal für jede Theorie vor ihrem Beweis gilt) vollkommen daneben.

Eine Option zum Test wäre es hier, daß man regelmäßig die verfügbare Entropie (s.o.) protokolliert und prüft, ob das bei AVM-Firmware und Freetz unterschiedliche Werte ergibt. Dafür reicht ja schon ein (asynchrones) "logger", wenn man das Syslog "nach außen" legt und die Info auf einem anderen System so lange erhält, bis da der "untrustedd" doch noch den Watchdog triggern läßt. Allerdings muß dazu natürlich auch das Entfernen des "untrustedd" wieder optional sein - wobei der Einbau der notwendigen Ausgaben zur Kontrolle ohnehin eine Änderung am Image braucht und wohl nicht erst in der "rc.custom" zur Laufzeit erfolgen kann, weil es da schon zu spät sein dürfte, um noch Infos für den "echten Beginn" der Initialisierung zu erhalten.

Die Initialisierung der RNG-Hardware (die steht zu Beginn vermutlich noch unter Kontrolle des "bootcore"-Kernels) erfolgt bei AVM jedenfalls schon in der "/etc/boot.d/core/head" - von diesem Zeitpunkt an sollte dann am besten auch die Protokollierung der verfügbaren Entropie bereits laufen und z.B. jede Sekunde einmal abfragen und das - per "showshringbuf" - in einen Ring-Puffer schreiben ... dafür braucht's kein Netzwerk o.ä. und wenn das Netzwerk später erst mal gestartet wurde, kann man zuerst den Ringbuffer-Inhalt an die (externe) Senke übertragen und danach anstelle des "showshringbuf" direkt auch die Ausgabe nach extern verwenden. Das alles braucht natürlich (damit es läuft) dann jemanden, der sich damit einigermaßen auskennt und das (unfallfrei) in ein Freetz-Image einbauen kann.

Und das alles nur für die Überprüfung dieser einen Theorie ... da muß die jemandem schon plausibel genug erscheinen, damit er das Vorhaben in Angriff nimmt.

 

[fda89]

@PeterPawn nuhup ist "mandatory" in die Freetz-Busybox, also immer verfügbar

in rc.custom:

echo "SLEEP S: $(date)" >/dev/console
for x in 1 2 3 4 5; do
sleep 60
echo "SLEEP60: $(date)" >/dev/console
done
echo "SLEEP E: $(date)" >/dev/console

Mit den Pipes kenn ich mich nicht so gut aus, der Watchdog (4m) wird nicht getriggert. Allerdings stimmt die Reihenfolge der Logausgaben nicht, der rc.custom Aufruf wird erst viel später geloggt. Damit ist das nicht so optimal.
Nebenbei werden durch eine sehr langsame rc.custom onlinechanged & external verzögert da diese erst nach rc.mod starten dürfen.

[FREETZ] RCMOD: Freetz version ng-C17419-046614da7
2020-11-17 17:32:23 voipd[3665]: ready (2sec)
[Supervisor] Info: voip.service exit success
[Supervisor] Info: start voipkpid.service
[Supervisor] Info: voipkpid.service exit success
[Supervisor] Info: all Services loaded.
[Supervisor] Info: spindown.service exit success
[FREETZ] RCMOD: Starting Crond ... done.
[FREETZ] RCMOD: WebCFG is updating inetd ... active.
[FREETZ] RCMOD: Starting Syslogd ... done.
[FREETZ] RCMOD: Starting Inetd ... done.
[FREETZ] RCMOD: Setting up SSH authorized-keys for root ... done.
[FREETZ] UDEVMOUNT: /dev/sda1 - mounting started
[FREETZ] RCMOD: Setting up CA-bundle ... done.
MOUNT: partition type is: 0xc
Mounting [STICK] to device /dev/sda1...
MOUNT: use blkid to get device /dev/sda1 data
MOUNT: filesystem type is: ext3
MOUNT:mount -t 'extX' /dev/sda1 /var/media/ftp/STICK
grep: /var/tmp/medialabels: No such file or directory
[FREETZ] UDEVMOUNT: /dev/sda1 - mounted as /var/media/ftp/STICK (ext3)
[FREETZ] EXTERNAL: Starting external (/var/media/ftp/STICK/.ext):
[FREETZ] EXTERNAL: Waiting for mod-startup:
[FREETZ] RCMOD: Dropbear is updating inetd ... active.
[FREETZ] RCMOD: Starting AutoFS ... done.
[FREETZ] RCMOD: Starting Samba-nmbd ... done.
[FREETZ] RCMOD: Samba-smbd is updating inetd ... active.
SLEEP S: Tue Nov 17 17:32:32 CET 2020                             <<<<<<<<
[LIB_DSL_UTILS SYS][ERR]timeout
SLEEP60: Tue Nov 17 17:33:32 CET 2020
telefon: SIGCHLD PID 5624 received!
psetd: Error: Could not send KPIs via avmipc_msg_send()
telefon: SIGCHLD PID 5625 received!
SLEEP60: Tue Nov 17 17:34:32 CET 2020
SLEEP60: Tue Nov 17 17:35:32 CET 2020
SLEEP60: Tue Nov 17 17:36:32 CET 2020
SLEEP60: Tue Nov 17 17:37:32 CET 2020
SLEEP E: Tue Nov 17 17:37:32 CET 2020
[FREETZ] RCMOD: Vsftpd will be started by external.
[FREETZ] RCMOD: Starting rc.custom ... done.                      <<<<<<<<
[FREETZ] RCMOD: Startup finished.
[FREETZ] ONLINECHANGED[2908]: [online] approved
[FREETZ] ONLINECHANGED[2908]: [online] executing /etc/onlinechanged/00-get_ip
[FREETZ] ONLINECHANGED[2908]: [online] executing /etc/onlinechanged/vsftpd
[FREETZ] ONLINECHANGED[2908]: [online] finished
[FREETZ] EXTERNAL: done.
[FREETZ] EXTERNAL: Waiting for time-synchronisation:
[FREETZ] EXTERNAL: done.
[FREETZ] EXTERNAL: Vsftpd is updating inetd ... active.
[FREETZ] EXTERNAL: Starting external finished.

@olistudent openssl wird schon lange nicht mehr ersetzt, das hatte ER noch gemacht. Avm nutzt mittlerweile auch musl+glibc (nicht für die 7490). In NG werden die auch nicht mehr ersetzt

$ ldd $(which wget)
        librt.so.1 => /usr/lib/freetz/librt.so.1 (0x778e0000)
        libssl.so.1.0.0 => /usr/lib/freetz/libssl.so.1.0.0 (0x7787c000)
        libcrypto.so.1.0.0 => /usr/lib/freetz/libcrypto.so.1.0.0 (0x776e9000)
        libc.so.1 => /usr/lib/freetz/libc.so.1 (0x77660000)
        ld-uClibc.so.1 => /usr/lib/freetz/ld-uClibc.so.1 (0x778f6000)
        libpthread.so.1 => /usr/lib/freetz/libpthread.so.1 (0x77638000)
        libdl.so.1 => /usr/lib/freetz/libdl.so.1 (0x77624000)

@PeterPawn: Ich hab die 7490 zum testen genommen und dort ein avm-image geflasht. So kann ich einfach über der Console nachschauen

# uptime
 17:47:47 up 5 min,  load average: 1.21, 1.23, 0.60

# cat "/proc/sys/kernel/random/entropy_avail"
218

# wc /var/flash/*asec*
        0         0         0 /var/flash/asec
        0         0         0 /var/flash/import_asec.tmp
        0         0         0 total

 

[PeterPawn]

Solange der "init"-Watchdog vom "supervisor" abgeschaltet wird, ist es ja in Ordnung und das:

[Supervisor] Info: all Services loaded.

zeigt ja, daß das der Fall war (zumindest sollte das nach bisherigem Kenntnisstand so sein).

Dann kannst Du das mit dem generellen Abschalten aller Watchdogs ja abhaken - bleibt die Aufgabe, das Problem einzugrenzen, warum der "untrustedd" genau abstürzt und was man dagegen tun kann, außer den gleich komplett zu entfernen. Denn aus Platzgründen macht das eher wenig Sinn (daher kann da auch keine NOR-Box mit engem Flash als Grund herhalten) und solange man nicht genau weiß, was der eigentlich macht, sollte man ihn vielleicht nicht unbedingt entfernen - am Ende hat sich jemand bei AVM noch etwas dabei gedacht, als die das gebaut haben (selbst wenn wir momentan noch zu blöd sind, die Absicht dahinter genau zu erkennen).

Einen möglichen (und meinen im Moment klar präferierten) Ansatz für weitere Überlegungen hatte ich ja oben dargelegt - mal sehen, wann da jemand tätig wird beim Testen und wer das dann sein wird. Der Teil mit dem "init"-Watchdog wäre für mich jedenfalls (und ich hoffe mal, auch für Dich) erledigt - nur müßte das dann auch den Weg ins GitHub-Repo (und ggf. in die ganzen anderen) finden.

Ob man die Suche nach dem "untrustedd"-Problem jetzt in diesem Thread weiter betreibt (wo dann der Titel nicht mehr so ganz paßt) oder den doch besser in einen neuen auslagert, von dem man ja auch hierher verlinken kann, will/kann ich nicht entscheiden - ich hätte nur die Präferenz, das in einem neuen zu machen, weil Seite 5 schon wieder "viel Lesestoff" ist und die Heulerei, daß man da nichts finden kann, dann wieder losgeht.

 

[fda89]

Ich denke so rund läuft das aber nicht mit dem rcmod start, da die obere mit <<<<<< markierte Zeile unter der unteren markierten in der Console stehen sollten
Meine 7590 ist mit remove-untrustedd geflash

 

[PeterPawn]

Wie soll das gehen? Spätestens das "sed" arbeitet dann wieder zeilenorientiert und solange da kein "\n" in der Pipe auftaucht, ist die Zeile nicht komplett - mithin wird die auch nicht ausgegeben bzw. "verarbeitet" vom "sed". Dann mußt Du schon die Ausgabe passend zu den Erwartungen machen ... denn das gilt für alles vor der 07.19 ebenso - nur hat das vermutlich bis dahin keiner mit einer solchen "Verzögerungsschleife" getestet und/oder dabei auf die Ausgaben und ihre Reihenfolge geachtet.

 

[fda89]

Ach, das war vorher auch nicht optimal. Komisch dass vsftpd erst nach rc.custom geloggt wird.

Hier noch zum Vergleich ohne Patch: (der Stick ist uralt und wird nicht immer erkannt)

2020-11-18 00:21:40 voipd[3324]: ready (5sec)
[Supervisor] Info: voip.service exit success
[Supervisor] Info: start voipkpid.service
[Supervisor] Info: voipkpid.service exit success
[FREETZ] RCMOD: Starting Crond ... done.
[FREETZ] RCMOD: WebCFG is updating inetd ... active.
[FREETZ] RCMOD: Starting Syslogd ... done.
[FREETZ] RCMOD: Starting Inetd ... done.
[FREETZ] RCMOD: Setting up SSH authorized-keys for root ... done.
[FREETZ] RCMOD: Setting up CA-bundle ... done.
[FREETZ] RCMOD: Dropbear is updating inetd ... active.
[FREETZ] RCMOD: Starting AutoFS ... done.
[FREETZ] RCMOD: Starting Samba-nmbd ... done.
[FREETZ] RCMOD: Samba-smbd is updating inetd ... active.
SLEEP S: Wed Nov 18 00:21:48 CET 2020
[LIB_DSL_UTILS SYS][ERR]timeout
SLEEP60: Wed Nov 18 00:22:48 CET 2020
telefon: SIGCHLD PID 5056 received!
psetd: Error: Could not send KPIs via avmipc_msg_send()
telefon: SIGCHLD PID 5057 received!
SLEEP60: Wed Nov 18 00:23:48 CET 2020
SLEEP60: Wed Nov 18 00:24:48 CET 2020
[  256.480000][1]Kernel panic - not syncing: ar7wdt_hw_reboot: init sequence hangs !
[  256.480000][1]
[  256.480000][1]set_reboot_status: Soft-Reboot(PANIC)  - PANIC(1)SUM(1)UP(256)UTC(1605655489)FW(07.21)HW(185)HWS(1)BV(1.1777)

Ohne Patch und ohne Warteschleife

2020-11-18 00:38:49 voipd[3877]: ready (2sec)
[Supervisor] Info: voip.service exit success
[Supervisor] Info: start voipkpid.service
[Supervisor] Info: voipkpid.service exit success
[Supervisor] Info: spindown.service exit success
[FREETZ] RCMOD: Starting Crond ... done.
[FREETZ] RCMOD: WebCFG is updating inetd ... active.
[FREETZ] RCMOD: Starting Syslogd ... done.
[FREETZ] UDEVMOUNT: /dev/sda1 - mounting started
MOUNT: partition type is: 0xc
[FREETZ] RCMOD: Starting Inetd ... done.
[FREETZ] RCMOD: Setting up SSH authorized-keys for root ... done.
Mounting [STICK] to device /dev/sda1...
MOUNT: use blkid to get device /dev/sda1 data
MOUNT: filesystem type is: ext3
MOUNT:mount -t 'extX' /dev/sda1 /var/media/ftp/STICK
grep: /var/tmp/medialabels: No such file or directory
[FREETZ] UDEVMOUNT: /dev/sda1 - mounted as /var/media/ftp/STICK (ext3)
[FREETZ] EXTERNAL: Starting external (/var/media/ftp/STICK/.ext):
[FREETZ] RCMOD: Setting up CA-bundle ... done.
[FREETZ] EXTERNAL: Waiting for mod-startup:
[FREETZ] RCMOD: Dropbear is updating inetd ... active.
[FREETZ] RCMOD: Starting AutoFS ... done.
[FREETZ] RCMOD: Starting Samba-nmbd ... done.
[FREETZ] RCMOD: Samba-smbd is updating inetd ... active.
[FREETZ] RCMOD: Vsftpd will be started by external.
[FREETZ] ONLINECHANGED[2947]: [online] approved
[FREETZ] ONLINECHANGED[2947]: [online] executing /etc/onlinechanged/00-get_ip
[FREETZ] ONLINECHANGED[2947]: [online] executing /etc/onlinechanged/vsftpd
[FREETZ] ONLINECHANGED[2947]: [online] finished
[FREETZ] EXTERNAL: done.
[FREETZ] EXTERNAL: Waiting for time-synchronisation:
[FREETZ] EXTERNAL: done.
[FREETZ] RCMOD: Starting rc.custom ... done.
[FREETZ] RCMOD: Startup finished.
[Supervisor] Info: rcmod.service exit success
[Supervisor] Info: all Services loaded.
[FREETZ] EXTERNAL: Vsftpd is updating inetd ... active.
[FREETZ] EXTERNAL: Starting external finished.
[LIB_DSL_UTILS SYS][ERR]timeout

 

[PeterPawn]

Ach, das war vorher auch nicht optimal. Komisch dass vsftpd erst nach rc.custom geloggt wird.

Ist das jetzt eine reine Feststellung oder ein Widerspruch gegen die meine? Daß der erste Teil (das "echo -n ...") auch ohne Patch nicht geloggt wird (bevor dann der Abbruch durch den Watchdog kommt), ist ja auch klar zu sehen - erst das "echo done" nach der Ausführung sendet dann auch das Zeilenende mit und dann schreibt das "sed" die Zeile in die Ausgabe.

Der Start des "vsftpd" dürfte am "onlinechanged" und an "external" hängen (also von denen abhängig sein, nicht "irgendwas verzögern"), wenn ich das Protokoll richtig lese.

Wobei ich jetzt nicht mehr durchblicke ... im Teil "Ohne Patch und ohne Warteschleife" sieht es komisch aus, wenn (a) schon eine Uhrzeit gesetzt ist (die sollte ja erst vom NTP-Server kommen - wenn hier ein lokaler verwendet wird, solltest Du das dazuschreiben, weil es sonst eben Unklarheiten gibt) und (b) erst eine Weile später (und zwar eine "gute Weile" später) ein "onlinechange" auftritt.

Hier wäre es dann halt auch interessant zu wissen, wie lange die Initialisierung bis zum "all Services loaded" gedauert hat - wenn das eine 7590 sein sollte und da die 120 Sekunden eingestellt sein sollten, könnte das ja wieder etwas eng werden - mal abgesehen davon, daß man nicht vorhersagen kann, wie lange die "rc.custom" braucht und ob die rechtzeitig fertig wird - egal, wie lang das Timeout für den "init"-Watchdog gesetzt wurde.

Da kann der Benutzer jederzeit "Sch***e bauen" mit eigenen Kommandos und deshalb sollte man ohnehin die "rc.custom" generell ebenfalls vom Geschehen in der "rc.mod" abhängen - ggf. noch mit einer Option (im GUI zur Runtime, wenn man die Kommandos in der "rc.custom" editieren kann), die "rc.custom" doch synchron auszuführen.

Wobei das selten etwas bringen dürfte - das ist praktisch am Ende der "rc.mod" und alles andere, was wichtig sein könnte, wurde zuvor schon gestartet. Da gibt es also auch selten Notwendigkeiten (und Möglichkeiten), etwas mit anderen Freetz-Paketen zu synchronisieren und dann kann man das auch gleich "richtig asynchron" abarbeiten lassen, weil dann wenigstens der Rest vom Freetz von Unsinn in den Benutzer-Kommandos nicht ausgebremst wird.

Üblicherweise werden da ja so Sachen wie ein "ifconfig wlan up" eingetragen, wenn das nicht jemand (obwohl es wohl auch nur ein Workaround soll, wenn man dem Kommentar dazu folgt) gleich wieder in einen (wenn auch optionalen) Patch verwandelt hätte, wo inzwischen alle Welt vergessen hat, daß das eben auch nur ein Workaround um ein - einigermaßen ungeklärtes - Problem sein sollte.

Aber wie auch immer - man hat eben keine Kontrolle darüber, was der Benutzer in der "rc.custom" einträgt und m.E. sollte die "rc.mod" diesen Kommandos in der "rc.custom" nur einen Schubs geben und sich ansonsten weder um die enthaltenen Kommandos, noch um die dabei erzielten Fortschritte kümmern und einfach mit der eigenen Arbeit fortfahren.

Ich würde aber selbst dann die "rc.mod" vom Rest der AVM-Initialisierung trennen, wenn die Watchdog-Zeit noch reichlich vorhanden sein sollte. Solange die "rc.mod" die installierten Pakete startet und da ggf. auch noch Unsinn in den (synchron ausgeführten) Start-Skripts stehen kann (wie z.B. ein "wget", was erst dann erfolgreich sein kann, wenn die Internet-Verbindung steht uind was dann bei einem DSL-Ausfall auch mal etwas länger dauern kann - ich habe irgendwas in der Richtung beim "callmonitor" im Hinterkopf), behindert das dann eben nicht die AVM-Services.

Solange man nicht bei Freetz-Fehlfunktionen die Box in eine Boot-Schleife schicken will (das hatte ich irgendwo heute schon mal "postuliert", ggf. war das sogar weiter oben in diesem Thread), sollte die Freetz-Initialisierung in diesem "rcmod"-Service nur angestoßen, aber nicht wirklich komplett ausgeführt werden. Schließlich wurde der "große Bruder" des "supervisors" von AVM (also der "systemd" im Original) ja in erster Linie deshalb entwickelt, um die Initialisierung und die Abhängigkeiten von Diensten in ein event-gesteuertes Framework zu verpacken - da paßt die Art und Weise des (sequentiellen) Startens der Freetz-Pakete in der "rc.mod" schon von der Philosophie nicht länger zum Rest der Initialisierung - auch wenn AVM selbst da noch längst nicht alles umgestellt hat, z.B. beim eigenen WAN-Stack und der "rc.net".

Je mehr man diese ganzen Prozesse auch in Freetz jetzt schon voneinander unabhängig gestaltet, um so einfacher ist es im weiteren Verlauf, die Daemons für die Freetz-Pakete auch vom sequentiellen Start anhand der Paketliste und der "Prioritäten" auf Service-Units und Abhängigkeiten von anderen Units umzustellen. Aus einem eigenen "freetz.target" wird zwar vermutlich nicht so ohne weiteres etwas werden, aber vielleicht funktioniert das "svctl" ja auch für Targets (ich habe es bisher noch nicht daraufhin untersucht).

 

[fda89]

Das war eine Feststellung, es war mir bislang nicht aufgefallen.
Ich habe eine 7590 als Router umschaltbar an WAN und DSL. Dazu ein 1200 Repeater via Kupfer angeschlossen. Diese Geräte verwende ich nicht allein und bekomme Ärger wenn was nicht funktioniert... Ich flashe diese selten und auch nur wenn ich vor Ort bin. Zum testen benutze ich immer eine 7490 die an einer schaltbaren Steckdose hängt, somit so gut wie unkaputbar. Internet über "mitbenutzern"/ip-client. Die Uhrzeit kommt aus der rc.custom wo lokale Geräte verwendet werden

> Der Start des "vsftpd" dürfte am "onlinechanged" und an "external" hängen
Nein, das ist ja das seltsame!

External startet erst nach rcmod: https://github.com/Freetz-NG/freetz-ng/blob/master/make/mod/files/root/etc/init.d/rc.mod#L155
Durch diese Datei konnte bis heute also auch die rc.custom external verzögern. Ich glaub onlinechanged macht ohne diese Datei auch nichts.
EDIT: https://github.com/Freetz-NG/freetz-ng/blob/master/make/mod/files/root/bin/onlinechanged.sh#L53

> Sachen wie ein "ifconfig wlan up" eingetragen
Bei mir ist das nicht nötig, keine Ahnung warum das bei manchen nicht funktioniert

> Ich würde aber selbst dann die "rc.mod" vom Rest der AVM-Initialisierung trennen
Hätt ich schon gemacht, wenn ich das mit den Pipes genau wüsste. Das ist mir so zu heikel

> "Prioritäten" auf Service-Units und Abhängigkeiten von anderen Units umzustellen.
Würde ich jetzt nicht in Angriff nehmen, dann braucht man verschieden System für die alten und neuen Geräte. Gewisse Abhängigkeiten gibt es schon: https://freetz-ng.github.io/freetz-ng/wiki/60_Development/startlevel_of_packages.en


Wie lange es bis zum Ende des Boot-Watchdogs braucht
7590: #75
7490: #81

 

[hermann72pb]

> Sachen wie ein "ifconfig wlan up" eingetragen
Bei mir ist das nicht nötig, keine Ahnung warum das bei manchen nicht funktioniert

Hast du dnsmasq im Image und vor allem diese Patches, die es dem dnsmasq ermöglichen vor multid zu starten? Ich meine mich dunkel zu erinnern, dass diese WLAN-DOWN-Problematik irgendwie damit zusammen hängt. Zumindest habe ich es bei allen meinen Boxen seit geräumter Zeit in rc.custom stehen. Und ich habe immer dnsmasq im Image.

 

[Massa]

Also ich erinnere mich, dass dieses WLAN-DOWN Problem der Grund für mich war, von freetz auf freetz-NG umzustellen.
In freetz brauchte man "ifconfig wlan up" noch (wobei es damals keine Infos gab bzw. ich keine gefunden habe, dass das Problem bereits existiert/bekannt war), in freetz-NG war bereits ein patch eingebaut, mit dem das nicht mehr notwendig war.
Ich erinnere mich auch, dass es da in Freetz-NG einen patch zum Auswählen gab/gibt - kann es nur gerade nicht (mehr) finden...

dnsmasq habe ich auch immer mit im Image - und bei mir ist kein "ifconfig wlan up" eingetragen....

 

[PeterPawn]

in freetz-NG war bereits ein patch eingebaut, mit dem das nicht mehr notwendig war.

Das kann man auch leicht mißverstehen, so wie das formuliert ist. Ja, es gibt in Freetz-NG einen Patch - nur adressiert der nicht das Problem, was zur Notwendigkeit dieses zusätzlichen "ifconfig wlan up" führt, sondern dessen Ausführung wird nur von der "rc.custom" (wo es als Workaround klar sichtbar ist) in die "rc.mod" verlagert.

Das meinte ich ja mit "lazy research" - wenn man immer so mit Problemen umgeht und die alle nur durch Workarounds versucht zu lösen (die besser nur temporär sein sollten), dann landet man irgendwann im Chaos. Das ist wie das Kleben eines Pflasters auf jeden neu aufgekratzten Mückenstich - werden das zu viele, helfen einzelne Pflaster nicht mehr (weil die dann schon übereinander kleben und die unteren so langsam zu schimmeln beginnen) und es muß ein deutlich größeres her.

Ich wage mal die Behauptung, daß noch kein einziger Nutzer eines Freetz-NG-Images für die 07.21 auf der 7490 jemals für sich selbst getestet hat, ob das Problem mit der 07.2x-Reihe weiterhin besteht. Außer der Vermutung, daß sich das Problem auf die Boxen mit dem Scorpion-WiSoC von Qualcomm beschränkt (die dafür ein eigenes, zweites FRITZ!OS in der Firmware haben, das beim WLAN-Start erst mal auf das WiSoC geladen wird), ist da wohl bisher nichts weiter bekannt, weil sich jeder Freetz-Benutzer mit dem Pflaster zufrieden gibt und einfach niemand mehr nachsehen will, ob darunter nicht schon lange der Wundbrand eingesetzt hat.

 

[fda89]

Ich wage mal die Behauptung, daß noch kein einziger Nutzer eines Freetz-NG-Images für die 07.21 auf der 7490 jemals für sich selbst getestet hat, ob das Problem mit der 07.2x-Reihe weiterhin besteht.

Doch, ich hab einen gross angelegt Feldtest gemacht, bei dem jeder unfreiwillig mitgeholfen hat: https://github.com/Freetz-NG/freetz-ng/blob/master/config/ui/patches.in#L1736
Wäre das noch nötig gewesen hätte man es mit Sicherheit sofort und oft hier gelesen

Mit BUGON war das gleiche Vorgehen. Mit 7.2x für 7590 nicht mehr nötig, für 7490 schon

@hermann72pb: Ich nutze immer dnsmasq, beauche keine "ifconfig" und keinen Patch!

 

[PeterPawn]

bei dem jeder unfreiwillig mitgeholfen hat

Wußte ich nicht, daher habe ich hier dann deutlich Unrecht ... zu meiner Verteidigung bleibt mir wohl nur die Vermutung, daß ich das glatt überlesen habe in den langen Texten, die immer den Inhalt Deiner Commits auch für "Laien" erkennbar machen, speziell bei diesem hier, wo wohl schon der Titel diesen "Hinweis" enthalten sollte, daß das ab 07.2x nicht mehr erforderlich sein würde: https://github.com/Freetz-NG/freetz...26fc4c738ad5e116cb01032458bd744d05db2b570c442 und auch in Deiner Zusammenfassung in den "NEWS" habe ich das halt überlesen.

War denn Dein Feldtest, das Entfernen der Provider-Datenbanken ab 07.19 zu deaktivieren, auch von Erfolg gekrönt (das war ja zeitlich durchaus in der Nähe: https://github.com/Freetz-NG/freetz-ng/commit/c3a6d1830f8ccf78cfe8281abf6dea4510fb103e) und es hat sich keiner darüber beschwert (wie bei der "debug.cfg" wohl auch nicht - das fällt nur den "Nicht-Benutzern" beim Lesen auf) oder hat sich dabei herausgestellt, daß man diese Patches bei der 07.2x doch besser auch deaktiviert lassen sollte? Ich frage nur aus Interesse und um zu verstehen, was Du so unter einem Feldtest verstehen könntest und woher die Freetz-NG-Benutzer jetzt wissen sollen, worauf sie bei einem solchen Feldtest achten müssen oder was am Ende eigentlich nur "noch nicht fertig" ist, wenn man auf eine neue Labor-Reihe wechselt und wo gar nicht erwartet wird, daß das schon funktioniert.

Aber ist es mir auch entgangen, daß Du (nachdem Du dann tatsächlich dachtest festgestellt zu haben, daß der WLAN_IF-Patch für die 07.19-Labore und auch die 07.2x-Release wohl auch bei anderen nicht mehr erforderlich ist) ebendiese "Anderen" darüber informiert hättest an einer Stelle, wo Du zuvor durchaus "mitdiskutiert" hattest.

Wobei man sicherlich auch ohne Übertreibung schreiben kann, daß Du diese Änderung zunächst wohl eher "auf Verdacht" hin vorgenommen hast - denn bei Dir selbst kannst Du da ja dann schwerlich getestet haben, wenn es bei Dir (auch mit Freetz oder Deinem NG) noch nie erforderlich war. Die Frage, ob der tatsächlich bei "VR9" generell notwendig ist, wie es derzeit in Freetz-NG eingebaut ist, dürfte auch noch ungeklärt sein - der Zusammenhang zum zusätzlichen (ARM-)FRITZ!OS für den QCA955X wird wohl eher zutreffen und das sind deutlich weniger Geräte, als alle mit einem VR9 als Hauptprozessor.

Zumindest wüßte ich von keiner VR9-Box, wo das Problem auftrat und die Box dann kein zweites OS verwendete für das WLAN. Und auch wenn die Änderung erst einmal vollkommen harmlos aussieht ... hat tatsächlich mal jemand getestet, welche Auswirkungen das bei einer der anderen Boxen (nicht 7490, 3490, etc., da hatte ich das sogar mal geprüft auf der 7490) hat, wenn man zuvor das WLAN absichtlich deaktiviert hatte und dann (zu recht) davon ausgeht, daß das nach einem Neustart auch noch aus sein sollte? Ich frage ja nur ... weil auch dieser Patch für den Benutzer halt "unausweichlich" ist, wenn er eine VR9-Box mit einer Firmware von 06.90 bis 07.12 verwendet.

 

[fda89]

Der Fehler ist ja nicht dass Wlan an/aus ist, sondern "es wird keine Ip zugewiesen (layer 3), obwohl WLan verbinden ist (layer 1)". Das Funknetz geht also, und nur das IP Interface und damit auch DHCP funktionieren nicht. (soweit ich das verstanden hab). Damit: Keine Beschwerden -> geht
Warum sollte man prüfen welche Auswirkung das auf nicht-VR9 hat? https://github.com/Freetz-NG/freetz-ng/blob/master/config/ui/patches.in#L1738
Die remove-dbs haben einen Fehler im Webif verursacht, dh bevor man diese aktivieren sollte bräuchten die ein bisschen Liebe. Das ist bei anderen Patches auch so. Wer die debug.cfg will (ich nicht) muss sich drum kümmern (ich nicht).

... weil auch dieser Patch für den Benutzer halt "unausweichlich" ist, wenn er eine VR9-Box mit einer Firmware von 06.90 bis 07.12 verwendet.

Nö. Hättest nur 3 Zeilen weiterlesen müssen! https://github.com/Freetz-NG/freetz-ng/blob/master/config/ui/patches.in#L1739
Bei mir ist er nicht aktiviert