Ich gehe mal davon aus, daß wir uns da auch mißverstanden haben ... meine Antwort in #2 bezog sich eigentlich nur darauf, daß die in #1
verdächtigten Symbole nichts mit dem dnsmasq-Paket in Freetz zu tun haben ... es gibt diese Symbole eben auch in jedem anderen kdsldmod.ko auf einer nicht modifizierten FRITZ!Box.
Da es sich offenbar um irgendwelche "double free errors" (also wiederholte Freigaben eines eigentlich bereits freigegebenen Bereiches im Speicher, was auf generelle Probleme bei der Verwaltung der "Lebenszeit" von Speicher und/oder Objekten hindeutet) handelt, ist es in meinen Augen auch ziemlich normal, wenn der Fehler dann irgendwann auf den verwendeten DNS-Server "durchschlägt", solange der AVM-IP-Stack (das ist ja das Gespann aus kdsldmod.ko und dsld) für DNS-Abfragen (die dann natürlich überwiegend vom tatsächlich verwendeten DNS-Server/-Proxy getätigt werden) irgendeine Sonderbehandlung ausführt und dabei dann aufs Antlitz knallt.
Das Symbol ab #4, bei dem der Fehler dann auftritt (dnsmasqentry -> das ist ja der Name der Funktion, die das doppelte "free()" auslöst, wie der Auszug aus dem Kernel-Code in #2 zeigt), ist ja auch ein anderes als das in #1 (da war es "dnsmasq_expire_timer") und dieses "dnsmasqentry" ist keine Funktion aus kdsldmod ... also stürzt bei den Fehlern ab #4 wohl tatsächlich der dnsmasq irgendwo ab, wenn der eine Funktion "dnsmasqentry" enthalten sollte.
Ob das nun ein Folgefehler eines nach wie vor vorhandenen "double free" in AVM's kdsldmod ist oder ob da dnsmasq tatsächlich einen eigenen Fehler produziert (halte ich für weniger wahrscheinlich, weil dnsmasq eigentlich mit der Verwaltung von Kernel-Memory (da kommen "slabs" zum Einsatz) eher weniger zu tun haben sollte), kann ich auch nicht feststellen.
Jedenfalls finden bei AVM eben auch Symbole Verwendung, die die Zeichenfolge "dnsmasq" ihrerseits enthalten:
Code:
$ grep dnsmasq /proc/kallsyms
815c3f20 t dnsmasq_headerhashkey [kdsldmod]
815c4140 t dnsmasq_rcv_fragquery [kdsldmod]
815c4300 t dnsmasq_unhash [kdsldmod]
815c4480 t dnsmasq_expire_timer [kdsldmod]
816b7a04 d dnsmasq_entry_cache [kdsldmod]
815c44e0 t dnsmasq_attach [kdsldmod]
815c4ca0 t dnsmasq_flush [kdsldmod]
815c4520 t dnsmasq_exit [kdsldmod]
815c4540 t dnsmasq_init [kdsldmod]
815c4560 t dnsmasq_new.constprop.12 [kdsldmod]
815c46a0 t dnsmasq_snd_packet [kdsldmod]
815c4e20 t dnsmasq_detach [kdsldmod]
815c4e80 t dnsmasq_rcv_packet [kdsldmod]
816b79c4 d dnsmasq_module_struct [kdsldmod]
815c5700 t dp_dnsmasq_active_entries [kdsldmod]
815c5780 t dp_set_dnsmasq_masquerading [kdsldmod]
816b79c0 d dnsmasq_module_desc [kdsldmod]
815c56a0 t dp_dnsmasq_print [kdsldmod]
815c5800 t dp_set_dnsmasq_dnsservers_notifyfunc [kdsldmod]
815c57e0 t dp_set_dnsmasq_overwrite_dnsservers [kdsldmod]
815c57c0 t dp_set_dnsmasq_dnsservers [kdsldmod]
815c5aa0 t dp_set_dnsmasq_transparent [kdsldmod]
815c5a20 t dp_get_dnsmasq_dnsservers [kdsldmod]
815c5a60 t dp_get_dnsmasq_used_dnsservers [kdsldmod]
Ich kann es zwar nicht ausschließen, daß die irgendetwas mit dem "
dnsmasq" von Simon Kelley zu tun haben, halte das aber nach wie vor für wenig wahrscheinlich ... ich habe auch in den Quellen von dnsmasq auf Anhieb bei Stichproben keinen der o.a. Funktionsnamen gefunden. Daher gehe ich bei den oben dargestellten Symbolen tatsächlich davon aus, daß sich hinter "dnsmasq" irgendeine Um-/Beschreibung der Arbeitsweise verbirgt und weniger eine "Sonderbehandlung" für das dnsmasq-Paket von S. Kelley.
Daß dann diese "Sonderbehandlung" für DNS-Pakete im Allgemeinen auch zu einem Zeitpunkt stattfindet, wo der DNS-Server vermutlich irgendwelche Pakete aussendet/empfängt, liegt m.E. ganz einfach daran, daß sonst wohl niemand (bzw. eher wenige Prozesse) ihrerseits mit DNS-Abfragen nach außen drängen aus einer FRITZ!Box heraus.
Ich würde tatsächlich nicht nachvollziehen können, wie ein "user-land process" (und das ist der "dnsmasq" meines Wissens) etwas mit der slabs-Verwaltung im Kernel zu tun haben sollte ... beim kdsldmod.ko wäre das hingegen vollkommen normal, das ist praktisch seine "natürliche Speicherverwaltung" für kleinere Requests. Insofern halte ich eben einen entsprechenden Absturz des "dnsmasq"-Servers (wenn es überhaupt dazu kommen sollte und das nicht nur eine Warnung ist, die als "Ablaufverfolgung" dient und auf das potentielle Problem aufmerksam machen soll) immer noch für einen Folgefehler eines anderswo zu suchenden Problems.
Da ich bei mir alle DNS-Abfragen über einen VPN-Tunnel zu einem Root-Server laufen lasse, kann ich die 7490 nicht selbst bei diesem Problem "beobachten", da die FRITZ!Box in diesem Szenario eben DNS-Abfragen gar nicht als solche erkennen kann und somit auch keine irgendwie geartete Sonderbehandlung stattfinden kann. Ich würde aber fast darauf wetten wollen, daß dieser Fehler auch auf "unbehandelten AVM-Versionen" ab und an mal auftreten sollte. Leider läßt sich das nur dann halbwegs zuverlässig ermitteln (sonst ist sie ja nicht mehr "unbehandelt"), wenn man den AVM-Mailserver "mail3.avm.de" für die eigene FRITZ!Box "umlenkt" und somit dafür sorgt, daß die E-Mails an
[email protected] und
[email protected] abgefangen werden und man so bei einem Crash auch automatisch Kenntnis von dessen Ursache erhält.
