Geänderter Start von multid in FRITZOS 7.50 - Wrapper für dnsmasq funktioniert nicht mehr

[PeterPawn]

Was nicht mehr funktioniert ist nun die ONLINECHANGED Abfrage,

Geht es genauer?

Der Mechanismus mit dem onlinechanged läuft ja tatsächlich über den multid, von dem wird - nach einer Benachrichtigung seitens des dsld - das (Shell-)Skript /bin/onlinechanged aufgerufen und zwar mit Parametern, die die Änderungen (offline, online, offlineipv6, onlineipv6 - die Parameter ohne ipv6 beziehen sich dann eben auf IPv4) und den neuen "Gesamtzustand" (status_offline, status_onlinev4, status_onlinev6 oder status_online4v6) spezifizieren.

Dieses Skript sucht dann innerhalb des Verzeichnisses /etc/onlinechanged (nicht rekursiv) nach regulären Dateien (deshalb funktionieren dort auch bei AVM keine Symlinks) und versucht die gefundenen Dateien als Shell-Skripte (unabhängig von ihrem Inhalt und event. vorhandenen Shebangs) auszuführen, wobei die Parameter an diese Skripte weitergeleitet werden. In diesem Verzeichnis versammeln sich bei AVM dann auch die diversen Aktionen, die bei einem Wechsel des Online-Status ausgeführt werden sollen:

• send_crashreport -> benachrichtigt bei Änderungen nach "online" den ctlmgr, der dann seinerseits prüft, ob es (a) zuvor einen Absturz gab und (b) das Senden derartiger Protokolle an AVM erlaubt ist, bevor er einen Absturzbericht versendet
• start_smbd -> stoppt und startet den (von AVM eingekauften) SMB-Service nqcs, wenn die Box als IP-Client läuft (ansonsten wird der nach jeder WebDAV-Änderung neu gestartet, damit auch ein vorhandenes bzw. fehlendes Verzeichnis für den "Online-Speicher" korrekt eingebunden wird) und der (IPv4-)Zustand nach online wechselt
• webdav_net -> dieses Skript ist eigentlich (heutzutage) einigermaßen überflüssig bzw. dem Beibehalten einer früheren Dateisystemstruktur geschuldet ... es prüft lediglich die Existenz eines weiteren Skripts (/etc/webdav_control) und ruft dann dieses mit den Parametern auf, die schon an webdav_net übergeben wurden

Streng genommen ist die Reihenfolge bei der Abarbeitung dieser Skript-Dateien in /etc/onlinechanged zufällig, wobei das verwendete find-Kommando sicherlich immer dieselbe Reihenfolge (die nicht zwingend alphabetisch sortiert ist) ausspucken würde und dabei (immer noch) sequentiell (und nicht parallel, wie beim Start des Systems) gearbeitet wird.

---

In Freetz-NG hingegen (und in den anderen Abkömmlingen von Freetz) gibt es eine Option dafür, dieses Verhalten zu ändern: https://github.com/Freetz-NG/freetz...8cd64a5f83e0e28f5a/config/ui/patches.in#L1687 - die (automatische) Übersetzung ins Deutsche ist:

