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

leo22

Aktives Mitglied
Mitglied seit
13 Apr 2005
Beiträge
918
Punkte für Reaktionen
4
Punkte
18
Leider hat AVM in der neuen Firmware den Aufruf von multid beim Systemstart in der rc.net geändert. Damit lässt sich dnsmasq nicht mehr in Betrieb nehmen, da dieses erfordert, dass multid nach dnsmasq gestartet wird.

Schuld daran ist der multid-Wrapper, welcher nicht mehr abgearbeitet wird. Der alte Wrapper (in FREETZ-NG für 7.29) ruft am Schluss rc.multid mit dem Parameter $multid_mode auf.

rc.multid startet dann multid oder ruft multid zusätzlich mit -s (für Stop) oder -I (für reload) auf. Das neue rc.net (in FRITZOS 7.50) ruft multid nicht direkt auf, sondern via svctl, also z. B. svctl start multid, svctl stop multid, svctl reload multid. Deshalb funktioniert auch der alte Wrapper nicht mehr.

Hat sich schonmal jemand Gedanken gemacht, wie der Wrapper einfach zu ändern wäre? Dieser müsste ja dann in svctl eingreifen. rc.multid ist sehr komplex, so dass ich da auf die Schnelle nicht durchsehe, was dort alles passiert.

Gleiches trifft auch für den dsld-Wrapper zu. Auch dsld wird in der neuen Firmware via svctl gestartet.
 
Daran wäre ich auch sehr interessiert. Ich nutze Freetz (NG) ausschliesslich wegen der Funktionalität, einen alternativen DNS-Server auf der Box laufen zu lassen...

Ich hätte da zwei Überlegungen:

1.) man bindet den multid an einen anderen Port
2.) beim Start vom DNSMasq werden in dessen Startskript ein "multid -s" oder eben über svctl ein Stop-Kommando geschickt und am ende des Start-Skripts vom DNSMasq ein "multid" oder wieder über svctl ein Start-Kommando...
 
Zuletzt bearbeitet:
DNSMASQ funktioniert zumindest bei der 7590 mit OS7.5 im LAN leider nicht im WLAN der versuch es wie bei ehemals mit der rc.costum und ifconfig wlan up funktioniert leider auch nicht mit ifconfig wlan up
also es ist so das dnsmasq keine IP über WLAN lefert im lan schon und WLAN SSID wird auch angezeigt
 
Zuletzt bearbeitet:
Wie wäre es denn (solange Freetz-NG seine Dienste nicht ordentlich in jeweils eigene Service-Files zerlegt, die Abhängigkeiten entsprechend beschreibt und generell den supervisor zum Starten der Dienste, die sich aus Zusatzpaketen ergeben, nutzt - was ja die beste Lösung wäre), wenn beim Starten des dnsmasq der multid angehalten und im Anschluß neu gestartet wird?

Die Auswirkungen auf den multid, wenn der (DNS-)Port bereits in Benutzung ist, habe ich hier irgendwo mal gezeigt (Stichworte aicmd und multid sollten zum erwähnten Beitrag führen) und solange man kein "Gespann" aus multid und dnsmasq für die Auflösung betreiben will (was ja ohnehin nur mit Kopfständen gelingen würde), schaltet der multid dann eben lediglich die DNS-Funktionen ab und gut ist's.

Vermutlich ist das auch der Gedanke hinter dem zweiten Punkt in #2 ... nach meiner Erfahrung würde das so auch funktionieren, wobei man das Stoppen des multid wohl am besten über den Parameter -s macht, denn das (originale) Service-File enthält keinen ExecStop-Eintrag (obwohl auch ExecStop und sogar ExecStopPost wohl implementiert sind) und beim Starten dann aber wieder auf svctl zurückgreift, denn nur so erhält dann auch der supervisor wieder Kenntnis davon, daß der multid.service wieder läuft und er ihn mit der neuen PID in seine Liste der Abhängigkeiten zwischen den Services einbauen kann.

Das ganze Geraffel in rc.multid ist "Freetz-spezifisch" ... bei AVM gibt/gab es da gar kein eigenes rc-File, das war alles in rc.net enthalten.