Das in AVM eingebaute onlinechanged wird auf einigen DSL-Dosen aus unbekannten Gründen nicht zuverlässig aufgerufen (siehe http://www.ip-phone-forum.de/showthread.php?t=231873).

Auf Boxen hinter einem NAT, z.B. auf vielen IP-Clients, hinter Kabelroutern usw., wird onlinechanged ebenfalls nicht ausgelöst, da dsld nicht für die Verbindung zuständig ist. Somit können die Dienste auf solchen Boxen nicht automatisch neu initialisiert werden, nachdem sich die externe IP-Adresse geändert hat.

An dieser Stelle kann dieser Patch nützlich sein: Er startet ein Shell-Skript /sbin/ip_watchdog über /etc/inittab und sorgt dafür, dass das Skript automatisch neu gestartet wird (über "respawn"), falls es versehentlich beendet wird. Das Skript prüft in regelmäßigen Abständen (60 s) die externe IP über /usr/bin/get_ip und ruft die onlinechanged-Skripte von AVM und Freetz über /bin/onlinechanged.sh auf, wenn sich die IP geändert hat. Gleichzeitig stellt der Patch sicher, dass das Master-Skript /bin/onlinechanged von AVM leer ist, so dass die Skripte nicht doppelt aufgerufen werden.

Wer sollte diesen Patch verwenden? In erster Linie Benutzer mit für NAT konfigurierten Boxen, die von AVM onlinechanged überhaupt nicht profitieren können. Zweitens Benutzer, die Probleme mit dem unzuverlässigen Aufruf von AVM onlinechanged auf ihren DSL-Boxen haben.

Begrenzungen: Die Umgebungsvariable IPADDR wird wie üblich gesetzt, aber keine anderen Variablen, die von AVM multid im ursprünglichen onlinechanged gesetzt werden, wie NETMASK, GATEWAY, DNS1, DNS2.

Sie werden derzeit weder von AVM noch von Freetz-Skripten verwendet verwendet, so dass diese Einschränkung kein Problem darstellen sollte. Ein weiterer Unterschied zu AVM onlinechanged ist, dass diese Lösung nur "onlinechanged online" aufruft, niemals "onlinechanged offline". Auch dies sollte kein Problem sein, aber Sie sollten sich dessen bewusst sein.

Übersetzt mit www.DeepL.com/Translator (kostenlose Version)

Geändert wird das (neue) System dann an dieser Stelle: https://github.com/Freetz-NG/freetz-ng/blob/master/patches/scripts/109-replace_onlinechanged.sh und das erfolgt - wie man sieht - auch unabhängig davon, ob man das AVM-Skript ersetzen will oder nicht - im letzteren Fall kommt noch eine weitere Aufrufebene hinzu, bei der das Freetz-Skript /bin/onlinechanged.sh PARALLEL aufgerufen wird (https://github.com/Freetz-NG/freetz...ches/scripts/109-replace_onlinechanged.sh#L23) und dem (aufrufenden) multid schon lange vor der Abarbeitung der ganzen "action"-Skripte signalisiert wird, daß die Verarbeitung der Signalisierung abgeschlossen ist.

Das ist allerdings einigermaßen kontraproduktiv, besonders bei moderneren (FRITZ!)OS-Versionen und an Dual-Stack-Anschlüssen - dann fühlt sich der multid nämlich berechtigt, sofort nach einer "online"-Benachrichtigung für IPv4 eine weitere für IPv6 (oder auch umgekehrt, je nachdem, wie sich das System verhält) nachzureichen (da gibt es ja gar keine "gemeinsame" Nachricht, online und onlineipv6 sind jeweils getrennte Änderungen, s.o.) und DAS muß jetzt (obwohl dem multid ERNEUT der sofortige Erfolg gemeldet wird, weil die zweite Instanz von /bin/onlinechanged.sh eben auch parallel gestartet wird) innerhalb von /bin/onlinechanged.sh erst einmal passend synchronisiert bzw. serialisiert werden.

WAS das /bin/onlinechanged.sh dann in seinen verschiedenen Prozessen (es ist ja IMMER dasselbe Skript) genau macht, protokolliert es aber einigermaßen ausführlich in der Datei /var/log/onlinechanged.log - da sollte dann meines Erachtens auch bei einem Problem ETWAS MEHR als ein lakonisches:

Was nicht mehr funktioniert ist nun die ONLINECHANGED Abfrage

drin sein und mindestens dieses Protokoll noch "beigelegt" werden, wenn schon die (resultierende, also bestenfalls die "komprimierte") Konfigurationsdatei für Freetz-NG fehlt und man so auch nicht entscheiden kann, ob die o.g. Option zum Ersetzen des AVM-Mechanismus nun bei der Konfiguration ausgewählt wurde oder nicht.

---

Und in onlinechanged.sh werden dann auch deutlich mehr Orte nach Skripten durchsucht (https://github.com/Freetz-NG/freetz.../pkgs/mod/files/root/bin/onlinechanged.sh#L67) und diese obendrein noch (über alle Verzeichnisse) alphabetisch nach Namen sortiert, bevor sie dann aufgerufen werden - da muß man dann auch für mehr Orte im Dateisystem sicherstellen, daß einem da niemand ein Kuckucksei ins Nest legt und man das dann einfach aufruft. Außerdem besteht im Freetz-Skript zwischen den Zeilen 48 und 50 eine (wenn auch kleine) Chance für eine "race condition", wo dann ggf. zwei Instanzen von onlinechanged.sh parallel an die Abarbeitung der Skript-Dateien gehen.

Es gibt kein "atomares" Konstrukt aus einem einzelnen test -e <filename> und einem nachfolgenden touch <filename>, aber das läßt sich anders regeln, indem man die eigene PID ins Semaphoren-File schreibt und dabei die Shell-Option noclobber verwendet - gewonnen hat dann derjenige Prozess, dessen PID tatsächlich in der Datei steht und ein zweiter muß weiterhin warten, bis der Vorgänger seinerseits beendet ist. Für das Dateisystem sorgt dann der Kernel (i.V.m. den FS-Treibern) dafür, daß tatsächlich nur EINMAL die Datei erfolgreich angelegt werden kann, wenn zwei Prozesse parallel versuchen, dieselbe Datei zu erzeugen. Nur einer der konkurrierenden Prozesse erhält dann das Handle, mit dem er seine PID in die Datei schreiben kann und nur derjenige, dessen PID tatsächlich in der Datei steht, hat dann die Sperre als Eigentümer auch eingerichtet.

 

[hermann72pb]

@PeterPawn Danke für die ausführliche Untersuchung von onlinechanged.sh! Aber wenn man es jetzt abkürzen würde: Eigentlich sollte es dann reichen, diesen patch ins Image nicht reinzunehmen und alles bleibt dabei, wie AVM es original macht? Zumindest rein theoretisch.
Ich kann mich noch an die Zeiten erinnern, als Alexander Kriegisch es damals so um 2007 geschrieben hatte. Da hatte AVM tatsächlich noch mächtig Probleme in ihrer Original-Firmware damit. Aber es ist inzwischen viel Zeit vergangen... Ich muss zugestehen, ich hatte bei mir diese Option auch immer "mitgenommen". Einfach weil es bis jetzt funktioniert hatte. Aber es ist tatsächlich so, dass viele Sachen in FREETZ mittlerweile an die sich veränderte AVM-Firmware nicht mehr so gut passen, sodass man sich vor allem bei den Patches gut überlegen sollte, ob man die alle denn immer noch einfach "mitnimmt".

 

[feedzapper]

Es ist so das /var/log/onlinechanged.log nicht existiert - zu KEINEM Zeitpunkt.
- REPLACE_ONLINECHANGED und ONLINECHANGED-WEB-CGI sind deaktiviert in Freetz.
- Die Box läuft tatsächlich an einem DS lite Anschluss
- ONLINECHANGED taucht zu keinem Zeitpunkt im SYSLOG mit dem geänderten multid.service auf
hier mal ein Log vom dsld bei laufender Verbindung und einem Neustart im Vordergrund :

root@fritz:/var/log# svctl stop dsld
[svctl] dsld.service, result: success
root@fritz:/var/log# dsld -d -f -v
dsld: set no arch
dsld: set no arch
dsld: startup ($Revision$$CompileDate: Nov 18 2022 12:02:18 $)
dsld: DSL Mac 44:XX:XX:XX:XX:XX
dsld: VOIP Mac 44:XX:XX:XX:XX:XX
dsld: VCC2 Mac 44:XX:XX:XX:XX:XX
dsld: VCC3 Mac 44:XX:XX:XX:XX:XX
dsld: kdsld_set_guest_ipv4_net: 192.168.179.0/255.255.255.0
dsld: voip: ppptarget voip disabled, ignored
dsld: sync_dsl is igd_device
dsld: interface lo carrier_up.
dsld: interface cpunet0 carrier_up.
dsld: interface eoam carrier_up.
dsld: interface adsl carrier_up.
dsld: interface ppptty carrier_up.
dsld: interface eth2 carrier_up.
dsld: interface eth1 carrier_up.
dsld: interface eth0 carrier_up.
dsld: avmipc_command: avmipc_stream_open failed (-1)
dsld: interface lan carrier_up.
dsld: interface wifi1 carrier_up.
dsld: interface ath0 carrier_up.
dsld: interface tun0 carrier_up.
RTNETLINK answers: No such file or directory
dsld: egress shaping with fq_codel
dsld: ingress shaping with fq_codel
RTNETLINK answers: No such file or directory
dsld: Sync!!!!!!; media=VDSL
dsld: old sync_type=1, old dslfd=-1, old ifname=ptm0
dsld: real speed 109310/41998 (vdsl)
dsld: effective speed 109310/41822 (vdsl)
dsld: change_wanqueues: WAN queues do not exist; setting them up
dsld: kdsld_set_qos_rate ptm0 rate 41822
dsld: showtime: sync_dsl
dsld: interface ptm0 carrier_up.
dsld: ntpiface: 0
dsld: real speed 109310/41998 (vdsl)
dsld: effective speed 109310/41822 (vdsl)
dsld: change_wanqueues: WAN queues do not exist; setting them up
dsld: _showtime(1): sync_dsl (0)
dsld: _autodetect_complete(1): sync_dsl (0)
dsld: determine_tc_shaper_params: encaplen=26, kbitrate=41157, burst=3200, cell_size=64, linklayer=ethernet, packet_overhead=8, mpu=64
RTNETLINK answers: No such file or directory
dsld: avmipc_command: avmipc_stream_open failed (-1)
dsld: interface dsl carrier_up.
dsld: avm_pa: prioack enable ptm0 0x100005
dsld: avm_pa: prioack tgetenable ptm0 0x100004
dsld: 0: out auth ok: "XXXXXXXXXXXX", sync_group:0x76ea2e00
dsld: kdsld_set_qos_rate ptm0 rate 41157
dsld: kdsld_set_qos_rate ptm0 rate 41157
dsld: avmipc_command: avmipc_stream_open failed (-1)
dsld: avmipc: multid newprefix
dsld: kdsld_set_guest_ipv4_net: 192.168.179.0/255.255.255.0
dsld: avmipc_command: avmipc_stream_open failed (-1)
dsld: avm_pa: prioack enable ptm0 0x100005
dsld: avm_pa: prioack tgetenable ptm0 0x100004

 

[PeterPawn]

@hermann72pb:
Wenn das heißen soll, daß man nicht nur die Option in der Freetz.-NG-Konfiguration ausschaltet (denn dann gäbe es immer noch Änderungen bei der onlinechanged-Behandlung), sondern den oben verlinkten Patch (109-irgendwas) komplett entfernt, dann würde ich da mal auf "paßt" tippen - allerdings habe ich mir längst nicht mehr alle anderen Patches auf Abhängigkeiten und ggf. Inkompatibilitäten mit neueren FRITZ!OS-Versionen angesehen. Damit verliert man dann aber auch die Freetz-Behandlung KOMPLETT (gerade bei einem kaskadierten Router KANN die durchaus nützlich sein, solange man sich nichts Eigenes gebaut hat) und ebenso das dazugehörige Benutzer-Interface.

---

Es ist so das /var/log/onlinechanged.log nicht existiert - zu KEINEM Zeitpunkt.

Und da gibt es definitiv einen Zusammenhang damit, daß Du das Service-File für den multid geändert hast?

Ich finde irgendwie keinen Punkt in https://github.com/Freetz-NG/freetz-ng/blob/master/make/pkgs/mod/files/root/etc/init.d/rc.multid, der eine (direkte) Auswirkung auf die onlinechanged-Behandlung erkennen ließe ... entweder das erfolgt wieder über drei Ecken oder es gibt tatsächlich keinen direkten Zusammenhang (auch nicht mit irgendwelchen Semaphoren, von denen onlinechanged.sh dann abhängig ist).

Irgendwo im erwähnten Skript gibt es noch eine Prüfung, ob die Datei /tmp/.mod.started existiert oder nicht (https://github.com/Freetz-NG/freetz-ng/blob/master/make/pkgs/mod/files/root/bin/onlinechanged.sh#L36), vielleicht kommt sich DAS jetzt auch ins Gehege, weil die Events schon auftreten können, wenn der "freetz-mod" noch gar nicht komplett initialisiert wurde.

Warum der dann aber GAR KEIN Protokoll mehr ausgeben soll, erschließt sich mir nicht wirklich ... irgendwie KANN das eigentlich nur dann passieren, wenn das (Freetz-)Skript tatsächlich NIE aufgerufen wird, denn irgendeine log-Zeile ist eigentlich in jedem denkbaren Pfad bei der Ausführung zu finden: https://github.com/Freetz-NG/freetz-ng/blob/master/make/pkgs/mod/files/root/bin/onlinechanged.sh und dann legt jeder Aufruf die ggf. fehlende Protokolldatei auch an (die Ausgabe erfolgt mittels append-Redirection).

Vielleicht überprüfst Du einfach noch einmal, welche Änderungen durch Freetz-NG da tatsächlich vorgenommen wurden und wo DU ggf. der Freetz-(NG-)Idee die Füße wegziehst. Ansonsten sollte man diese Events so oft man möchte reproduzieren können, indem man einfach (im AVM-GUI) den dsld zum reconnect überredet - damit ist der eigene Test eigentlich relativ simpel.

 

[FischersFreetz]

Es ist so das /var/log/onlinechanged.log nicht existiert - zu KEINEM Zeitpunkt.

Dem kann ich nur widersprechen.

Spoiler: cat /var/log/onlinechanged.log

# cat /var/log/onlinechanged.log
1970-01-01 01:02:39 [6881-online] approved
1970-01-01 01:02:39 [6889-onlineipv6] waiting
1970-01-01 01:02:39 [6881-online] executing /etc/onlinechanged/00-get_ip
1970-01-01 01:02:39 [6881-online] executing /tmp/flash/onlinechanged/onlinechanged-cgi
1970-01-01 01:02:40 [6881-online] executing /etc/onlinechanged/start_smbd
1970-01-01 01:02:40 [6881-online] executing /etc/onlinechanged/webdav_net
1970-01-01 01:02:40 [6881-online]  * webdav_net online status_onlinev4
1970-01-01 01:02:41 [6881-online]  * mkdir: can't create directory '/var/media/ftp/uStor01/FRITZ/': Not a directory
1970-01-01 01:02:41 [6881-online]  * cat: can't open '/proc/bus/usb/devices': No such file or directory
1970-01-01 01:02:44 [6881-online]  * [svctl] smb2.service, result: success
1970-01-01 01:02:44 [6881-online]  * [svctl] smb2.service, result: success
1970-01-01 01:02:44 [6881-online]  * 1970-01-01 01:02:44 wsdd[7222]: ready (0sec)
1970-01-01 01:02:45 [6881-online] finished

1970-01-01 01:02:45 [6889-onlineipv6] approved
1970-01-01 01:02:46 [6889-onlineipv6] executing /etc/onlinechanged/00-get_ip
1970-01-01 01:02:46 [6889-onlineipv6] executing /tmp/flash/onlinechanged/onlinechanged-cgi
1970-01-01 01:02:46 [6889-onlineipv6] executing /etc/onlinechanged/start_smbd
1970-01-01 01:02:46 [6889-onlineipv6] executing /etc/onlinechanged/webdav_net
1970-01-01 01:02:46 [6889-onlineipv6]  * webdav_net onlineipv6 status_onlinev4v6
1970-01-01 01:02:46 [6889-onlineipv6] finished
...

Und vielen Dank für die Erläuterungen in #60.

 

[MikeBl]

trotzdem kann ich es nicht auswählen, um überhaupt etwas anpassen zu können. Vielleicht könnte dabei jemand helfen, was da schief läuft , o. ist es evtl jetzt generell deaktiviert worden.

Vollbild(er) gemäß Boardregeln als Vorschau eingebunden by stoney

 

[PeterPawn]

In der zugehörigen Datei Config.in (https://github.com/Freetz-NG/freetz-ng/blob/master/make/pkgs/dnsmasq/Config.in) sind keine zusätzlichen Bedingungen zu sehen, die eine Anzeige im Konfigurationsmenü verhindern würden.

Vielleicht entfernst Du ja die bestehende Konfiguration einfach einmal (man kann sie ja auch umbenennen und muß sie nicht gleich komplett löschen) und beginnst von vorne (am besten inkl. "Neubau" der Kconfig-Tools, dann sollten automatisch auch alle Caches älteren Datums sein und neu erstellt werden) - vielleicht ist die Option dann ja sichtbar. Es gibt jedenfalls keine (offensichtliche) Bedingung (im derzeitigen GitHub-Stand, wobei da in letzter Zeit keine Änderungen ausgeführt wurden, die darauf Einfluß haben könnten), mit der man dieses Paket irgendwie ausblenden könnte ... wenigstens eine Zeile mit dem Paketnamen sollte auch dann sichtbar sein, wenn das Paket NICHT aktiviert ist.

Aber vermutlich ist es (wieder mal) ganz simpel und da verwendet jemand (konkret Du, @MikeBl) einen alten Checkout, bei dem das Paket (eben WEGEN der bisherigen Unklarheiten) noch deaktiviert war für entsprechende FRITZ!OS-Versionen: https://github.com/Freetz-NG/freetz-ng/commit/a2f9a2c8a4b1b2ce0b7b306af51e8dc65faf0c74 - allerdings ist das jetzt auch schon wieder vier Wochen her, daß diese "Sperre" entfernt wurde. Also nichts mit:

o. ist es evtl jetzt generell deaktiviert worden.

, sondern ganz im Gegenteil, wenn ich mit meiner Vermutung richtig liegen sollte.

---

Es ist halt ermüdend (und da kann ich @cuma dann auch bis zu einem gewissen Punkt verstehen), wenn man immer wieder "die Basics" herbeten und/oder erst mal "nachweisen" muß, daß irgendwelche Probleme NICHT AUTOMATISCH bei Freetz-NG liegen müssen ... da gibt es durchaus noch genug andere offene Probleme, die tatsächlich dem Projekt zuzuschlagen wären.

So schwer sollte es jedenfalls nicht sein, sich (vor allem dann, wenn man sich selbst nicht so richtig auskennt) an die "vorgeschlagenen Wege" zu halten und dazu sollte (ich habe es aber nicht geprüft, ob das auch tatsächlich so dokumentiert ist) als erster Schritt auch immer ein "frischer Checkout" gehören, damit die Leute dann nicht alten, längst behobenen Problemen hinterher laufen müssen. Dann noch ein Screenshot, in dem man die Versionsangabe in der ersten Zeile auch sehen kann (man KANN solche Bilder ja auch als Vorschau einbinden und dann spielt die Größe (entgegen landläufiger Annahmen) auch keine entscheidende Rolle mehr bzw. größer ist dann tatsächlich automatisch auch besser, wenn man da mehr Infos entnehmen kann) und schon ist so ein "Problem" auch ohne jede Recherche in der "history" zu erkennen.

 

[MikeBl]

Mach eigentlich immer vor bauen ein Checkout. Hier noch Versionsnummer besagten letzten gebauten Images: 7590_07.50.all_freetz-ng-35609M-UNKNOWN_20230106-235835.
Hoffe ist für Beurteilung ausreichend.
Umgebung selber hab ich erst vor 3 Wochen neu aufgesetzt.


Leider ist besagtes dnsmasq nicht auffindbar unter Packages.
Werd aber config file einmal umbenennen und neu erstellen, vielleicht bringt es was.

 

[PeterPawn]

Sorry, da bin ich absolut raus. Ich habe KEINEN Schimmer, was genau die SVN-Bridge bei GitHub macht, wenn man darüber einen Klon erzeugen will.

Warum nimmst Du nicht einfach das passende git-Kommando, wie hier: https://github.com/freetz-ng/freetz-ng beschrieben und wohl von der überwiegenden Mehrheit der heutigen Freetz-NG-Benutzer praktiziert?

Von jemandem, der seine Kompetenz als "developer" einschätzt, würde ich tatsächlich erwarten, daß er das SELBST findet - zumal da ja auch noch eine dicke, fette Warnung steht.

Und dann funktioniert (nur nebenbei) üblicherweise auch die Anzeige des Hash-Wertes für den letzten Commit in der ersten Zeile wieder, wo bei Dir jetzt nur UNKNOWN steht ...

 

[MikeBl]

Danke und sorry, git pull brachte es wieder. Wollte auch nicht anmaßend mit der Auswahl Developer sein, weiss , bin es nicht ansatzweise,mir ging es nur um die erweiterten Auswahlmöglichkeiten, ob ich diese bedienen kann, ist eine andere Frage. Aber egal, das "richtige" Checkout bringt es.
Jetzt läuft auch Box wie sie sollte mit Firmware 7.50.
Dank an alle nochmals.

 

[hermann72pb]

---

Es ist halt ermüdend (und da kann ich @cuma dann auch bis zu einem gewissen Punkt verstehen), wenn man immer wieder "die Basics" herbeten und/oder erst mal "nachweisen" muß, daß irgendwelche Probleme NICHT AUTOMATISCH bei Freetz-NG liegen müssen ... da gibt es durchaus noch genug andere offene Probleme, die tatsächlich dem Projekt zuzuschlagen wären.

So schwer sollte es jedenfalls nicht sein, sich (vor allem dann, wenn man sich selbst nicht so richtig auskennt) an die "vorgeschlagenen Wege" zu halten und dazu sollte (ich habe es aber nicht geprüft, ob das auch tatsächlich so dokumentiert ist) als erster Schritt auch immer ein "frischer Checkout" gehören, damit die Leute dann nicht alten, längst behobenen Problemen hinterher laufen müssen. Dann noch ein Screenshot, in dem man die Versionsangabe in der ersten Zeile auch sehen kann (man KANN solche Bilder ja auch als Vorschau einbinden und dann spielt die Größe (entgegen landläufiger Annahmen) auch keine entscheidende Rolle mehr bzw. größer ist dann tatsächlich automatisch auch besser, wenn man da mehr Infos entnehmen kann) und schon ist so ein "Problem" auch ohne jede Recherche in der "history" zu erkennen.

Genau das habe ich nach meiner langjährigen Erfahrung hier in IPPF befürchtet...
Darum habe ich mir parallel und unabhängig von eurer Diskussion hier (als ob ich hellsehen kann) eine neue Libre Office Writer Datei angelegt, wo ich zunächst mal alles wirklich akribisch Schritt für Schritt protokolliere, was ich mache. Daraus erzeuge ich anschließend eine PDF-Datei und poste hier, wenn ihr nichts dagegen habt. Mit allen Quellangaben versteht sich. Denn mittlerweile wird es langsam sehr unübersichtlich hier, weil man sich die Informationen über mehrere Threads und Postings zusammen suchen muss.

Was haltet ihr von meiner Idee?

Und ja, Peter, Schritt 0 meiner Anleituntg ist wirklich "frisch auschecken" mit dem entsprechenden git-Befehl ...

[Edit Novize: Beiträge zusammengefasst - siehe Forumsregeln]

Leider hänge ich bei meiner Schritt-für-Schritt Anleitung noch an einigen Stellen, die eine lückenlose und in sich schlüssige Doku bis jetzt verhindern. Und zwar, sind wir wieder bei der Generierung von libmultid.so, aber bitte "sauber" mit FREETZ NG eigenen Config-Variablen. Es wurde oben vorgeschlagen, es mit "make libmultid-precompiled" zu erzeugen. So ganz "sauber" ist es aber nicht, denn damit landet die Bibliothek am Ende nicht unter "modified" und dementsprechend auch nicht im Image. Es manuell dahin zu schieben wäre auch nicht die feine Art. Schuld daran ist die Variable FREETZ_AVM_HAS_AVMMULTID_PRELOAD, die warum auch immer nicht aktiviert wird. Dadurch bleiben auch viele andere Sachen deaktiviert. Unter anderem die von mir bereits angesprochenen "vor multid laden" usw., die man früher in menuconfig auswählen/abwählen konnte oder zumindest gesehen hatte.
Ich habe mir insofern geholfen, dass ich die ursprünglich leere config/custom.in wie folgt gefüllt habe:

config FREETZ_AVM_HAS_AVMMULTID_PRELOAD
bool "AVM HAS AVMMULTID"
default n

Danach sieht man deutlich mehr Optionen unter menuconfig und zwar logischerweise als "zwangsaktiviert" als Folge von meinem "bypass". libmultid.so landet dann auch unter "build". Vermutlich muss man dann auch kein "precompiled" zwangsläufig ausführen. Die Frage wäre aber, ob diese von mir notdüftig selbsterfundene "bypass"-Option gut ist und woran es eigentlich hackt, dass FREETZ_AVM_HAS_AVMMULTID_PRELOAD "verboten" bleibt. Ich finde auf jeden Fall die Stelle im ganzen Wüst der Zwangsverknüpfungen und Zwangsbedingungen nicht, warum und vor allem wo es bei 7590 und FW 7.50 deaktiviert wurde.

Edit: Damit ihr selbst den Eindruck bekommt, was man durch meinen "Bypass" da zu sehen bekommt, poste ich hier ein Paar Screenshots vom menuconfig. Der Punkt aus config/custom.in taucht im Hauptmenü zumindest bei mir ganz unten auf. Wenn man diesen Punkt aktiviert, tauchen an diversen Stellen die zuvor verborgenen Optionen zu libmultid.so auf.

Edit2: Ich werde wirklich alt... Eigentlich hatte ich in #14 doch selbst meine Frage beantwortet: cuma/fda77 hatte es mit seinem letzten commit eingeführt
commit + Diskussion dazu
Und wie man da unten in den Kommentaren zum commit sieht, bin ich nicht der Einzige, der mit dieser neuen Variable ein Problem hat, sogar ziemlich das gleiche Problem. Es wird da aber auch ersichtlich, dass der Verursacher der oben angesprochenen "Blockade" eigentlich

depends on \
       !FREETZ_SEPARATE_AVM_UCLIBC

ist. Jetzt bleibt es nur herauszufinden, wo diese Variable gesetzt wird...

Ach... und jetzt hat cuma es wieder zurückgezogen, nachdem ich mit meiner Anleitung da angefangen hatte. Ist wirklich 7 Stunden alt die letzte Änderung:
!FREETZ_SEPARATE_AVM_UCLIBC ist wieder raus
Langsam steige ich da nicht mehr durch. So schnell kommen da mittlerweile die Änderungen im trunk

 

[hermann72pb]

Nach dem ich mich ein Paar Tage mit anderen Dingen als FREETZ beschäftigt habe, scheint auf GITHUB wieder was passiert zu sein:
remove FREETZ_AVM_HAS_DNSCRASH
Steigt da überhaupt jemand noch durch?
Ich habe heute echt frisch ausgecheckt, extra minimal Pakete und Patches unter menuconfig ausgewählt und wollte nach meiner noch unfertigen Anleitung nochmal versuchen ein Image zu bauen, um diese Anleitung zu überprüfen und ggf. zu aktualisieren. Das Hauptproblem mit der Sichtbarkeit diverser Patches um multid herum unter menuconfig und der Möglichkeit libmultid dort als aktiviert zu sehen scheint durch die beiden Änderungen von cuma/fda77 auf github nun beseitigt zu sein. Dadurch sind meine Klimzüge aus dem Betrag zuvor nun nicht mehr erforderlich. libmultid.so sollte sich nach meinem Verständnis jetzt sogar ohne precompiled bauen lassen. Allerdings überblicke ich derzeit kaum Änderungen um den wrapper herum. Und das macht mich etwas unsicher.
Hat schon jemand probiert ein Image mit dnsmasq nach den letzten Änderungen zu bauen? Vielleicht funktioniert es doch mit der alten wrapper-Methode, was ich eigentlich nicht glaube.

 

[leo22]

Was um den wrapper herum passiert, da bin ich auch noch nicht dahintergestiegen, daher rührt ja auch dieser Thread.
Nach den diversen Änderungen von cuma habe ich schon mehrfach neue Images gebaut, und dnsmasq scheint mit meiner alten Konfiguration zu funktionieren.

 

[hermann72pb]

@leo22 Habe ich richtig verstanden, dass du bei dir all die Änderungen, die hier diskutiert und vorgeschlagen wurden gar nicht gemacht hast? Sprich einfach Image erstellt und es hat mit deiner alten dnsmasq-config dann funktioniert?
Aber dann dürfte es nicht so lange her sein, dass es mit dnsmasq, FW7.50 und FREETZ NG nun geht. Denn noch Anfang Januar durfte es eigentlich nicht gehen und erst seit den letzten 1-2 Änderungen von cuma.
Wenn es so ist, dann war das eigentliche Problem eigentlich nicht der wrapper an sich (obwohl es hier empfohlen wurde, den entsprechenden 106-Patch dazu zu löschen), sondern viel mehr die libmultid. Der wrapper hat dann nicht funktioniert, weil die Lib nicht richtig kompilliert oder eingebunden war oder sogar beides. Die hier vorgeschlagene Lösung mit der temp-Datei ist zwar auch sehr elegant und an sich interessant, aber im Grunde macht (oder versucht zumindest) der wrapper von FREETZ NG die gleiche Aufgabe, wenn es denn richtig funktionieren würde.
Ich schaue es mir dann zunächt mit FREETZ NG ohne Anpassungen und Veränderungen an.

Edit 20.01.2023 20:00: Nachdem ich es heute mit dnsmasq mit dem aktuellen FREETZ NG ohne hier oben im Thread vorgeschlagener Änderungen ausprobiert habe, kann ich die Rückmeldung von @leo22 bestätigen: Es läuft nun auch ohne die Veränderung nach Anleitung aus #30 oder aus #46. Die beiden Vorschläge würden zwar vermutlich als Alternativlösung immer noch funktionieren, dnsmasq funktioniert aber nun auch mit der aktuellen Version von FREETZ NG. Die Betonung liegt aber hier wirklich auf "aktueller Version". Und an dieser Stelle würde ich aus eigener Erfahrung auch empfehlen, frisch auszuchecken, mit menuconfig von vorne anzufangen und nicht versuchen, die alte Version aus dem git upzudaten, alte .config zu nutzen oder Ähnliches. Zwar könnte es grundsätzlich auch funktionieren und ich würde es nicht ausschließen, dennoch, wenn man sich etwas genauer betrachtet, was da alles in den letzten Tagen auf GITHUB alleine um diese Thematik herum passiert ist, wird man verstehen, warum ich es empfehle.

Das einzige, was ich allerdings zusätzlich vor dem Update (noch mit der alten Firmware+FREETZ) gemacht habe, war die Umstellung des Gastnetzes auf dnsmasq, wie von @leo22 hier ausführlich erläutert.

 

[schacka]

Bei der 6591 funktioniert es mit "LD_PRELOAD=/lib/libmultid.so multid" nicht direkt, da die libc.so.0 nicht unter /lib liegt ("multid: error while loading shared libraries: libc.so.0: cannot open shared object file").

Es geht eigentlich sehr komfortabel, wenn ich in der multidEnvironmentFile vorher den LD_LIBRARY_PATH angebe,

LD_LIBRARY_PATH=/usr/lib/freetz
LD_PRELOAD=/lib/libmultid.so multid

dann den Patch "106-wrapper_multid.sh" anpasse,

echo1 "preparing multid libmod"

# wrapath="/usr/bin/wrapper/"
# for daemon in dsld multid rextd; do
    # file="${FILESYSTEM_MOD_DIR}/lib/systemd/system/$daemon.service"
    # [ -e "$file" ] || continue
    # modsed -r \
      # "s,^(ExecStart *=).*/*($daemon *.*)$,\1$wrapath\2," \
      # "$file" \
      # "$wrapath$daemon"
# done

# grep -q "^PATH=" "${FILESYSTEM_MOD_DIR}/etc/init.d/rc.net" || sed '2 i\PATH=$PATH' -i "${FILESYSTEM_MOD_DIR}/etc/init.d/rc.net"

# modsed \
  # "s#\(^PATH=\)\(.*\)#\1/usr/bin/wrapper:\2#g" \
  # "${FILESYSTEM_MOD_DIR}/etc/init.d/rc.net" \
  # "^PATH=/usr/bin/wrapper:"

envfile="/var/tmp/multidEnvironmentFile"
file="${FILESYSTEM_MOD_DIR}/lib/systemd/system/multid.service"
    modsed -r \
      "s,^(EnvironmentFile=).*,\1$envfile," \
      "$file" \
      "$envfile"

und die Datei multidEnvironmentFile über die rc.custom kopiere.

cp /var/media/ftp/multidEnvironmentFile /var/tmp

 

[PeterPawn]

Bei der 6591 wird die glibc verwendet und die sollte man dann auch für den Start des multid benutzen - denn das Preloading von Libraries ändert ja nichts anderes mehr an dem erzeugten Prozess und AVM dürfte den multid genau gegen diese Library gelinkt haben.

Die Version der Library ist die 2.28 - folglich liegt die auch als /lib/libc-2.28.so vor und auf diese Datei wird dann mit dem Symlink /lib/libc.so.6 verwiesen - also mit einer Sechs am Ende und keiner Null.

Die saubere Lösung wäre es hier, die Library schon beim Erzeugen gegen eine glibc-2.28 zu linken ... aber notfalls geht es auch mit einer nachträglichen Änderung, weil beim Build eines Freetz-NG-Images ja keine glibc-2.28 gebaut/verwendet wird (zumindest keine fürs "target"), sondern die uClibc-ng (in irgendeiner Version, was hier aber keine Rolle spielt).

Für die Änderung kann man auf dieses Tool zurückgreifen: https://github.com/NixOS/patchelf - was m.W. ohnehin schon bei Freetz-NG in den Tools oder sogar in den "prerequisites" steht. Der Aufruf würde (in etwa) so aussehen:

patchelf --replace-needed libc.so.0 libc.so.6 libmultid.so

und danach sollte eine (erfolgreich geänderte) Library libmultid.so nach der (vorhandenen) /lib/libc.so.6 suchen, wobei vermutlich auch ein einfacher, zusätzlicher Symlink von /lib/libc.so.6 auf /lib/libc.so.0 ausreichen würde, was dann eine etwas unsauberere Lösung wäre (weil ja noch andere Programme nach einer libc.so.0 suchen könnten und die kriegen dann auch - je nach Suchreihenfolge - unter Umständen die glibc-Version der Library vorgesetzt).

EDIT: Die angegebene Version 2.28 der glibc stammt noch aus der Firmware 07.27 - sollte sich das geändert haben bei der Labor-/Inhouse-Reihe (eine Release-Version für die 6591 gibt es ja m.W. noch nicht oder sie wäre an mir vorbeigegangen), spielt das aber auch keine Rolle, denn genau für solche Fälle ist ja der "stable link" als libc.so.6 vorhanden, der dann schon auf die richtige Datei zeigen wird.

 

[schacka]

@PeterPawn Es läuft wie heißes Frittenfett Besten Dank für die fundierte Erklärung!

Scheint aber insgesamt ein Problem bei der 6591 zu sein und auch der Wrapper ist murks. So murks, dass sich die Box beim Autostart von DNSMASQ und reboot komplett aufhängt. Bei der 7.29 als auch der 7.39 (deine Erinnerung trügt dich nicht). Am Ende ist also alles mit einem schönen Startscript und der angepassten libmultid.so machbar.