Am einfachsten sind zwei zusätzliche Zeilen in der rc.dnsmasq in den Funktionen start (zum Anhalten des multid) und startdaemon_post (https://github.com/Freetz-NG/freetz.../dnsmasq/files/root/etc/init.d/rc.dnsmasq#L25 - zum erneuten Starten des multid), wobei man den ganzen Kram mit dem Ändern des Verhaltens des multid (inkl. Wrapper) besser gleich ganz wegläßt als Patch.

Erst wenn man das alles noch mit Abfragen spicken will, ob das auch die richtige FRITZ!OS-Version und die passende Freetz-NG-Konfiguration ist, wird das aufwändiger und braucht mehr als die erwähnten zwei Änderungen in dieser einen Datei.

Allerdings wäre es natürlich auch denkbar, den Start des dnsmasq selbst wieder über eine Service-Datei zu organisieren ... dann ist es noch viel einfacher dafür zu sorgen, daß der multid erst NACH dem dnsmasq gestartet wird ... nur paßt das dann - je nach Situation - nicht mehr zur sehr späten Initialisierung von Freetz-NG als "mod"-Paket und erst recht nicht dazu, wenn die Initialisierung von external-Paketen erst "ganz weit hinten" im Ablauf erfolgt und man den dnsmasq möglichst auch noch ausgelagert hat.

Die einzige, wirklich "saubere" Lösung wäre es hier sicherlich, den Start der ganzen Freetz-NG-Pakete ebenfalls auf die Möglichkeiten des parallelen Starts der Dienste umzustellen, was ja dank des supervisor mittlerweile möglich ist - da lassen sich sogar die Starts von Freetz-NG-Paketen und von AVM-Daemons so weit miteinander verzahnen, daß einiges an Kopfständen vermeidbar ist, wozu einen zuvor der sehr späte Start von Freetz-NG (und das dann auch noch alles "seriell" und schön der Reihe nach) gezwungen hat.

Mit dem supervisor ist es aber eben gar nicht mehr erforderlich, daß ein einmal gestarteter Service sich auch so schnell wie möglich initialisiert und danach die Steuerung wieder zurückgibt, damit der Startvorgang weitergehen kann ... da das alles parallelisiert ist, kann so ein Service (zum Beispiel für einen NTP-Client) auch einfach so lange warten, bis dann mal eine DSL-Synchronisation stattgefunden hat und die Uhrzeit irgendwie gesetzt wurde. Das behindert keinen einzigen anderen Service ... es sei denn, der wäre AUCH auf eine korrekt gesetzte Uhrzeit angewiesen und daher in seinem Service-File mittels After=<any_service> als abhängig von einem vorher zu startenden Service markiert.

Man braucht also einfach nur ein passendes Service-File erstellen und das in /lib/systemd/system werfen ... den Rest der ganzen Starterei übernimmt dann der supervisor und wenn man sich nicht anders zu helfen weiß (AVM macht das auch so, daß von Version zu Version immer mehr Dienste auf dieses Startprinzip umgestellt werden), dann führt man eben bei Service-Start einfach das (alte) rc-File aus.

AVM hat mittlerweile auch das WLAN vom LAN getrennt und startet das WLAN als gesonderten Service (wifi.service) NACHDEM der Rest des Netzwerks bereits gestartet wurde (After=network.target). Mit einiger Wahrscheinlichkeit hängt auch ein Problem mit "unvollständiger Bindung" des dnsmasq an ein Interface bzw. das Fehlen des WLANs in der LAN-Bridge (falls das so sein sollte) mit dieser geänderten Reihenfolge zusammen ... ich kann derzeit nicht mal sicher sagen, WANN denn nun die Freetz-NG-Initialisierung beginnt (die dann ihrerseits ja erst wieder den dnsmasq startet), denn ein Service, von dessen Initialisierung der Freetz-NG-Start abhängig ist (https://github.com/Freetz-NG/freetz...5/patches/scripts/115-systemd-services.sh#L21) existiert in dieser Form in FRITZ!OS 07.50 gar nicht mehr (es gibt schlicht keinen net.service mehr) und ob das jetzt am Ende heißt, daß der supervisor diese Abhängigkeit dann ignoriert und die Freetz-NG-Initialisierung zu früh startet (nämlich bevor noch das Netzwerk initialisiert wurde) oder sie wieder GANZ ANS ENDE verschiebt, kann man nur raten (solange man die Implementierung dieses offensichtlichen systemd-Abkömmlings nicht kennt) oder man muß es eben Schritt für Schritt ausprobieren (und dazu aber auch erst einmal ein Freetz-NG auf einem Gerät haben).
 
Wie in dem verlinkten Thread ersichtlich, ging es bereits mit der Labor nicht mehr.

Mit dem Release auf der 7590 sieht es ebenfalls so aus.

DNS-Port unbelegt:

Code:
aicmd multid
HELP                                     - show help
SLABDUMP                                 - show slab allocation
SLABSHOW                                 - show slab information
QUIT                                     - disconnect
eth_qos list                             - list active eth qos entries
show dns-rebind                          - show dns rebind info
show eth_status                          - show eth status ports
dnsd dump                                - dump internal info
dnsd stats                               - dump statistic
dnsd server                              - dump server statistic
dnsd cache                               - dump cache
dnsd hashtab                             - dump cache hashtab
dnsd memory                              - dump info about memory usage
dnsd queries                             - dump queries
dnsd socks                               - dump socks
dnsd forwards                            - dump forwards
dnsd probe                               - latency probe on next query
dnsd flush                               - flush cache
dnsd domainflush                         - flush cache for domain
dnsd zone                                - zone (default|guest|external)
dnsd addstatic                           - addstatic <name> <addr>
dnsd delstatic                           - delstatic <name> <addr>
dnsd delbyip                             - delbyip <addr>
dnsd delbyname                           - delbyname <name>
dnsd failstream                          - streamfailed (<ipv4-addr> | <ipv6-addr> <port>)
dnsd stoptimer                           - stoptimer (<ipv4-addr> | <ipv6-addr> <port>)
neighbour ethaddr                        - dump ethaddr hash table
neighbour inaddr                         - dump inaddr hash table
topology list                            - show list
dhcpd context                            - show context
dhcpd interfaces                         - show interfaces
dhcpd leases                             - show leases
dhcpd add                                - add static lease
dhcpd del                                - delete lease
dhcpd import                             - import <leasefilename>
dhcpv6d                                  - module NOT enabled
loop_prevention show                     - Show the currently applied filters
loop_prevention filter                   - Apply a blocking list <ifname> <iftype> <action_type> ...
lldpinfo list                            - show list
mrouter global                           - dump global info
mrouter upstream                         - dump upstream
mrouter routes                           - dump routes
mrouter vifs                             - dump vifs
rextd_mng                                - module NOT enabled
avmcsock getsymbol <address>             - get symbol for address
avmcsock show csock                      - show all csock
avmcsock show dnsconfig                  - show all dns context
avmcsock show dnsglobal                  - show all dns global values
avmcsock show dnscache                   - show cache
avmcsock show dnsqueries                 - show all pending queries
avmcsock show timercb                    - show all timer
avmcsock show debughandles               - show all debughandles
avmcsock show cprocess                   - show all processes
avmcsock show cbcontext                  - show all cbdata
avmcsock show daemon                     - show daemon status
avmcsock show cbuf                       - show cbuf status
avmcsock show avmipc [endpoint shmatch]  - show avmipc events and states
avmcsock set debug                       - set debug flags
avmcsock ctimer show                     - show all timer
avmcsock ctimer overview                 - show ctimer overview
avmcsock iotrace format unctrl|hexdump   - set format for csock iotrace
avmcsock iotrace file                    - enable iotrace to file
avmcsock iotrace enable                  - enable iotrace via debugmsg
avmcsock iotrace disable                 - disable iotrace
avmcsock iotrace match help|<match>      - show allowed matches or set match
avmcsock iotrace reset                   - remove all matches
avmcsock iotrace show                    - show configuration
ewnwlinux show csockshell                - show shells running
ewnwlinux show genetlink                 - show gerneric netlink families
libavmpcp show pcpinfo                   - show pcpinfo

Start mit belegtem DNS-Port:

Code:
multid
multid[8920]: [8920]: Daemon start failed (3sec)

Test:

Code:
aicmd multid
aicmd: avmipc_command: avmipc_stream_open failed (-1)

Erneuter start mit unbelegtem DNS-Port:

Code:
multid
multid[9389]: ready (4sec)
 
Kommt beim Start im Vordergrund und mit erhöhter Geschwätzigkeit (multid -f -v) irgendein weiterer Hinweis auf die Ursache?

Beim multid geht AVM ohnehin komische Wege - während an anderen Stellen die Firmware mehr und mehr in getrennte Einheiten zerlegt wird, kriegt dieser Daemon immer mehr Aufgaben.

Denkbar, daß da mittlerweile weitere Prüfungen drin sind, schließlich bastelt AVM auch schon seit mehreren Versionen an der Zuverlässigkeit des eigenen DNS-Servers, speziell beim Thema Failover und Recovery bei TLS-gesicherten Abfragen.

Als das Sept./Okt. 2022 noch einmal aufgewärmt wurde im anderen Thread, war ich wohl nicht mehr dabei (das Unterforum für Freetz-NG lese ich halt nur sporadisch, falls ein neuer Thread mein Interesse weckt) - dann stimmt das wohl nicht länger nach weiteren Änderungen am multid, was ich vor nicht einmal einem Jahr noch gezeigt hatte. Passiert … merke ich mir jetzt halt, daß es sich geändert hat.
 
Hier die wichtigen Teile des erweiterten Logs:

Code:
multid: dgramserver: 16(-) (allocated): bind([::]:53) failed - Address in use (125)
multid: dgramserver: 19(-) (allocated): bind(0.0.0.0:67) failed - Address in use (125)
multid: Initialisation of multid_dnsd_start [FAIL]
multid: Initialisation of daemon [FAIL]
multid: daemonmng_init() failed

Merkwürdig ist, dass er Port 67 ebenfalls anmeckert (Test ist AdGuardHome zu starten, DHCP in der Box ist dabei aus).

Selbst wenn ich den DNS-Port in der ar7.cfg ändere und mit ar7cfgchanged aktiviere (oder sollte man das besser anders machen?) geht es leider nicht.

Edit: DHCP in AdGuardHome mal deaktiviert, aber meldet dann nur noch Port 53 und schlägt trotzdem fehl.
 
Zuletzt bearbeitet:
Das sind doch schon mal Fehlermeldungen, mit denen man etwas anfangen kann.

Offensichtlich nervt es die neue Implementierung jetzt, wenn kein bind() beim DNS-Port möglich ist ... dafür gab/gibt es ja die libmultid.so, die - sofern sie "pre-loaded" wird - die bind()-Aufrufe auf andere Ports umlenken soll (jeweils Portnummer + 50000).

Problematisch wird nun nur, daß Freetz-NG bei GRX5-Boxen gar nicht mehr dieselben Libraries verwendet, wie das FRITZ!OS ... letzteres sattelte schon vor ein paar Versionen auf musl um und Freetz-NG nutzt weiterhin die uClibc-ng 1.0.40 (iirc - soo genau habe ich das auch nicht mehr verfolgt, das ist mir zuviel Aufwand).

Da in dieser Library wiederum die "normale" libc.so als erstes geladen wird, damit man darin die Funktion bind() durch eigenen Code ersetzen (bzw. ergänzen) kann, stellt sich als nächstes dann die Frage, WELCHE libc.so da eigentlich geladen wird, denn im Quelltext der Library steht das Folgende:
C:
 30 #ifndef LIBC_LOCATION
 31 #if defined(__UCLIBC__)
 32 #define LIBC_LOCATION "/lib/libc.so." xstr(__UCLIBC_MAJOR__)
 33 #endif
 34 #endif
Da sicherlich __UCLIBC__ definiert ist, wenn das für eine 7590 übersetzt wird, wird sicherlich auch der Pfad zur C-Library irgendetwas JENSEITS von /lib/libc.so. sein, wobei für die AVM-Firmware schon der "abschließende" Punkt zuviel wäre, denn dort GIBT es nur die Bibliothek /lib/libc.so - also ohne abschließenden Punkt.

Damit dürfte selbst dann, wenn der Dateiname gar nicht weiter durch die Versionsnummer der uClibc-ng erweitert wird, das Laden der C-Library schon fehlschlagen an dieser Stelle: https://github.com/Freetz-NG/freetz...48c71/make/libs/libmultid/src/libmultid.c#L60

Ich finde jedenfalls weder im Makefile (https://github.com/Freetz-NG/freetz-ng/blob/master/make/libs/libmultid/src/Makefile), noch in der Datei, die ins Makefile für Freetz-NG eingebunden wird (libmultid.mk -> https://github.com/Freetz-NG/freetz-ng/blob/master/make/libs/libmultid/libmultid.mk), einen Hinweis darauf, daß die oben zu sehende Variable LIBC_LOCATION bereits außerhalb des Quelltextes vorbelegt würde.

Überprüfen kann man das (sofern man einen Freetz-NG-Build ausgeführt hat) ganz einfach, indem man sich mal die Zeichenketten in der libmultid.so ansieht - der Pfad der zu ladenden C-Library sollte sich einfach lokalisieren lassen. Solange da NICHT nur /lib/libc.so stehen sollte, KANN das eigentlich nicht funktionieren, wenn man den multid unter Einbeziehen der libmultid.so startet, denn das exit(1) in der init()-Funktion sollte auch den gesamten weiteren Startprozess beenden.

Wie es weiter gehen kann, hängt jetzt davon ab, was da in der libmultid.so tatsächlich landet ... es müßte also mal jemand bei sich in einem Freetz-NG-Build (ich habe keinen und ich will auch keinen haben) nachsehen, was da erzeugt wurde.

EDIT: Und am besten auch mal nach allen Stellen suchen, an denen eine C-Library (egal ob musl oder uClibc-ng) vorkommt und deren genauen Namen zzgl. eventueller Symlinks auf die (finale) Datei auflisten .... nur so kriegt man einen Überblick, welche Library unter welchem Namen wo zu erreichen ist.
 
Zuletzt bearbeitet:
Da bin ich dann leider raus, benutze kein freetz...
 
Wie bzw. wozu willst Du dann den DNS-Teil des multid mit anderer Software ersetzen? Irgendwie mußt Du das vorhandene System ja modifizieren oder lädst Du tatsächlich nach jeden Neustart des Router jedem Neustart des Routers wieder das originale Binary von https://static-mirror.adguard.com/adguardhome/release/AdGuardHome_linux_mipsle_softfloat.tar.gz (manuell oder im Rahmen einer Ausführung von install.sh), um das dann (wieder nur bis zum nächsten Neustart) zu benutzen?

Ohne Remapping des Ports wird es jedenfalls eher nicht (mehr) funktionieren und da ist die Idee mit einer Library, die VOR der C-Library geladen wird, ja nicht so verkehrt - das funktioniert auch außerhalb von Freetz bzw. Freetz-NG.

Je nach vorhandenen Kenntnissen kann man sich dann dennoch die libmultid-Quellen per Cross-Compiler übersetzen und gegen eine (ebenso per Cross-Toolchain erzeugte) C-Library (bei musl gibt es nicht so viele Konfigurationsmöglichkeiten, das geht mit configure recht einfach für ein Target, wenn man die Toolchain (C-Compiler, Linker) für das Ziel hat) linken und wenn man die zuvor noch passend patcht (es wird nur der Teil benötigt, der für IPv6-Support und das Ummappen des DNS-Ports verantwortlich ist ... und dann muß noch der Name der C-Library richtig gesetzt werden), dann sollte es auch funktionieren, den multid mit einer zusätzlichen Environment-Variablen aufzurufen: LD_PRELOAD=<path_to_libmultid> multid -f -v und wenn man die libmultid noch zusätzlich mit -DDEBUG übersetzt, dann sollten sogar die darin enthaltenen zusätzlichen Protokoll-Zeilen auf der Console sichtbar sein.

Startet dann der multid wieder (und zeigt ein netstat, daß der Port 53 nach 50053 umgemappt wurde), ist der Weg für AdGuard Home auch AUF einer FRITZ!Box wieder offen, obwohl man schon eine recht potente Box dafür nutzen sollte (also eine von den "großen" und vermutlich auch nicht mehr unbedingt eine VR9-basierte).
 
Zuletzt bearbeitet:
  • Like
Reaktionen: LazyT
Irgendwie mußt Du das vorhandene System ja modifizieren
Ich passe die originale Firmware mit deinem modfs an und starte SSHD sowie AdGuardHome per rc.user - bis zur 7.50 kein Problem. :)

Das mit der libmultid habe ich noch nicht ganz verstanden:
- sie leitet den bind() Aufruf der libc auf sich selber um und addiert 50000 dazu
- damit sie benutzt wird ruft man den multid mit LD_PRELOAD=libmultid auf

Soweit korrekt? Warum muss dann an der originalen libc noch etwas geändert werden?

Danke für deine Geduld und sorry, wenn es hier etwas OT wird...

Edit1: habe libmultid mal crosscompiliert und ausprobiert:
Code:
[libmultid::_libmultid_init()] successfully initialized
[libmultid::bind()] IPv4 fd=42 0.0.0.0:67
Es wird also zumindest für DHCP schonmal aufgerufen, aber DNS sehe ich leider nicht.

Edit2: mit aktivierten D_IPV6 macht er auch DNS und es läuft wieder. Vielen Dank!
Edit3: unter bestimmten Umständen wird multid offenbar neu gestartet (z.B. neue IP?) dann wird er wieder ohne LD_PRELOAD gestartet und das Problem ist wieder da.
 
Zuletzt bearbeitet:
  • Like
Reaktionen: PeterPawn
Ich nutze bei mir dnsmasq sehr intensiv auf meiner produktiven 7590 und will darauf aus unterschiedlichen Gründen nicht verzichten. Daher hatte ich eure Diskussion hier sehr intensiv verfolgt. Am Ende war es an einigen Stellen zu spezifisch für mich, da man sich da schon sehr detailliert in die Quellen vertiefen müsste, um es nachvollziehen zu können. Es wäre für die Allgemeinheit gut gewesen, wenn @LazyT hier etwas genauer beschreiben würde, was denn von den Denkanstößen von PeterPawn letztendlich zum Erfolg gebracht hat. Ggf. in Form eines Patches oder vergleichbar. Denn die Ideen von PeterPawn sind zwar sehr wertvoll, sie bleiben aber vorerst in Form einer "Skizze", wie man es machen kann.

cuma/fda77 hat gestern bei freetz-ng etwas in die Richtung unternommen:
split FREETZ_AVM_HAS_AVMDAEMON_PRELOAD
Ob es wirkt und wie es wirkt, muss ich noch testen.

Mich irittiert dort ein wenig der Satz:
"Remaps multid's binding of the DHCP port. Don't forget to set up a server for the guest-wlan too."

War das früher nicht so, dass trotz Benutzung von DHCP von dnsmasq der multid trotzdem DHCP im Gast-WLAN übernommen hatte? Ich weiß, dass dieser "Mischbetrieb" von dnsmasq und multid alles andere als übersichtlich und gut war. Dennoch hatte es ja irgendwie funktioniert.

@LazyT Welche Erfahrungen hast du mit DHCP im Gast-WLAN bei deiner Methode?
 
Es wäre für die Allgemeinheit gut gewesen, wenn @LazyT hier etwas genauer beschreiben würde, was denn von den Denkanstößen von PeterPawn letztendlich zum Erfolg gebracht hat.
Na einfach die existierende libmultid dazu benutzt, wofür sie gedacht war: in meinem Fall eben den multid DNS-Port von 53 auf 50053 umzuleiten, um AdGuardHome als DNS-Server zu verwenden. Da gibts keinen Patch, einfach mit D_DNS + D_IPV6 und D_MUSL compiliert und dem multid mittels LD_PRELOAD untergeschoben.

Welche Erfahrungen hast du mit DHCP im Gast-WLAN bei deiner Methode?
Leider gar keine: habe kein Gast-WLAN und eben nur den DNS umgeleitet (verwende den originalen multid DHCP-Server).
 
Zuletzt bearbeitet:
Edit3: unter bestimmten Umständen wird multid offenbar neu gestartet (z.B. neue IP?) dann wird er wieder ohne LD_PRELOAD gestartet und das Problem ist wieder da.
Besteht dieses Problem des Problems immer noch? Wenn ja, läßt sich dann abschätzen, wie oft bzw. wann das auftritt?
 
und das Problem ist wieder da.
Warum änderst Du nicht einfach das service-File, mit dem der multid gestartet wird? Ich gehe mal NICHT davon aus, daß der an irgendeiner anderen Stelle direkt aus einer anderen Komponente gestartet wird (weiß es aber auch nicht, ein grep könnte da schon Wunder bewirken und Aufschluß bringen).

Und das Hinzufügen einer Variablen zum Environment in einem service-File ist easy ... wie man in mehreren Dateien von AVM auch sehen kann.

Allerdings wird dort wohl nur die Option unterstützt, eine komplette Datei als (EDIT: zusätzliches) Environment zu verwenden ... ein Hinzufügen einzelner Variablen ist wohl nicht vorgesehen (sagt jedenfalls auch mein strings über das supervisor-Binary) und so müßte man sich seine eigene Datei erzeugen.

Zwar wird auch im FRITZ!OS eine entsprechende Datei dynamisch generiert, aber nur dann, wenn die EVA-Variable ptest irgendwelche "production tests" (bei AVM oder OEMs) anstoßen soll. Üblicherweise ist diese Datei (/var/tmp/psupport.data) leer und man kann sie einfach in der Service-Definition durch eine eigene ersetzen, die nur eine Zeile für LD_PRELOAD enthält.



Falls sich mal jemand erbarmt und die Geschichte mit der libmultid für eine 7590 in Freetz(-NG) baut (m.E. wird das durch die Standardeinstellungen derzeit aber verhindert - allerdings habe ich auch nicht sooo genau hingeschaut), kann man auch genauer untersuchen, ob das mit einem Mischmasch von C-Libraries (musl + uClibc-ng) tatsächlich Probleme bereitet.

Denn schaue ich mir das Binary für den multid genauer an:
Rich (BBCode):
vidar:~/._fritzbox/FB7590/154.07.50-101716 $ file sbin/multid
sbin/multid: ELF 32-bit MSB pie executable, MIPS, MIPS32 rel2 version 1 (SYSV), dynamically linked, interpreter /lib/ld-musl-mips-sf.so.1, stripped
vidar:~/._fritzbox/FB7590/154.07.50-101716 $ readelf -hl sbin/multid
ELF Header:
  Magic:   7f 45 4c 46 01 02 01 00 00 00 00 00 00 00 00 00
  Class:                             ELF32
  Data:                              2's complement, big endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              DYN (Position-Independent Executable file)
  Machine:                           MIPS R3000
  Version:                           0x1
  Entry point address:               0xd3e0
  Start of program headers:          52 (bytes into file)
  Start of section headers:          628516 (bytes into file)
  Flags:                             0x70001007, noreorder, pic, cpic, o32, mips32r2
  Size of this header:               52 (bytes)
  Size of program headers:           32 (bytes)
  Number of program headers:         10
  Size of section headers:           40 (bytes)
  Number of section headers:         29
  Section header string table index: 28

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  PHDR           0x000034 0x00000034 0x00000034 0x00140 0x00140 R   0x4
  INTERP         0x000174 0x00000174 0x00000174 0x0001a 0x0001a R   0x1
      [Requesting program interpreter: /lib/ld-musl-mips-sf.so.1]
  ABIFLAGS       0x000190 0x00000190 0x00000190 0x00018 0x00018 R   0x8
  REGINFO        0x0001a8 0x000001a8 0x000001a8 0x00018 0x00018 R   0x4
  LOAD           0x000000 0x00000000 0x00000000 0x8b2d4 0x8b2d4 R E 0x10000
  LOAD           0x08bf94 0x0009bf94 0x0009bf94 0x02464 0x0b078 RW  0x10000
  DYNAMIC        0x0001c0 0x000001c0 0x000001c0 0x001e8 0x001e8 R   0x4
  GNU_STACK      0x000000 0x00000000 0x00000000 0x00000 0x00000 RWE 0x10
  GNU_RELRO      0x08bf94 0x0009bf94 0x0009bf94 0x0006c 0x0006c R   0x1
  NULL           0x000000 0x00000000 0x00000000 0x00000 0x00000     0x4

 Section to Segment mapping:
  Segment Sections...
   00
   01     .interp
   02     .MIPS.abiflags
   03     .reginfo
   04     .interp .MIPS.abiflags .reginfo .dynamic .hash .dynsym .dynstr .rel.dyn .init .text .MIPS.stubs .fini .rodata .eh_frame
   05     .ctors .dtors .data.rel.ro .data .rld_map .got .sdata .sbss .bss
   06     .dynamic
   07
   08     .ctors .dtors .data.rel.ro
   09
vidar:~/._fritzbox/FB7590/154.07.50-101716 $
, so wird darin ja EXPLIZIT der Loader von musl aufgerufen und da dieser dann die Variable LD_PRELOAD auswertet, die Library lädt und erst einmal die in der libmultid.so noch aufzulösenden Referenzen bearbeitet, wird schon an DIESER Stelle jetzt eine C-Library geladen (und spätere Referenzen auf dort enthaltene Funktionen MÜSSTEN sich dann auch wieder aus dieser bedienen, solange die Referenz über denselben Namen (bzw. Symlink) erfolgt) und das KÖNNTE dann durchaus auch beim Linken gegen eine uClibc-ng tatsächlich die libc.so sein, die zum FRITZ!OS gehört und mit musl generiert wurde.

Das ist von vielen Faktoren abhängig, sowohl von der Implementierung des DynLoaders in musl als auch von den diversen Flags und Zeichenketten in den (gelinkten) Bibliotheken und obendrein noch von gesetzten oder fehlenden Environment-Variablen - das ist mir tatsächlich zu kompliziert, um das alles nur im Trockentest durchzugehen und daher sollte das einfach mal jemand mit einer passenden Freetz-NG-Installation und vorhandenem strace-Binary entsprechend protokollieren lassen, denn da findet man sehr schnell heraus, welche Library tatsächlich geladen wird.

Ist das dann wirklich die aus dem FRITZ!OS (weil alle weiteren Referenzen so "unspezifisch" sein, daß sie auch über die (bereits geladene) /lib/libc.so aufgelöst werden können), sollte diese Library auch dann noch verwendbar sein, wenn FRITZ!OS und Freetz unterschiedliche C-Libraries verwenden und damit diese Einschränkung: https://github.com/Freetz-NG/freetz...a6e4fac99f0bef3b8/config/avm/features.in#L278 hinfällig sein.

In der 07.50 für die 7590 habe ich auch nur ein einziges Binary gefunden (welches keine Library und kein LKM ist), in dessen Header der Interpreter NICHT ausdrücklich auf den Loader von musl festgelegt war und das ist psupportd_sendmsg - denn das ist statisch gelinkt und Referenzen darin wurden bereits beim Linken aufgelöst:
Rich (BBCode):
vidar:~/._fritzbox/FB7590/154.07.50-101716 $ find . -type f -not -name "*.[ks]o*" -exec file '{}' \; | grep ELF | grep -v "interpreter.*musl"
./usr/bin/psupportd_sendmsg: ELF 32-bit MSB executable, MIPS, MIPS32 rel2 version 1 (SYSV), statically linked, stripped
vidar:~/._fritzbox/FB7590/154.07.50-101716 $



@LazyT:
Hast Du jetzt LIBC_LOCATION im Quelltext angepaßt oder nicht? In Deiner Liste in #15 fehlt das.
 
Zuletzt bearbeitet:
läßt sich dann abschätzen, wie oft bzw. wann das auftritt?
Mir fiel es bisher nur 1x auf, dass DHCP nicht mehr ging nachdem ich eine weitere VPN-Verbindung hinzugefügt hatte.

Warum änderst Du nicht einfach das service-File, mit dem der multid gestartet wird?
Wenn ich das richtig sehe lädt er das Environment aus /var/tmp/psupport.data? Das wäre ja sogar ohne weiteren Aufwand beschreibbar. Muss ich mal testen bei Gelegenheit.

Hast Du jetzt LIBC_LOCATION im Quelltext angepaßt oder nicht?
Anfangs ja, inzwischen gibt es seit dem Commit gestern auch die Option D_MUSL.
 
Das wäre ja sogar ohne weiteren Aufwand beschreibbar.
Das würde ich mir verkneifen ... denn diese Datei wird auch noch von anderen Service-Definitionen benutzt - daher ja meine Ausführungen dazu, wie man sich eine "eigene" erstellen sollte.

Anfangs ja, inzwischen gibt es seit dem Commit gestern auch die Option D_MUSL.
Ah ja ... da habe ich gar nicht erst mehr nachgesehen und mit den ganzen zwischenzeitlichen Änderungen wirkt ja auch Deine "Anleitung" aus #15 wieder "unvollständig" - wofür Du zwar nichts kannst, aber vielleicht wäre es doch gut, wenn man sich bei der weiteren Diskussion mal auf EINEN Thread konzentriert oder meinetwegen noch einen dritten aufmacht, in dem dann die "neuen" Erkenntnisse zusammengefaßt werden. So, wie es jetzt mit zwei "parallel gespeisten" Threads läuft, ist es jedenfalls eher suboptimal ... da verliere sogar ich selbst den Überblick, was wo genau geschrieben wurde.



Wenn mich nicht alles täuscht, sollte bei ALLEN verwendeten C-Libraries auch mindestens ein Symlink unter /lib/libc.so auf (irgendeine) C-Library verweisen und zwar auf die, welche ursprünglich für das FRITZ!OS verwendet wurde/wird und DAS wäre ja genau diejenige, die auch für multid zu verwenden wäre. Das würde dann die ganzen (zusätzlichen) Symbole und die Abhängigkeit von der C-Library, die bei AVM verwendet wird, obsolet werden lassen ... daher ja meine "Frage" an die Freetz-NG-Benutzer weiter oben.
 
Das würde ich mir verkneifen ... denn diese Datei wird auch noch von anderen Service-Definitionen benutzt - daher ja meine Ausführungen dazu, wie man sich eine "eigene" erstellen sollte.
Hab ich beim überfliegen am Handy verpeilt, sorry. Allerdings sollte ja nichts anderes von AVM die Ports 53/67 nutzen und sollte damit ja relativ "egal" sein? Für etwas eigenes müsste ich das ja bereits beim Image erstellen anpassen und neu flashen.

So, wie es jetzt mit zwei "parallel gespeisten" Threads läuft, ist es jedenfalls eher suboptimal
Ich hatte mich hier ja eigentlich nur wegen dem identischen Problem mit AdGuardHome eingeklinkt und würde den Freetz Experten daher wieder das Feld überlassen.
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.