Dnsmasq (?) crasht die Box scheinbar / 06.35 und 06.50

vice_pres

Mitglied
Mitglied seit
6 Apr 2008
Beiträge
473
Punkte für Reaktionen
4
Punkte
18
Hi, Ich hab mich immer mal wieder gefragt warum die Box ab und zu rebootet (selten) - ich bekomm nur keinen wirklichen Dreh dran...
Code:
 Jan 13 20:50:05 fritz kern.info kernel: [290224.010000] ipmasq: CPU0 line 3162, got lock Jan 13 20:50:05 fritz kern.err kernel: [290291.870000] slab error in cache_free_debugcheck(): cache `dnsmasqentry': double free detected Jan 13 20:50:05 fritz kern.warn kernel: [290291.880000] Call Trace: Jan 13 20:50:05 fritz kern.warn kernel: [290291.880000] [] dump_stack+0x8/0x40 Jan 13 20:50:05 fritz kern.warn kernel: [290291.880000] [] cache_free_debugcheck.isra.43+0x118/0x140 Jan 13 20:50:05 fritz kern.warn kernel: [290291.880000] [] kmem_cache_free+0x3c/0x120 Jan 13 20:50:05 fritz kern.warn kernel: [290291.880000] [] dpenv_cache_free+0x18/0x24 [kdsldmod] Jan 13 20:50:05 fritz kern.warn kernel: [290291.880000] [] dnsmasq_expire_timer+0x38/0x48 [kdsldmod] Jan 13 20:50:05 fritz kern.warn kernel: [290291.880000] [] timercb_docallouts+0x388/0x890 [kdsldmod] Jan 13 20:50:05 fritz kern.warn kernel: [290291.880000] [] timer_function+0x44/0x104 [kdsldmod] Jan 13 20:50:05 fritz kern.warn kernel: [290291.890000] [] run_timer_softirq+0x154/0x280 Jan 13 20:50:05 fritz kern.warn kernel: [290291.890000] [] hw5_irqdispatch+0x90/0x120 Jan 13 20:50:05 fritz kern.warn kernel: [290291.890000] [] start_kernel+0x3f0/0x408
Es tritt unter 06.50 und unter 06.35 auf, ich kann es leider aber nicht reproduzieren - also nicht mit einer bestimmten Aktion. Ab und zu passiert es einfach... Viele Grüße Peter Edit: Leider gehen die Zeilenumbrüche verloren, ich habs nochmal probiert... geht auch nicht
 

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
12,691
Punkte für Reaktionen
915
Punkte
113
Das ist nicht der dnsmasq, falls Du das Paket für Dein Freetz-Image gewählt hast.

Diese Symbole finden sich in kdsldmod.ko wieder, es gab sie auch schon vor dem 3.10.73-Kernel dort.

Das wollte ich zwar schon lange mal ausprobieren, ob da AVM nun einen Prozess "dnsmasq" irgendwie anders behandelt, wenn der eine Verbindung nach draußen aufbaut (nur dann dürfte der kdsld dafür zuständig sein) oder ob da am Ende Code-Teile aus dem originalen dnsmasq verbaut sind (glaube ich aber nicht, der steht unter GPLv2, das vermeidet AVM m.E. bei den "closed source"-Komponenten wie der Teufel das Weihwasser).

Es könnte auch ganz schlicht bei AVM für "DNS masquerading" stehen und mit dem Namen des freien DNS-Servers nur zufällig übereinstimmen. Letzteres halte ich sogar für die wahrscheinlichste Erklärung, denn die Behandlung von DNS-Abfragen folgt in der Firmware schon eigenen Regeln, ggf. sogar getrennt nach "Diensten" ... gesonderte Server für TR-069 und SIP hat bestimmt jeder schon mal in einer FRITZ!Box-Konfiguration gesehen, genauso wie extra dafür erstellte Regeln, die solchen Verkehr maximal priorisieren.

Da findet also zweimal eine Freigabe desselben kleineren Speicherbereiches (die "slabs" sind die zweite Stufe der Speicherverwaltung im Kernel, unterhalb der "pages") statt, das ist irgendwo ein Fehler im kdsld mit höherer Wahrscheinlichkeit und tritt vermutlich auch dann auf, wenn auf einer Box gar kein Freetz aktiv ist. Da das alles innerhalb des Kernels läuft (offensichtlich irgendeine Timer-Behandlung) und Du sicherlich keinen eigenen Kernel verwendest, dürfte das nur schwer aus dem "user space" zu erreichen sein, daß so ein Fehler auftritt.

Offensichtlich hat AVM da auch noch entsprechenden Zusatzcode zum Testen solcher Bedingungen im Kernel belassen bei der Release-Version, denn der Fehler stammt eigentlich aus "mm/slab.c":
Code:
#if DEBUG || defined(CONFIG_DEBUG_SLAB_DOUBLE_FREE)
#define slab_error(cachep, msg) __slab_error(__func__, cachep, msg)

static void __slab_error(const char *function, struct kmem_cache *cachep,
                        char *msg)
{
        printk(KERN_ERR "slab error in %s(): cache `%s': %s\n",
               function, cachep->name, msg);
        dump_stack();
        add_taint(TAINT_BAD_PAGE, LOCKDEP_NOW_UNRELIABLE);
}
#endif
und wird nur eincompiliert, wenn eine der "DEBUG"-Bedingungen erfüllt ist.
 

vice_pres

Mitglied
Mitglied seit
6 Apr 2008
Beiträge
473
Punkte für Reaktionen
4
Punkte
18
Danke Peter, ich habe mich tatsächlich von der namensgleichheit verwirren lassen und auf das Paket dnsmasq getippt. Ich werde die Box nochmal auf das 06.50er Image switchen und dann mal schauen was im syslog steht wenn die crasht.
 

vice_pres

Mitglied
Mitglied seit
6 Apr 2008
Beiträge
473
Punkte für Reaktionen
4
Punkte
18
Nur als Nachtrag, mit 06.50 siehts so aus:

Code:
Jan 19 20:43:42 fritz kern.err kernel: [434800.120000] slab error in cache_free_debugcheck(): cache `dnsmasqentry': double free detected
Jan 19 20:43:42 fritz kern.debug kernel: [434800.120000] CPU: 0 PID: 0 Comm: swapper/0 Tainted: P           O 3.10.73 #1
Jan 19 20:43:42 fritz kern.debug kernel: [434800.120000] Stack : 00000003 8088afa8 00000051 00000051 00000000 00000000 00000009 00000003
Jan 19 20:43:42 fritz kern.debug kernel: [434800.120000] 	  00000000 00000400 00000000 00000000 00000005 80720ac0 8066d63c 80720807
Jan 19 20:43:42 fritz kern.debug kernel: [434800.120000] 	  00000000 00000000 8088a2d0 80720ac0 815c0000 80110000 816d6f98 8004e438
Jan 19 20:43:42 fritz kern.debug kernel: [434800.120000] 	  8e5ef800 8004a9b0 00000000 00000000 80670d14 8070fb84 8070fb84 8066d63c
Jan 19 20:43:42 fritz kern.debug kernel: [434800.120000] 	  00000000 00000000 00000000 00000000 00000000 00000000 00000000 8070faf8
Jan 19 20:43:42 fritz kern.debug kernel: [434800.120000] 	  ...
Jan 19 20:43:42 fritz kern.err kernel: [434800.120000] Call Trace:
Jan 19 20:43:42 fritz kern.debug kernel: [434800.120000] [<80025080>] show_stack+0x80/0xa0
Jan 19 20:43:42 fritz kern.debug kernel: [434800.120000] [<8010ca9c>] cache_free_debugcheck.isra.57+0xbc/0x140
Jan 19 20:43:42 fritz kern.debug kernel: [434800.120000] [<8010d7b8>] kmem_cache_free+0x58/0x180
Jan 19 20:43:42 fritz kern.debug kernel: [434800.130000] [<800558e8>] do_softirq+0xa8/0xc0
Jan 19 20:43:42 fritz kern.debug kernel: [434800.130000] [<80020194>] r4k_wait_irqoff+0x34/0x48
Jan 19 20:44:32 fritz kern.err kernel: [434849.500000] [kernel-trap] pc=0x8010cf08(cache_alloc_refill+0x148/0x7e0) addr=0x800068e0 task=dnsmasq pid=4484 ra=0x8010ce48(cache_alloc_refill+0x88/0x7e0)
Jan 19 20:44:32 fritz kern.err kernel: [434849.510000][1]DSP: XDU=1( D1 ) OVR=1 MIPS_OVR=0
Jan 19 20:44:32 fritz kern.err kernel: [434849.510000][1][pcmlink]error: trigger too late 13783 usec (40fe9fb6 41333498 4133c240)
Jan 19 20:44:32 fritz kern.err kernel: [434849.510000][1]avm_DebugSignal: 0 kernel info: 0
Jan 19 20:44:32 fritz kern.err kernel: [434849.510000][0][avmdebug] push: pushmail 2
 

sebdas

Neuer User
Mitglied seit
25 Jan 2016
Beiträge
2
Punkte für Reaktionen
0
Punkte
1
Ich sehe ähnliche Probleme schon seit einigen Releases. Der Fehler tritt unregelmäßig im Schnitt vielleicht einmal in 24 Stunden auf. Soweit ich sehen kann, sind nur Freetz Images betroffen, nicht jedoch originale AVM Images. Ein Beispiel aus Syslog:

Code:
Jan 24 10:51:57 gw.lan kernel: [175140.490000] slab error in cache_free_debugcheck(): cache `dnsmasqentry': double free detected
Jan 24 10:51:57 gw.lan kernel: [175140.490000] Call Trace:
Jan  24 10:52:12 gw.lan kernel: [175155.840000] [kernel-trap]  pc=0x8010cf08(cache_alloc_refill+0x148/0x7e0) addr=0x800068e0  task=dnsmasq pid=3251 ra=0x8010ce48(cache_alloc_refill+0x88/0x7e0)
Gibt es Ideen zur Eingrenzung der Ursache oder zur Vermeidung des Fehlers?
 

vice_pres

Mitglied
Mitglied seit
6 Apr 2008
Beiträge
473
Punkte für Reaktionen
4
Punkte
18
Mittlerweile sehe ich es doch etwas anders als PeterPawn in #2 - zumindest aus meiner Sicht als nicht-entwickler.

Der Grund: Es wird explizit auf den dnsmasq Prozess und seine PID verwiesen, also scheint es ja doch schon mit DEM dnsmasq Paket zu tun haben das ich ausgewählt habe.

z.B.
Code:
Feb 26 17:15:11 fritz kern.err kernel: [252561.210000] [kernel-trap] pc=0x8010cf08(cache_alloc_refill+0x148/0x7e0) addr=0x800068e0 task=dnsmasq pid=4447 ra=0x8010ce48(cache_alloc_refill+0x88/0x7e0)
 

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
12,691
Punkte für Reaktionen
915
Punkte
113
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.
 

vice_pres

Mitglied
Mitglied seit
6 Apr 2008
Beiträge
473
Punkte für Reaktionen
4
Punkte
18
Oha, da hab ich Peter jetzt aber herausgefordert :D ;)

Ja, das hatte ich in der Tat dann missverstanden in #2 und danke für deine ausführliche Erklärung! Ich war also trotzdem irgendwie auf dem Holzweg :)

Ich bin mal auf die Suche gegangen nach "dnsmasqentry" - hab es in diversen Bootlogs von Fritzboxen die im Netz stehen gefunden und beim grep im Freetz Ordner sagt grep, dass kdsldmod.ko die Zeichenfolge beinhaltet.

Manchmal passiert es 2 mal am Tag, manchmal auch eine Woche lang garnicht - und ich finds nicht so wirklich raus wobei es passiert, meist ganz im Hintergrund und ich merk es nur weil die MT-F ihr Display anmachen.

Alles in allem kann man wohl wenig dran drehen - ich hab derzeit für ein Support-Ticket bei AVM eine Installation mit vanilla 06.51 laufen auf der auch Geräte angemeldet sind - da ist es in 23 Tagen bisher keinmal passiert (da ich da die Box neu aufgesetzt habe und sie jetzt seitdem läuft - allerdings im LAN1 Modus und nicht als DSL-Router).
 

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
12,691
Punkte für Reaktionen
915
Punkte
113
dass kdsldmod.ko die Zeichenfolge beinhaltet.
In der Tat ... da ich mit meinem "grep" auf die Kernel-Symbole nur die "externen" Symbole erwische, habe ich das "dnsmasqentry" im kdsldmod.ko gar nicht gesehen. Wenn das nur innerhalb der Zeichenketten im Module das Ergebnis einer __func__-Referenz ist (siehe das #define für slab_error in #2), paßt das aber dazu, daß es in der Kernel-Meldung auftaucht und trotzdem kein externes Symbol ist.

Damit hat dann auch dieser Funktionsname wohl nichts mit dem dnsmasq zu tun ... ich schrieb ja in #7 auch, daß dazu der dnsmasq ohnehin eine entsprechend benannte Funktion enthalten müßte und dann immer noch unklar wäre, warum da ein Userland-Prozess mit slabs hantiert.

Ich habe schon überlegt, ob das an irgendwelchen "malformed answers" bei DNS-Abfragen liegen könnte (z.B. die aktuelle glibc-Lücke tendiert ja auch in diese Richtung, auch wenn da "malformed" eigentlich übertrieben ist) ... wenn dabei der DNS-Resolver irgendwie dazu gebracht werden kann, so ein "double free" zu machen (was meist ja mit "use after (first) free" verbunden ist), dann wäre so ein Problem in der Tat sehr schwer nachzustellen, weil immer die (externe) Antwort als Auslöser dazu benötigt würde.

Ich hoffe mal stark, daß AVM da nicht doch irgendwo im kdsldmod "Anleihen" beim Resolver-Code der glibc genommen hat (außerhalb weiß ja niemand - ohne Quelltext-Einblick - wozu diese Behandlungen überhaupt gedacht sind ... man kann nur spekulieren, daß dort der Unterschied in den "logischen" Interfaces (internet, tr069, voip, usw.) irgendwie behandelt wird, wenn jedes dieser Interfaces eigene DNS-Server haben kann) ... und damit das Problem hinter CVE-2015-7547 auf diesem Weg vielleicht doch Einzug hält, auch wenn im FRITZ!OS anstelle der glibc die uClibc verwendet wird. Aber es kann natürlich genauso gut auch jede andere ungültig aufgebaute Antwort sein oder sogar wieder ein Fehler, der nur in bestimmten Konstellationen überhaupt auftritt - wobei es dafür wohl doch zu regelmäßig erfolgt.

Jedenfalls werde ich bei solchen (nicht deterministischen) Problemen immer etwas unruhig - wenn man sagen könnte, das tritt bei der Abfrage der Adresse für "foo.bar.com" auf, ist das etwas anderes, als wenn es sporadisch auftaucht und praktisch nicht zu reproduzieren ist.
 

sebdas

Neuer User
Mitglied seit
25 Jan 2016
Beiträge
2
Punkte für Reaktionen
0
Punkte
1
Eventuelle Diskussionen um CVE-2015-7547 sind sicherlich einen separaten Thread wert.

Ich hatte auch irgendwann Zweifel am Ausschluss des Zusammenhangs mit Dnsmasq bekommen. Zur Validierung hatte ich ein Image ohne diese Option generiert. Diese Konstellation läuft tatsächlich perfekt stabil seit 4 Wochen. Damit habe ich einen Workaround, welcher mir ermöglicht, Freetz mit Einschränkung weiterhin einzusetzen. Ausgehend von Beobachtungen der Router Crashs ist der Zusammenhang mit der Nutzung von Dnsmasq zwingend.

Ich sehe natürlich auch die Schwierigkeit, die auftretenden Debug-Symbole zuzuordnen. Es wäre vermutlich interessant zu sehen, ob eine andere alternative DNS/DHCP-Lösung ähnliche Probleme generieren würde. Kennt jemand passende Alternativen?

Bezüglich Workaround: Gibt es Tipps, wie wir einen Betrieb ohne Dnsmasq kompensieren können? PXE Boot und TFTP lässt sich in meinem Fall vorübergehend von anderen Maschinen betreiben. Ich sehe jedoch keine Möglichkeit, die DNS Domain der angeschlossen DHCP Klienten zu kontrollieren.
 
Zuletzt bearbeitet:

schalli

Neuer User
Mitglied seit
31 Jul 2006
Beiträge
5
Punkte für Reaktionen
0
Punkte
0
Eventuelle Diskussionen um CVE-2015-7547 sind sicherlich einen separaten Thread wert.

Ich hatte auch irgendwann Zweifel am Ausschluss des Zusammenhangs mit Dnsmasq bekommen. Zur Validierung hatte ich ein Image ohne diese Option generiert. Diese Konstellation läuft tatsächlich perfekt stabil seit 4 Wochen. Damit habe ich einen Workaround, welcher mir ermöglicht, Freetz mit Einschränkung weiterhin einzusetzen. Ausgehend von Beobachtungen der Router Crashs ist der Zusammenhang mit der Nutzung von Dnsmasq zwingend.

Ich sehe natürlich auch die Schwierigkeit, die auftretenden Debug-Symbole zuzuordnen. Es wäre vermutlich interessant zu sehen, ob eine andere alternative DNS/DHCP-Lösung ähnliche Probleme generieren würde. Kennt jemand passende Alternativen?

Bezüglich Workaround: Gibt es Tipps, wie wir einen Betrieb ohne Dnsmasq kompensieren können? PXE Boot und TFTP lässt sich in meinem Fall vorübergehend von anderen Maschinen betreiben. Ich sehe jedoch keine Möglichkeit, die DNS Domain der angeschlossen DHCP Klienten zu kontrollieren.
Hi, ich habe genau das gleiche Problem wie oben beschrieben.
Die Box crasht etwa ein bis zwei Mal am Tag und im syslog findet sich der Kernel Stacktrace von oben.

Ein Workaround, den ich gefunden habe ist folgender:
In der dnsmasq-config das Häkchen bei "Durch AVM/Provider zugewiesene Upstream Nameserver nutzen.momentan: 192.168.180.1 und 192.168.180.2" und eigene DNS-Server eintragen (ich hab die von Google genomen: 8.8.8.8 und 8.8.4.4).
Seit zwei Tagen hatte ich keine Abstürze.
Habe dann testweise wieder das Häkchen reingenommen und die Google-DNS-Server gelöscht, prompt ist die Box nach einigen Stunden abgeschmiert.

Leider kann ich auch nicht mehr zur Behebung des Fehlers beitragen, aber vielleicht hilft mein Workaround, das Problem einzugrenzen.
Und es wäre schön, wenn der ein oder andere meinen Workaround verifizieren könnte.
"Kein Absturz seit zwei Tagen" ist nicht so aussagekräftig, wie ich mir das wünsche.

Ich werde aber ein Auge drauf haben und berichten, falls es mit den manuellen DNS-Servern doch nicht funktioniert.


Grüße

schalli
 

hermann72pb

IPPF-Promi
Mitglied seit
6 Nov 2005
Beiträge
3,655
Punkte für Reaktionen
8
Punkte
38
@schalli: Danke für deinen Tipp. Werde ich ebenfalls testen und darüber berichten, ob es was bringt. Ich habe allerdings dich nicht ganz mit dem Häckchen und DNS-Server verstanden:
a) Default-mäßig ist dieser Hacken doch gesetzt? D.h. deine Empfehlung wäre, den Hacken zu deaktivieren. Richtig?
b) Default-mäßig sind unter "zusätzlich diese Upstream Nameserver nutzen (durch Leerzeichen getrennt):" keine Server eingetragen. Du würdest empfehlen da durch Leerzeichen getrennt beide Google-Server einzutragen? Richtig? Warum eigentlich die von Google? Aber egal...

Was sind deine Erfahrungen in den letzten Tagen zu dem Thema?

Nun zu meinen Beobachtungen und zur Verschwörungstheorie darüber, ob es mit Original-FW (ohne FREETZ) auftreten würde oder nicht.

1. Meine gefreetzte 7490 mit 51-Firmware und Trunk zeigt ähnliches Verhalten, wie hier geschildet. Ich habe die Box letzte Tage etwas näher beobachtet, allerdings noch nicht dazu gekommen, Syslog draußen (oder ins USB-Flash) laufen zu lassen. Wäre aber meine nächste Überlegung gewesen
2. Eine vergleichsweise ähnliche 7490 mit 51-Firmware, allerdings ohne FREETZ läuft bei meinen Eltern stabil und ohne Reboot schon seit etwa 2 Monaten. Meine rebootet dagegen durchschnittlich 1-2 Mal am Tag
3. Ich habe auch eine 7390, die als Zweitbox und DECT-Repeater läuft. Die Box hat einen ähnlichen Trunkstand, wie die 7490, allerdings ist dort dnsmasq deaktiviert. Diese 7390 hat die Rebbots auch nicht
4. Die Reboots passieren typischerweise zu Surfzeiten. Wenn meine subjektive Beobachtung stimmt, dann unmittelbar danach, wenn man eine neue Webseite im Browser aufruft. Wie gesagt, kein Telefonieren oder erhöhter Traffik oder sonstwas, was die Box zu dem Zeitpunkt belastet. Wenn ich es jetzt nachträglich analysiere, würde ich dafür tippen, dass meine Webseiten-Anfrage über den Browser eine DNS-Anfrage generiert, die dann letztendlich die Box über dnsmasq crasht. Also, meine unabhängigen Beobachtungen bestätigen schon die Verschwörungstheorie mit dem dnsmasq...

Eine Frage an die Experten hier: Weiß jemand, was dieses "Nutzen von AVM-Server" physikalisch bedeutet? Fragt dnsmasq beim multid nach diesen Server oder liest er sie aus irgendeiner Datei aus? Oder wird dafür vielleicht doch eine Funktion von multid genutzt? Wofür ist das überhaupt gut?

Ist das Problem vielleicht darin vergraben, dass AVM da wieder was heimlich an ihrem multid gedreht hat, sodass dieses Zusammenspiel zwischen dnsmasq und multid nicht mehr geht?

MfG
 

schalli

Neuer User
Mitglied seit
31 Jul 2006
Beiträge
5
Punkte für Reaktionen
0
Punkte
0
a) Default-mäßig ist dieser Hacken doch gesetzt? D.h. deine Empfehlung wäre, den Hacken zu deaktivieren. Richtig?
Ja genau, Haken bei "Durch AVM/Provider zugewiesene Upstream Nameserver nutzen" muss raus.
Sorry, das ist bei meinem Post nicht rübergekommen.

b) Default-mäßig sind unter "zusätzlich diese Upstream Nameserver nutzen (durch Leerzeichen getrennt):" keine Server eingetragen. Du würdest empfehlen da durch Leerzeichen getrennt beide Google-Server einzutragen? Richtig? Warum eigentlich die von Google? Aber egal...
Ich habe einfach die von Google genommen, weil ich mir deren IPs merken kann.
Kannst es gerne mal mit anderen versuchen, vielleicht wäre es sogar mal interessant, einfach die korrekten, von AVM vorgesehenen Server da einzutragen.
Die Fritzbox behauptet ja schon seit ich dnsmasq benutze, die Server von AVM sind 192.168..., was ja aber nicht stimmen kann.

Was sind deine Erfahrungen in den letzten Tagen zu dem Thema?
Die Box läuft absolut stabil, seit mindestens 19 Tagen.
Sie ist nie abgestürzt, ich hab zwischendurch höchstens mal manuell neu gestartet, weil ich wegen Gewitter den Strom rausgenommen hatte.
 

JanGerrit

Neuer User
Mitglied seit
24 Jan 2006
Beiträge
110
Punkte für Reaktionen
0
Punkte
16
Guten Tag Miteinander,

ich nutze ebenfalls dnsmasq mit freetz (13693M, FW 6.51) und habe keine Probleme, auch bei gesetztem Häkchen "Durch AVM/Provider zugewiesene Upstream Nameserver nutzen" läuft die Box stabil. Ich hatte beim Umstieg auf die FW 6.51 auch erst Probleme, das Problem waren aber zwei Geräte im Netz die Amok liefen (eine IP Kamera mit DNS Anfragen und eine Pogoplug mit DHCP Anfragen). An welchem der beiden Geräte es letztlich lag habe ich nicht weiter verfolgt. Die IP Kamera schickt ihre DNS Abfragen nun ins Nirvana und die Pogoplug hat eine feste IP bekommen, seit dem läuft alles prima.

Viele Grüße,
Jan Gerrit
 
Zuletzt bearbeitet:

hermann72pb

IPPF-Promi
Mitglied seit
6 Nov 2005
Beiträge
3,655
Punkte für Reaktionen
8
Punkte
38
Was heißt denn bei dir "amok laufen"? Betraf das nur die Geräte, oder hat die Box bei dir dabei auch rebootet und es jetzt nicht tut, weil du die Geräte "ruhig gestellt" hast?
Und nein, meine Beobachtung betrifft einen ganz normalen PC mit Win10 und Firefox als Browser. Wie ich oben bereits schrieb, reicht von dem PC dann einen einfachen Aufruf einer neuen Webseite aus.
Achso, welche Box hast du denn eigentlich? Meine Beobachtungen betreffen eine 7490 und ich bin mir nicht sicher, ob dieses Verhalten mit dem Reboot auch auf weiteren Boxen (z.B. 7390) auftritt.
Sollten wir allen ähnliche Boxen haben, würde es sich lohnen im nächsten Schritt .config gegenseitig auszutauschen. Denn wenn dnsmasq alleine nicht der Übeltäter ist, ist es vielleicht eine ungeschickte Kombination mit einem weiteren Paket oder Auswirkung eines der Remove-Patches.

Übrigens, Workarround von schalli scheint bei mir auch zu wirken. Seit mehreren Stunden läuft die Box nun ohne Reboot, trotz recht intensiver Suchaktivitäten im Netz. Ich beobachte weiter...

MfG
 

JanGerrit

Neuer User
Mitglied seit
24 Jan 2006
Beiträge
110
Punkte für Reaktionen
0
Punkte
16
n'Abend Miteinander,


vorab, ja bei mir läuft auch eine 7490 und ja, ich hatte nach dem Umstieg auf die 6.51 auch das Problem das der dnsmasq abgestürzt ist, ob er dabei auch die Box mit in den Tod gerissen hat (oder diese neu startete) weiß ich nicht mehr. Amok laufen heißt, bezogen auf die IP-Cam (welche per Firewall-Regel nicht ins Internet darf), dass diese in einem irrwitzigen Abstand dutzende Domains immer und immer wieder beim DNS Server abgefragt hat. Das zweite Gerät (die Pogoplug) hat ein fehlerhaftes DHCP-Refresh gesendet und dies immer und immer wieder. Zum eingrenzen des Problems wäre ein blick ins Syslog sicher hilfreich, du kannst bei dnsmasq zusätzlich das Häkchen "Namensauflösung loggen" setzen um zu sehen was dort passiert.

Viele Grüße,
Jan Gerrit

PS: ich habe gerade ein Problem mit der Uploadfunktion des Forum, daher werde ich die config.txt später nachreichen.
PPS: Der Anhang will einfach nicht, daher hier nun die Config im Text.
Code:
FREETZ_HAVE_DOT_CONFIG=y
FREETZ_USER_LEVEL_ADVANCED=y
FREETZ_SHOW_ADVANCED=y
FREETZ_TYPE_7490=y
FREETZ_TYPE_LANG_DE=y
FREETZ_TYPE_FIRMWARE_06_5X=y
FREETZ_TYPE_FIRMWARE_FINAL=y
FREETZ_TYPE_LANGUAGE="de"
FREETZ_TARGET_IPV6_SUPPORT=y
FREETZ_REMOVE_DTRACE=y
FREETZ_REMOVE_AVM_E2FSPROGS=y
FREETZ_ADD_ETCSERVICES=y
FREETZ_RESTORE_DEBUG_CFG_SUPPORT=y
FREETZ_AVMDAEMON_DISABLE_NTP=y
FREETZ_AVMDAEMON_DISABLE_MULTIDPORTS=y
FREETZ_AVMDAEMON_DISABLE_DNS=y
FREETZ_AVMDAEMON_DISABLE_DHCP=y
FREETZ_AVMDAEMON_DISABLE_LLMNR=y
FREETZ_PACKAGE_DNSMASQ=y
FREETZ_PACKAGE_DNSMASQ_DISABLE_DNS=y
FREETZ_PACKAGE_DNSMASQ_DISABLE_DHCP=y
FREETZ_PACKAGE_HASERL=y
FREETZ_PACKAGE_INETD=y
FREETZ_PACKAGE_MOD=y
FREETZ_PACKAGE_MOD_ETCSERVICES=y
FREETZ_PACKAGE_MODCGI=y
FREETZ_PACKAGE_OPENVPN=y
FREETZ_PACKAGE_OPENVPN_OPENSSL=y
FREETZ_PACKAGE_OPENVPN_WITH_LZO=y
FREETZ_PACKAGE_OPENVPN_ENABLE_SMALL=y
FREETZ_PACKAGE_UTIL_LINUX=y
FREETZ_WGET=y
FREETZ_PACKAGE_OPENVPN_CGI=y
FREETZ_PACKAGE_SYSLOGD_CGI=y
FREETZ_LIB_libcrypto=y
FREETZ_LIB_libssl=y
FREETZ_OPENSSL_VERSION_PROMPT=y
FREETZ_OPENSSL_VERSION_1=y
FREETZ_OPENSSL_SHLIB_VERSION="1.0.0"
FREETZ_LIB_liblzo2=y
FREETZ_LIB_ld_uClibc=y
FREETZ_LIB_libcrypt=y
FREETZ_LIB_libdl=y
FREETZ_LIB_libm=y
FREETZ_LIB_libpthread=y
FREETZ_LIB_librt=y
FREETZ_LIB_libuClibc=y
FREETZ_LIB_libgcc_s=y
FREETZ_LIB_libctlmgr=y
FREETZ_LIB_libmultid=y
FREETZ_LIB_libmultid_WITH_ANYIP=y
FREETZ_LIB_libmultid_WITH_DNS=y
FREETZ_LIB_libmultid_WITH_DHCP=y
FREETZ_LIB_libmultid_WITH_LLMNR=y
FREETZ_BUSYBOX__MANDATORY=y
FREETZ_BUSYBOX__MANDATORY_05_XX=y
FREETZ_BUSYBOX__IPV6_UTILS=y
FREETZ_BUSYBOX_HAVE_DOT_CONFIG=y
FREETZ_BUSYBOX_PLATFORM_LINUX=y
FREETZ_BUSYBOX_FEATURE_BUFFERS_GO_ON_STACK=y
FREETZ_BUSYBOX_SHOW_USAGE=y
FREETZ_BUSYBOX_FEATURE_VERBOSE_USAGE=y
FREETZ_BUSYBOX_FEATURE_DEVPTS=y
FREETZ_BUSYBOX_FEATURE_PIDFILE=y
FREETZ_BUSYBOX_PID_FILE_PATH="/var/run"
FREETZ_BUSYBOX_FEATURE_SUID=y
FREETZ_BUSYBOX_FEATURE_PREFER_APPLETS=y
FREETZ_BUSYBOX_BUSYBOX_EXEC_PATH="/bin/busybox"
FREETZ_BUSYBOX_FEATURE_SYSLOG=y
FREETZ_BUSYBOX_FEATURE_HAVE_RPC=y
FREETZ_BUSYBOX_LFS=y
FREETZ_BUSYBOX_CROSS_COMPILER_PREFIX=""
FREETZ_BUSYBOX_SYSROOT=""
FREETZ_BUSYBOX_EXTRA_CFLAGS=""
FREETZ_BUSYBOX_EXTRA_LDFLAGS=""
FREETZ_BUSYBOX_EXTRA_LDLIBS=""
FREETZ_BUSYBOX_NO_DEBUG_LIB=y
FREETZ_BUSYBOX_INSTALL_APPLET_SYMLINKS=y
FREETZ_BUSYBOX_PREFIX="./_install"
FREETZ_BUSYBOX_PASSWORD_MINLEN=6
FREETZ_BUSYBOX_MD5_SMALL=1
FREETZ_BUSYBOX_SHA3_SMALL=1
FREETZ_BUSYBOX_FEATURE_USE_TERMIOS=y
FREETZ_BUSYBOX_FEATURE_EDITING=y
FREETZ_BUSYBOX_FEATURE_EDITING_MAX_LEN=1024
FREETZ_BUSYBOX_FEATURE_EDITING_HISTORY=255
FREETZ_BUSYBOX_FEATURE_TAB_COMPLETION=y
FREETZ_BUSYBOX_FEATURE_EDITING_FANCY_PROMPT=y
FREETZ_BUSYBOX_FEATURE_NON_POSIX_CP=y
FREETZ_BUSYBOX_FEATURE_COPYBUF_KB=64
FREETZ_BUSYBOX_FEATURE_SKIP_ROOTFS=y
FREETZ_BUSYBOX_MONOTONIC_SYSCALL=y
FREETZ_BUSYBOX_IOCTL_HEX2STR_ERROR=y
FREETZ_BUSYBOX_FEATURE_HWIB=y
FREETZ_BUSYBOX_FEATURE_SEAMLESS_GZ=y
FREETZ_BUSYBOX_GUNZIP=y
FREETZ_BUSYBOX_BUNZIP2=y
FREETZ_BUSYBOX_UNXZ=y
FREETZ_BUSYBOX_XZ=y
FREETZ_BUSYBOX_BZIP2=y
FREETZ_BUSYBOX_GZIP=y
FREETZ_BUSYBOX_GZIP_FAST=0
FREETZ_BUSYBOX_TAR=y
FREETZ_BUSYBOX_FEATURE_TAR_CREATE=y
FREETZ_BUSYBOX_FEATURE_TAR_FROM=y
FREETZ_BUSYBOX_FEATURE_TAR_OLDGNU_COMPATIBILITY=y
FREETZ_BUSYBOX_FEATURE_TAR_GNU_EXTENSIONS=y
FREETZ_BUSYBOX_UNZIP=y
FREETZ_BUSYBOX_BASENAME=y
FREETZ_BUSYBOX_CAT=y
FREETZ_BUSYBOX_DATE=y
FREETZ_BUSYBOX_FEATURE_DATE_ISOFMT=y
FREETZ_BUSYBOX_FEATURE_DATE_COMPAT=y
FREETZ_BUSYBOX_DD=y
FREETZ_BUSYBOX_FEATURE_DD_SIGNAL_HANDLING=y
FREETZ_BUSYBOX_FEATURE_DD_IBS_OBS=y
FREETZ_BUSYBOX_ID=y
FREETZ_BUSYBOX_GROUPS=y
FREETZ_BUSYBOX_SYNC=y
FREETZ_BUSYBOX_TEST=y
FREETZ_BUSYBOX_TOUCH=y
FREETZ_BUSYBOX_FEATURE_TOUCH_SUSV3=y
FREETZ_BUSYBOX_TR=y
FREETZ_BUSYBOX_FEATURE_TR_CLASSES=y
FREETZ_BUSYBOX_FEATURE_TR_EQUIV=y
FREETZ_BUSYBOX_CHGRP=y
FREETZ_BUSYBOX_CHMOD=y
FREETZ_BUSYBOX_CHOWN=y
FREETZ_BUSYBOX_CHROOT=y
FREETZ_BUSYBOX_CP=y
FREETZ_BUSYBOX_CUT=y
FREETZ_BUSYBOX_DF=y
FREETZ_BUSYBOX_DIRNAME=y
FREETZ_BUSYBOX_DU=y
FREETZ_BUSYBOX_FEATURE_DU_DEFAULT_BLOCKSIZE_1K=y
FREETZ_BUSYBOX_ECHO=y
FREETZ_BUSYBOX_FEATURE_FANCY_ECHO=y
FREETZ_BUSYBOX_ENV=y
FREETZ_BUSYBOX_EXPR=y
FREETZ_BUSYBOX_FALSE=y
FREETZ_BUSYBOX_HEAD=y
FREETZ_BUSYBOX_FEATURE_FANCY_HEAD=y
FREETZ_BUSYBOX_LN=y
FREETZ_BUSYBOX_LOGNAME=y
FREETZ_BUSYBOX_LS=y
FREETZ_BUSYBOX_FEATURE_LS_FILETYPES=y
FREETZ_BUSYBOX_FEATURE_LS_FOLLOWLINKS=y
FREETZ_BUSYBOX_FEATURE_LS_RECURSIVE=y
FREETZ_BUSYBOX_FEATURE_LS_SORTFILES=y
FREETZ_BUSYBOX_FEATURE_LS_TIMESTAMPS=y
FREETZ_BUSYBOX_FEATURE_LS_USERNAME=y
FREETZ_BUSYBOX_MD5SUM=y
FREETZ_BUSYBOX_MKDIR=y
FREETZ_BUSYBOX_MKFIFO=y
FREETZ_BUSYBOX_MKNOD=y
FREETZ_BUSYBOX_MV=y
FREETZ_BUSYBOX_NICE=y
FREETZ_BUSYBOX_NOHUP=y
FREETZ_BUSYBOX_PRINTENV=y
FREETZ_BUSYBOX_PRINTF=y
FREETZ_BUSYBOX_PWD=y
FREETZ_BUSYBOX_READLINK=y
FREETZ_BUSYBOX_FEATURE_READLINK_FOLLOW=y
FREETZ_BUSYBOX_REALPATH=y
FREETZ_BUSYBOX_RM=y
FREETZ_BUSYBOX_RMDIR=y
FREETZ_BUSYBOX_SEQ=y
FREETZ_BUSYBOX_SLEEP=y
FREETZ_BUSYBOX_FEATURE_FANCY_SLEEP=y
FREETZ_BUSYBOX_SORT=y
FREETZ_BUSYBOX_STAT=y
FREETZ_BUSYBOX_FEATURE_STAT_FORMAT=y
FREETZ_BUSYBOX_STTY=y
FREETZ_BUSYBOX_TAIL=y
FREETZ_BUSYBOX_FEATURE_FANCY_TAIL=y
FREETZ_BUSYBOX_TEE=y
FREETZ_BUSYBOX_FEATURE_TEE_USE_BLOCK_IO=y
FREETZ_BUSYBOX_TRUE=y
FREETZ_BUSYBOX_TTY=y
FREETZ_BUSYBOX_UNAME=y
FREETZ_BUSYBOX_UNAME_OSNAME="GNU/Linux"
FREETZ_BUSYBOX_UNIQ=y
FREETZ_BUSYBOX_UUDECODE=y
FREETZ_BUSYBOX_WC=y
FREETZ_BUSYBOX_YES=y
FREETZ_BUSYBOX_FEATURE_AUTOWIDTH=y
FREETZ_BUSYBOX_FEATURE_HUMAN_READABLE=y
FREETZ_BUSYBOX_FEATURE_MD5_SHA1_SUM_CHECK=y
FREETZ_BUSYBOX_FGCONSOLE=y
FREETZ_BUSYBOX_RESET=y
FREETZ_BUSYBOX_SETCONSOLE=y
FREETZ_BUSYBOX_WHICH=y
FREETZ_BUSYBOX_AWK=y
FREETZ_BUSYBOX_CMP=y
FREETZ_BUSYBOX_SED=y
FREETZ_BUSYBOX_VI=y
FREETZ_BUSYBOX_FEATURE_VI_MAX_LEN=1024
FREETZ_BUSYBOX_FEATURE_VI_8BIT=y
FREETZ_BUSYBOX_FEATURE_VI_COLON=y
FREETZ_BUSYBOX_FEATURE_VI_YANKMARK=y
FREETZ_BUSYBOX_FEATURE_VI_SEARCH=y
FREETZ_BUSYBOX_FEATURE_VI_USE_SIGNALS=y
FREETZ_BUSYBOX_FEATURE_VI_DOT_CMD=y
FREETZ_BUSYBOX_FEATURE_VI_READONLY=y
FREETZ_BUSYBOX_FEATURE_VI_SETOPTS=y
FREETZ_BUSYBOX_FEATURE_VI_SET=y
FREETZ_BUSYBOX_FEATURE_VI_WIN_RESIZE=y
FREETZ_BUSYBOX_FEATURE_VI_ASK_TERMINAL=y
FREETZ_BUSYBOX_FEATURE_ALLOW_EXEC=y
FREETZ_BUSYBOX_FIND=y
FREETZ_BUSYBOX_FEATURE_FIND_PRINT0=y
FREETZ_BUSYBOX_FEATURE_FIND_MTIME=y
FREETZ_BUSYBOX_FEATURE_FIND_MMIN=y
FREETZ_BUSYBOX_FEATURE_FIND_PERM=y
FREETZ_BUSYBOX_FEATURE_FIND_TYPE=y
FREETZ_BUSYBOX_FEATURE_FIND_XDEV=y
FREETZ_BUSYBOX_FEATURE_FIND_MAXDEPTH=y
FREETZ_BUSYBOX_FEATURE_FIND_NEWER=y
FREETZ_BUSYBOX_FEATURE_FIND_INUM=y
FREETZ_BUSYBOX_FEATURE_FIND_EXEC=y
FREETZ_BUSYBOX_FEATURE_FIND_USER=y
FREETZ_BUSYBOX_FEATURE_FIND_GROUP=y
FREETZ_BUSYBOX_FEATURE_FIND_NOT=y
FREETZ_BUSYBOX_FEATURE_FIND_DEPTH=y
FREETZ_BUSYBOX_FEATURE_FIND_PAREN=y
FREETZ_BUSYBOX_FEATURE_FIND_SIZE=y
FREETZ_BUSYBOX_FEATURE_FIND_PRUNE=y
FREETZ_BUSYBOX_FEATURE_FIND_PATH=y
FREETZ_BUSYBOX_FEATURE_FIND_REGEX=y
FREETZ_BUSYBOX_GREP=y
FREETZ_BUSYBOX_FEATURE_GREP_EGREP_ALIAS=y
FREETZ_BUSYBOX_FEATURE_GREP_FGREP_ALIAS=y
FREETZ_BUSYBOX_FEATURE_GREP_CONTEXT=y
FREETZ_BUSYBOX_XARGS=y
FREETZ_BUSYBOX_FEATURE_XARGS_SUPPORT_CONFIRMATION=y
FREETZ_BUSYBOX_FEATURE_XARGS_SUPPORT_QUOTES=y
FREETZ_BUSYBOX_FEATURE_XARGS_SUPPORT_TERMOPT=y
FREETZ_BUSYBOX_FEATURE_XARGS_SUPPORT_ZERO_TERM=y
FREETZ_BUSYBOX_HALT=y
FREETZ_BUSYBOX_INIT=y
FREETZ_BUSYBOX_FEATURE_USE_INITTAB=y
FREETZ_BUSYBOX_FEATURE_KILL_REMOVED=y
FREETZ_BUSYBOX_FEATURE_KILL_DELAY=0
FREETZ_BUSYBOX_FEATURE_INIT_SYSLOG=y
FREETZ_BUSYBOX_INIT_TERMINAL_TYPE="linux"
FREETZ_BUSYBOX_FEATURE_SHADOWPASSWDS=y
FREETZ_BUSYBOX_USE_BB_CRYPT=y
FREETZ_BUSYBOX_ADDUSER=y
FREETZ_BUSYBOX_LAST_ID=60000
FREETZ_BUSYBOX_FIRST_SYSTEM_ID=100
FREETZ_BUSYBOX_LAST_SYSTEM_ID=999
FREETZ_BUSYBOX_ADDGROUP=y
FREETZ_BUSYBOX_FEATURE_ADDUSER_TO_GROUP=y
FREETZ_BUSYBOX_DELUSER=y
FREETZ_BUSYBOX_DELGROUP=y
FREETZ_BUSYBOX_FEATURE_DEL_USER_FROM_GROUP=y
FREETZ_BUSYBOX_LOGIN=y
FREETZ_BUSYBOX_PASSWD=y
FREETZ_BUSYBOX_FEATURE_PASSWD_WEAK_CHECK=y
FREETZ_BUSYBOX_CRYPTPW=y
FREETZ_BUSYBOX_FEATURE_DEFAULT_PASSWD_ALGO="des"
FREETZ_BUSYBOX_INSMOD=y
FREETZ_BUSYBOX_RMMOD=y
FREETZ_BUSYBOX_LSMOD=y
FREETZ_BUSYBOX_FEATURE_LSMOD_PRETTY_2_6_OUTPUT=y
FREETZ_BUSYBOX_MODPROBE=y
FREETZ_BUSYBOX_FEATURE_CHECK_TAINTED_MODULE=y
FREETZ_BUSYBOX_DEFAULT_MODULES_DIR="/lib/modules"
FREETZ_BUSYBOX_DEFAULT_DEPMOD_FILE="modules.dep"
FREETZ_BUSYBOX_MOUNT=y
FREETZ_BUSYBOX_FEATURE_MOUNT_VERBOSE=y
FREETZ_BUSYBOX_FEATURE_MOUNT_NFS=y
FREETZ_BUSYBOX_FEATURE_MOUNT_CIFS=y
FREETZ_BUSYBOX_FEATURE_MOUNT_FLAGS=y
FREETZ_BUSYBOX_FEATURE_MOUNT_FSTAB=y
FREETZ_BUSYBOX_BLKID=y
FREETZ_BUSYBOX_FEATURE_BLKID_TYPE=y
FREETZ_BUSYBOX_DMESG=y
FREETZ_BUSYBOX_FEATURE_DMESG_PRETTY=y
FREETZ_BUSYBOX_FLOCK=y
FREETZ_BUSYBOX_GETOPT=y
FREETZ_BUSYBOX_FEATURE_GETOPT_LONG=y
FREETZ_BUSYBOX_MKSWAP=y
FREETZ_BUSYBOX_MORE=y
FREETZ_BUSYBOX_PIVOT_ROOT=y
FREETZ_BUSYBOX_SWAPONOFF=y
FREETZ_BUSYBOX_SWITCH_ROOT=y
FREETZ_BUSYBOX_UMOUNT=y
FREETZ_BUSYBOX_FEATURE_UMOUNT_ALL=y
FREETZ_BUSYBOX_FEATURE_MOUNT_LOOP=y
FREETZ_BUSYBOX_FEATURE_MOUNT_LOOP_CREATE=y
FREETZ_BUSYBOX_VOLUMEID=y
FREETZ_BUSYBOX_FEATURE_VOLUMEID_EXT=y
FREETZ_BUSYBOX_FEATURE_VOLUMEID_FAT=y
FREETZ_BUSYBOX_FEATURE_VOLUMEID_NTFS=y
FREETZ_BUSYBOX_CROND=y
FREETZ_BUSYBOX_FEATURE_CROND_DIR="/var/spool/cron"
FREETZ_BUSYBOX_SETSERIAL=y
FREETZ_BUSYBOX_CRONTAB=y
FREETZ_BUSYBOX_MAKEDEVS=y
FREETZ_BUSYBOX_FEATURE_MAKEDEVS_TABLE=y
FREETZ_BUSYBOX_TIME=y
FREETZ_BUSYBOX_NBDCLIENT=y
FREETZ_BUSYBOX_NC=y
FREETZ_BUSYBOX_NC_EXTRA=y
FREETZ_BUSYBOX_PING=y
FREETZ_BUSYBOX_PING6=y
FREETZ_BUSYBOX_FEATURE_FANCY_PING=y
FREETZ_BUSYBOX_STUN_IP=y
FREETZ_BUSYBOX_WGET=y
FREETZ_BUSYBOX_FEATURE_WGET_STATUSBAR=y
FREETZ_BUSYBOX_FEATURE_WGET_AUTHENTICATION=y
FREETZ_BUSYBOX_FEATURE_WGET_TIMEOUT=y
FREETZ_BUSYBOX_WHOIS=y
FREETZ_BUSYBOX_FEATURE_IPV6=y
FREETZ_BUSYBOX_FEATURE_PREFER_IPV4_ADDRESS=y
FREETZ_BUSYBOX_ARP=y
FREETZ_BUSYBOX_ARPING=y
FREETZ_BUSYBOX_BRCTL=y
FREETZ_BUSYBOX_FEATURE_BRCTL_FANCY=y
FREETZ_BUSYBOX_FEATURE_BRCTL_SHOW=y
FREETZ_BUSYBOX_ETHER_WAKE=y
FREETZ_BUSYBOX_FTPGET=y
FREETZ_BUSYBOX_FTPPUT=y
FREETZ_BUSYBOX_HOSTNAME=y
FREETZ_BUSYBOX_HTTPD=y
FREETZ_BUSYBOX_FEATURE_HTTPD_BASIC_AUTH=y
FREETZ_BUSYBOX_FEATURE_HTTPD_AUTH_MD5=y
FREETZ_BUSYBOX_FEATURE_HTTPD_CGI=y
FREETZ_BUSYBOX_FEATURE_HTTPD_CONFIG_WITH_SCRIPT_INTERPR=y
FREETZ_BUSYBOX_FEATURE_HTTPD_ENCODE_URL_STR=y
FREETZ_BUSYBOX_IFCONFIG=y
FREETZ_BUSYBOX_FEATURE_IFCONFIG_STATUS=y
FREETZ_BUSYBOX_FEATURE_IFCONFIG_HW=y
FREETZ_BUSYBOX_FEATURE_IFCONFIG_BROADCAST_PLUS=y
FREETZ_BUSYBOX_IFUPDOWN=y
FREETZ_BUSYBOX_IFUPDOWN_IFSTATE_PATH="/var/run/ifstate"
FREETZ_BUSYBOX_FEATURE_IFUPDOWN_IFCONFIG_BUILTIN=y
FREETZ_BUSYBOX_FEATURE_IFUPDOWN_IPV4=y
FREETZ_BUSYBOX_FEATURE_IFUPDOWN_IPV6=y
FREETZ_BUSYBOX_FEATURE_IFUPDOWN_MAPPING=y
FREETZ_BUSYBOX_INETD=y
FREETZ_BUSYBOX_IP=y
FREETZ_BUSYBOX_FEATURE_IP_ADDRESS=y
FREETZ_BUSYBOX_FEATURE_IP_LINK=y
FREETZ_BUSYBOX_FEATURE_IP_ROUTE=y
FREETZ_BUSYBOX_FEATURE_IP_ROUTE_DIR="/etc/iproute2"
FREETZ_BUSYBOX_FEATURE_IP_TUNNEL=y
FREETZ_BUSYBOX_FEATURE_IP_RULE=y
FREETZ_BUSYBOX_FEATURE_IP_SHORT_FORMS=y
FREETZ_BUSYBOX_NETSTAT=y
FREETZ_BUSYBOX_FEATURE_NETSTAT_PRG=y
FREETZ_BUSYBOX_NSLOOKUP=y
FREETZ_BUSYBOX_ROUTE=y
FREETZ_BUSYBOX_TELNETD=y
FREETZ_BUSYBOX_FEATURE_TELNETD_STANDALONE=y
FREETZ_BUSYBOX_TFTP=y
FREETZ_BUSYBOX_FEATURE_TFTP_GET=y
FREETZ_BUSYBOX_FEATURE_TFTP_PUT=y
FREETZ_BUSYBOX_TRACEROUTE=y
FREETZ_BUSYBOX_VCONFIG=y
FREETZ_BUSYBOX_IOSTAT=y
FREETZ_BUSYBOX_MPSTAT=y
FREETZ_BUSYBOX_PMAP=y
FREETZ_BUSYBOX_PSTREE=y
FREETZ_BUSYBOX_PWDX=y
FREETZ_BUSYBOX_SMEMCAP=y
FREETZ_BUSYBOX_TOP=y
FREETZ_BUSYBOX_FEATURE_TOP_CPU_USAGE_PERCENTAGE=y
FREETZ_BUSYBOX_FEATURE_TOP_CPU_GLOBAL_PERCENTS=y
FREETZ_BUSYBOX_UPTIME=y
FREETZ_BUSYBOX_FREE=y
FREETZ_BUSYBOX_KILL=y
FREETZ_BUSYBOX_KILLALL=y
FREETZ_BUSYBOX_KILLALL5=y
FREETZ_BUSYBOX_PIDOF=y
FREETZ_BUSYBOX_FEATURE_PIDOF_SINGLE=y
FREETZ_BUSYBOX_FEATURE_PIDOF_OMIT=y
FREETZ_BUSYBOX_PS=y
FREETZ_BUSYBOX_FEATURE_PS_WIDE=y
FREETZ_BUSYBOX_FEATURE_PS_LONG=y
FREETZ_BUSYBOX_RENICE=y
FREETZ_BUSYBOX_BB_SYSCTL=y
FREETZ_BUSYBOX_FEATURE_SHOW_THREADS=y
FREETZ_BUSYBOX_ASH=y
FREETZ_BUSYBOX_ASH_BASH_COMPAT=y
FREETZ_BUSYBOX_ASH_JOB_CONTROL=y
FREETZ_BUSYBOX_ASH_ALIAS=y
FREETZ_BUSYBOX_ASH_GETOPTS=y
FREETZ_BUSYBOX_ASH_BUILTIN_ECHO=y
FREETZ_BUSYBOX_ASH_BUILTIN_PRINTF=y
FREETZ_BUSYBOX_ASH_BUILTIN_TEST=y
FREETZ_BUSYBOX_ASH_CMDCMD=y
FREETZ_BUSYBOX_ASH_OPTIMIZE_FOR_SIZE=y
FREETZ_BUSYBOX_ASH_EXPAND_PRMT=y
FREETZ_BUSYBOX_FEATURE_SH_IS_ASH=y
FREETZ_BUSYBOX_FEATURE_BASH_IS_NONE=y
FREETZ_BUSYBOX_SH_MATH_SUPPORT=y
FREETZ_BUSYBOX_FEATURE_SH_STANDALONE=y
FREETZ_BUSYBOX_FEATURE_SH_NOFORK=y
FREETZ_BUSYBOX_SYSLOGD=y
FREETZ_BUSYBOX_FEATURE_ROTATE_LOGFILE=y
FREETZ_BUSYBOX_FEATURE_REMOTE_LOG=y
FREETZ_BUSYBOX_FEATURE_SYSLOGD_DUP=y
FREETZ_BUSYBOX_FEATURE_SYSLOGD_READ_BUFFER_SIZE=256
FREETZ_BUSYBOX_FEATURE_IPC_SYSLOG=y
FREETZ_BUSYBOX_FEATURE_IPC_SYSLOG_BUFFER_SIZE=16
FREETZ_BUSYBOX_LOGREAD=y
FREETZ_BUSYBOX_FEATURE_LOGREAD_REDUCED_LOCKING=y
FREETZ_BUSYBOX_KLOGD=y
FREETZ_BUSYBOX_FEATURE_KLOGD_KLOGCTL=y
FREETZ_BUSYBOX_LOGGER=y
FREETZ_LANG_DE=y
FREETZ_LANG_STRING="de"
FREETZ_SECURITY_LEVEL=1
FREETZ_STYLE_COLORED=y
FREETZ_STYLE="colored"
FREETZ_SKIN_legacy=y
FREETZ_FAVICON_NONE=y
FREETZ_FAVICON_STRING="none"
FREETZ_TAGGING_NONE=y
FREETZ_TAGGING_STRING="none"
FREETZ_USER_DEFINED_COMMENT=""
FREETZ_CREATE_SEPARATE_OPTIONS_CFG=y
FREETZ_BUILD_TOOLCHAIN=y
FREETZ_KERNEL_BINUTILS_2_24=y
FREETZ_KERNEL_GCC_4_8=y
FREETZ_KERNEL_BINUTILS_VERSION="2.24"
FREETZ_KERNEL_GCC_VERSION="4.8.5"
FREETZ_TARGET_UCLIBC_0_9_33=y
FREETZ_TARGET_UCLIBC_SUPPORTS_libubacktrace=y
FREETZ_TARGET_BINUTILS_2_24=y
FREETZ_TARGET_GCC_4_8=y
FREETZ_TARGET_GCC_DEFAULT_AS_NEEDED=y
FREETZ_STDCXXLIB_USE_UCLIBCXX=y
FREETZ_TARGET_UCLIBC_VERSION="0.9.33.2"
FREETZ_TARGET_BINUTILS_VERSION="2.24"
FREETZ_TARGET_GCC_MAJOR_VERSION="4.8"
FREETZ_TARGET_GCC_MINOR_VERSION="5"
FREETZ_TARGET_GCC_VERSION="${FREETZ_TARGET_GCC_MAJOR_VERSION}.${FREETZ_TARGET_GCC_MINOR_VERSION}"
FREETZ_GNULIBSTDCXX_VERSION="6.0.19"
FREETZ_STDCXXLIB="uclibcxx"
FREETZ_TARGET_CFLAGS="-Os -pipe -Wa,--trap"
FREETZ_RPATH="/usr/lib/freetz"
FREETZ_TARGET_UCLIBC_REDUCED_LOCALE_SET=y
FREETZ_TARGET_LFS=y
FREETZ_TOOLCHAIN_MINIMIZE_REQUIRED_GLIBC_VERSION=y
FREETZ_VERBOSITY_LEVEL=2
FREETZ_SIZEINFO_COMPRESSED=y
FREETZ_JLEVEL=2
FREETZ_CHECK_CHANGED=y
FREETZ_SQUASHFS_BLOCKSIZE_65536=y
FREETZ_SQUASHFS_BLOCKSIZE=65536
FREETZ_STRIP_BINARIES=y
FREETZ_STRIP_MODULES_FREETZ=y
FREETZ_DL_SITE_USER=""
FREETZ_DL_TOOLCHAIN_SITE=""
FREETZ_DL_KERNEL_TOOLCHAIN_VERSION="r13181"
FREETZ_DL_KERNEL_TOOLCHAIN_MD5="6462a9c01566ae63ba6ad7db76037665"
FREETZ_DL_TARGET_TOOLCHAIN_VERSION="r13181"
FREETZ_DL_TARGET_TOOLCHAIN_MD5="05de49e2b2d91e5b3eb1ff4355db6c55"
FREETZ_DL_TOOLCHAIN_SUFFIX="shared-glibc"
FREETZ_DL_KERNEL_SITE=""
FREETZ_DL_KERNEL_SOURCE_ID="7490_06.51"
FREETZ_DL_KERNEL_SOURCE="${FREETZ_DL_KERNEL_SOURCE_ID}-release_kernel.tar.xz"
FREETZ_DL_KERNEL_SOURCE_MD5="e4ed72a1182e7160de95579334685b0b"
FREETZ_DL_SITE="@AVM/fritzbox.7490/firmware/deutsch,@1&1/7490"
FREETZ_DL_SOURCE="FRITZ.Box_7490.113.06.51.image"
FREETZ_DL_SOURCE_MD5="7fb43ce53ba85509fa0c3002a3fe869c"
FREETZ_DL_SOURCE_CONTAINER=""
FREETZ_DL_SOURCE_CONTAINER_MD5=""
FREETZ_AVM_HAS_FIRMWARE_05_5X_VULNERABLE=y
FREETZ_AVM_HAS_FIRMWARE_05_5X=y
FREETZ_AVM_HAS_FIRMWARE_06_0X=y
FREETZ_AVM_HAS_FIRMWARE_06_2X=y
FREETZ_AVM_HAS_FIRMWARE_06_5X=y
FREETZ_AVM_HAS_FIRMWARE_LABOR=y
FREETZ_AVM_HAS_LANG_DE=y
FREETZ_AVM_HAS_LANG_EN=y
FREETZ_AVM_HAS_LANG_EN_BE=y
FREETZ_AVM_HAS_AHA=y
FREETZ_AVM_HAS_DECT=y
FREETZ_AVM_HAS_FHEM=y
FREETZ_AVM_HAS_MYFRITZ=y
FREETZ_AVM_HAS_MULTI_ANNEX=y
FREETZ_AVM_HAS_NAS=y
FREETZ_AVM_HAS_NTFS=y
FREETZ_AVM_HAS_PHONE=y
FREETZ_AVM_HAS_TAM=y
FREETZ_AVM_HAS_TR069=y
FREETZ_AVM_HAS_TR069_FWUPDATE=y
FREETZ_AVM_HAS_UDEV=y
FREETZ_AVM_HAS_UMTS=y
FREETZ_AVM_HAS_USB_HOST=y
FREETZ_AVM_HAS_AURA_USB=y
FREETZ_AVM_HAS_WEBDAV=y
FREETZ_AVM_HAS_WLAN=y
FREETZ_AVM_HAS_IPV6=y
FREETZ_AVM_HAS_PTY_SUPPORT=y
FREETZ_AVM_HAS_PRINTK=y
FREETZ_AVM_HAS_EXT2_BUILTIN=y
FREETZ_AVM_HAS_EXT3_BUILTIN=y
FREETZ_AVM_HAS_EXT4_BUILTIN=y
FREETZ_AVM_HAS_NLS_UTF8_BUILTIN=y
FREETZ_AVM_HAS_RAMZSWAP=y
FREETZ_AVM_HAS_CHRONYD=y
FREETZ_AVM_HAS_E2FSPROGS=y
FREETZ_AVM_HAS_INETD=y
FREETZ_AVM_HAS_LSOF=y
FREETZ_AVM_HAS_OPENSSL=y
FREETZ_AVM_HAS_OPENSSL_VERSION_1=y
FREETZ_AVM_HAS_AR7CFG_V12_MIN=y
FREETZ_AVM_HAS_MULTID_LEASES_FORMAT_V2=y
FREETZ_AVM_HAS_UPDATE_FILESYSTEM_IMAGE=y
FREETZ_AVM_HAS_EXT2_SQUASHFS4_PACKAGING_SCHEME=y
FREETZ_FILESYSTEM_MTD_SIZE=0
FREETZ_AVM_VERSION_06_5X=y
FREETZ_AVM_VERSION_04_XX_MIN=y
FREETZ_AVM_VERSION_05_2X_MIN=y
FREETZ_AVM_VERSION_05_5X_MIN=y
FREETZ_AVM_VERSION_06_0X_MIN=y
FREETZ_AVM_VERSION_06_2X_MIN=y
FREETZ_AVM_VERSION_06_5X_MIN=y
FREETZ_AVM_VERSION_06_5X_MAX=y
FREETZ_TARGET_ARCH_BE=y
FREETZ_TARGET_ARCH="mips"
FREETZ_TARGET_CROSS="${FREETZ_TARGET_ARCH}-linux-uclibc-"
FREETZ_TARGET_MAKE_PATH="toolchain/target/bin"
FREETZ_KERNEL_CROSS="${FREETZ_TARGET_ARCH}-unknown-linux-gnu-"
FREETZ_KERNEL_MAKE_PATH="toolchain/kernel/bin"
FREETZ_AVM_GCC_4_8=y
FREETZ_AVM_GCC_3_4_MIN=y
FREETZ_AVM_GCC_4_6_MIN=y
FREETZ_AVM_GCC_4_7_MIN=y
FREETZ_AVM_GCC_4_8_MIN=y
FREETZ_AVM_GCC_4_8_MAX=y
FREETZ_AVM_GCC_4_9_MAX=y
FREETZ_KERNEL_VERSION_3_10_73=y
FREETZ_KERNEL_VERSION_3_10=y
FREETZ_KERNEL_VERSION="3.10"
FREETZ_KERNEL_VERSION_MAJOR="3.10"
FREETZ_KERNEL_VERSION_2_6_13_MIN=y
FREETZ_KERNEL_VERSION_2_6_19_MIN=y
FREETZ_KERNEL_VERSION_2_6_28_MIN=y
FREETZ_KERNEL_VERSION_2_6_32_MIN=y
FREETZ_KERNEL_VERSION_3_10_MIN=y
FREETZ_KERNEL_VERSION_3_10_MAX=y
FREETZ_KERNEL_LAYOUT_VR9=y
FREETZ_KERNEL_LAYOUT="vr9"
FREETZ_MODULES_KVER="3.10.73"
FREETZ_KERNEL_PATCHES="3.10.73"
FREETZ_AVM_UCLIBC_0_9_33=y
FREETZ_AVM_UCLIBC_NPTL_ENABLED=y
FREETZ_AVM_SOURCE_7490_06_51=y
FREETZ_AVM_SOURCE_ID="7490_06.51"
FREETZ_AVM_SOURCE_FOR_KERNEL_LAYOUT_VR9=y
FREETZ_GCC_ABI="32"
FREETZ_GCC_ARCH="mips32r2"
FREETZ_GCC_TUNE="24kc"
FREETZ_GCC_FLOAT_ABI="soft"
FREETZ_REPLACE_KERNEL_AVAILABLE=y
FREETZ_REPLACE_KERNEL_EXPERIMENTAL=y
FREETZ_REPLACE_MODULE_AVAILABLE=y
FREETZ_TYPE_PREFIX="7490"
FREETZ_TYPE_PREFIX_SERIES_SUBDIR="06_5X"
FREETZ_INSTALL_BASE=y
FREETZ_REPLACE_BUSYBOX=y
FREETZ_CIFS_SUPPORT_AVAILABLE=y
FREETZ_NFS_SUPPORT_NEEDS_REPLACE_KERNEL=y
FREETZ_NFS_SUPPORT_AVAILABLE_AS_MODULE=y
FREETZ_LIBRARY_DIR="/usr/lib/freetz"
 
Zuletzt bearbeitet:

hermann72pb

IPPF-Promi
Mitglied seit
6 Nov 2005
Beiträge
3,655
Punkte für Reaktionen
8
Punkte
38
Die Box läuft bei mir jetzt seit fast zwei Tagen ohne Reboot. Also, scheint es mit den DNS-Servern tatsächlich zu funktionieren.
@JanGerrit: Machst du da noch NFS und replace kernel, oder habe ich was missverstanden? So hart bin ich doch nicht unterwegs. Also, an replace kernel liegt es nicht. Sonst hast du anscheinend genau das alles gewählt, was man sonst wählen würde, wenn man dnsmasq aktiv betreiben will, nämlich alle AVM-DNS-Sachen zu deaktivieren, damit dnsmasq laufen kann.
Auch ich habe OpenVPN und SSL, allerdings momentan nicht gestartet. Von daher würde ich das Thema eigentlich ausschließen.

Zum Log ist so eine Sache... Nicht dass die Box nachher genau deswegen amok läuft, weil es zuviel gelogt wurde. Und zwar egal ob Ringpuffer, RAM oder Netzwerk. Irgendwas kann dabei (oder dadurch) überlaufen oder zum WatchDog-Einsatz führen, weil es zu lange dauert. Von daher bin ich nicht der Befürworter von ausführlichen Logs...

Ich beobachte weiter...

MfG
 

hoewer

Neuer User
Mitglied seit
8 Okt 2018
Beiträge
7
Punkte für Reaktionen
2
Punkte
3
Erstaunlich - ein so alter Thread und die Symptome decken sich dennoch mit den meinen:
Gelegentliche Abstürze und die Logs weisen auf dnsmasq hin; und dabei bin ich inzwischen auf der 7490 mit OS 7.12 unterwegs.

[148209.110000][0]slab error in cache_free_debugcheck(): cache 'dnsmasqentry': double free detected: slabp=8664f000 objp=8664fe30 objnr=35 bufctl=0x15
[148209.110000][0](last freed from 0x816224d4 dnsmasq_rcv_packet+0x2b4/0x840 [kdsldmod] before 5972 jiffies)
[148209.110000][0]CPU: 0 PID: 0 Comm: swapper/0 Tainted: P O 3.10.107 #11
[148209.110000][0]Stack : 00000016 00000001 00000000 00000000 00000000 00000000 808bc0fa 00000041
[148209.110000][0] 00000000 00000000 806f442c 00000000 00000000 81603220 807a8be0 807a8927
[148209.110000][0] 806f442c 00000000 00000000 808bb890 8664f000 81740000 8173a8cc 8004abd8
[148209.110000][0] 00000016 80046dd0 00000000 00000000 806f7b60 80797a5c 80797a5c 807a8be0
[148209.110000][0] 00000000 00000000 00000000 00000000 00000000 00000000 00000000 807979d0
[148209.110000][0] ...
[148209.110000][0]Classified pointer on stack:
[148209.110000][0]808bc0fa textbuf.29255+0x2/0x3e0
[148209.110000][0]806f442c __func__.4154+0x9fcdc/0x11b380
[148209.110000][0]81603220 ctimer_internal_docallouts+0x320/0x5a0 [kdsldmod]
[148209.110000][0]807a8be0 init_task+0x1d0/0x490
[148209.110000][0]807a8927 init_uts_ns+0xc7/0x1a0
[148209.110000][0]808bb890 buf.15871+0x0/0x18
[148209.110000][0]81740000 [page: type:reserved]
[148209.110000][0]80046dd0 print_tainted+0x30/0x100
[148209.110000][0]806f7b60 __func__.4154+0xa3410/0x11b380
[148209.110000][0]80797a5c init_thread_union+0x3a5c/0x4000
[148209.110000][0]80797a5c init_thread_union+0x3a5c/0x4000
[148209.110000][0]807979d0 init_thread_union+0x39d0/0x4000
[148209.110000][0]80116668 __slab_error.isra.17+0x28/0x40
[148209.110000][0]Call Trace:
[148209.110000][0]39d0: [<80021880>] 0x80021880 show_stack+0x80/0xa0
[148209.110000][0]3ab8: [<80116668>] 0x80116668 __slab_error.isra.17+0x28/0x40
[148209.110000][0]3ad0: [<80116b58>] 0x80116b58 cache_free_debugcheck+0x1f8/0x340
[148209.110000][0]3be0: [<80116cf4>] 0x80116cf4 __do_kmem_cache_free+0x54/0x160
[148209.110000][0]3c08: [<81603220>] 0x81603220 ctimer_internal_docallouts+0x320/0x5a0 [kdsldmod]
[148209.120000][0]3c58: [<815a4eec>] 0x815a4eec timer_function+0x2c/0x160 [kdsldmod]
[148209.120000][0]3c78: [<8005ac5c>] 0x8005ac5c call_timer_fn.isra.6+0x3c/0x120
[148209.120000][0]3ca8: [<8005aeec>] 0x8005aeec run_timer_softirq+0x1ac/0x2a0
[148209.120000][0]3cf0: [<80051a64>] 0x80051a64 __do_softirq+0x184/0x300
[148209.120000][0]3d50: [<80051ce8>] 0x80051ce8 do_softirq.part.1+0x68/0xa0
[148209.120000][0]3d68: [<800520b4>] 0x800520b4 irq_exit+0xb4/0x100
[148209.120000][0]3d80: [<80013974>] 0x80013974 hw5_irqdispatch+0x54/0xe0
[148209.120000][0]3da0: [<80002490>] 0x80002490 ret_from_irq+0x0/0x4
[148209.120000][0]3e70: [<8001dd94>] 0x8001dd94 __pastwait+0x0/0xc
[148209.120000][0]3e70: [<8001dd8c>] 0x8001dd8c r4k_wait_irqoff+0x2c/0x34
[148209.120000][0]3e88: [<80091480>] 0x80091480 cpu_startup_entry+0x140/0x1a0
[148209.120000][0]3eb8: [<8086e9b8>] 0x8086e9b8 start_kernel+0x3d8/0x3f4
[148209.120000][0]
[148209.120000][0]double free detected:slabhead 8664f000:
[148209.120000][0]8664f000: 8caff020 8c816000 00000340 8664f340 0000001a 00000019 00006c6f 8664f0c0
[148209.120000][0]slab_bufctl: 8664f020 num=40
[148209.120000][0]8664f020: fffffffe fffffffe 00000027 fffffffe 00000023 fffffffe fffffffe fffffffe
[148209.120000][0]8664f040: fffffffd fffffffd fffffffe fffffffd fffffffe fffffffe fffffffe fffffffe
[148209.120000][0]8664f060: fffffffe fffffffe fffffffe fffffffe fffffffe 0000001b fffffffd fffffffd
[148209.120000][0]8664f080: fffffffd 0000001d 00000026 0000001e 00000024 0000001c 0000001a fffffffd
[148209.120000][0]8664f0a0: fffffffd fffffffd fffffffd<00000015>00000004 ffffffff 00000002 00000025
[148209.120000][0]slab_enh: 8664f0c0
[148209.120000][0]8664f0c0: 81616ee4 00e199a9 81603220 00e1b0ff 81616ee4 00e199aa 81603220 00e1b0ff
[148209.120000][0]8664f0e0: 81616ee4 00e199ad 816224d4 00e199ad 81616ee4 00e199a9 81603220 00e1b0ff
[148209.120000][0]8664f100: 81616ee4 00e199ab 816224d4 00e199ab 81616ee4 00e199aa 81603220 00e1b0ff
[148209.120000][0]8664f120: 81616ee4 00e199aa 81603220 00e1b0ff 81616ee4 00e199a9 81603220 00e1b0ff
[148209.120000][0]8664f140: 81616ee4 00e199ac 816224d4 00e199ab 81616ee4 00e199ac 816224d4 00e199aa
[148209.120000][0]8664f160: 81616ee4 00e199aa 81603220 00e1b0ff 81616ee4 00e199ac 816224d4 00e199ab
[148209.120000][0]8664f180: 81616ee4 00e199aa 81603220 00e1b0ff 81616ee4 00e199a9 81603220 00e1b0ff
[148209.120000][0]8664f1a0: 81616ee4 00e199a9 81603220 00e1b0ff 81616ee4 00e199a9 81603220 00e1b0ff
[148209.120000][0]8664f1c0: 81616ee4 00e199aa 81603220 00e1b0ff 81616ee4 00e199aa 81603220 00e1b0ff
[148209.120000][0]8664f1e0: 81616ee4 00e199aa 81603220 00e1b0ff 81616ee4 00e199aa 81603220 00e1b0ff
[148209.120000][0]8664f200: 81616ee4 00e199aa 81603220 00e1b0ff 81616ee4 00e199aa 816224d4 00e199ab
[148209.120000][0]8664f220: 81616ee4 00e199ab 00000000 00000000 81616ee4 00e199ab 00000000 00000000
[148209.120000][0]8664f240: 81616ee4 00e199ab 00000000 00000000 81616ee4 00e1aa43 816224d4 00e1aa44
[148209.120000][0]8664f260: 81616ee4 00e199ab 816224d4 00e199ad 81616ee4 00e199ab 816224d4 00e199ab
[148209.120000][0]8664f280: 81616ee4 00e199ab 816224d4 00e199ac 81616ee4 00e199ab 816224d4 00e199ac
[148209.120000][0]8664f2a0: 81616ee4 00e199ab 816224d4 00e199ad 81616ee4 00e199ab 00000000 00000000
[148209.120000][0]8664f2c0: 81616ee4 00e199ab 00000000 00000000 81616ee4 00e199ab 00000000 00000000
[148209.120000][0]8664f2e0: 81616ee4 00e199ab 00000000 00000000<81616ee4>00e199ab 816224d4 00e199ab
[148209.120000][0]8664f300: 81616ee4 00e199ab 816224d4 00e199ab 81616ee4 00e199ad 816224d4 00e199ad
[148209.120000][0]8664f320: 81616ee4 00e199ad 816224d4 00e199ad 81616ee4 00e199ad 816224d4 00e199ad
[148228.550000][1]slab error in slab_corrupt(): cache 'dnsmasqentry': corrupt-slab: slabp=810ad8b4 slab->inuse=4294967295 incorrect
[148228.550000][1]CPU: 1 PID: 9178 Comm: dnsmasq Tainted: P B O 3.10.107 #11
[148228.550000][1]Stack : 00000016 00000001 00000000 00000000 00000000 00000000 808bc0fa 00000042
[148228.550000][1] 00000000 00000000 806f442c 00000001 000023da 8c88b440 8f619d30 807a8927
[148228.550000][1] 806f442c 00000001 000023da 808bb890 8fe67ec0 0000003c 8ff52a00 8004abd8
[148228.550000][1] 00000016 80046dd0 00000000 00000000 806f7b60 8674b63c 8674b63c 8f619d30
[148228.550000][1] 00000000 00000000 00000000 00000000 00000000 00000000 00000000 8674b5b0
[148228.550000][1] ...
[148228.550000][1]Classified pointer on stack:
[148228.550000][1]808bc0fa textbuf.29255+0x2/0x3e0
[148228.550000][1]806f442c __func__.4154+0x9fcdc/0x11b380
[148228.550000][1]8c88b440 [slab: type:kmalloc-64 size:64 start:0x8c88b440+0x0]
[148228.550000][1]8f619d30 [task_struct(dnsmasq): 8f619b60+0x1d0]
[148228.550000][1]807a8927 init_uts_ns+0xc7/0x1a0
[148228.550000][1]808bb890 buf.15871+0x0/0x18
[148228.550000][1]8fe67ec0 [slab: type:kmem_cache size:128 start:0x8fe67ec0+0x0]
[148228.550000][1]80046dd0 print_tainted+0x30/0x100
[148228.550000][1]806f7b60 __func__.4154+0xa3410/0x11b380
[148228.550000][1]8674b63c [stack(dnsmasq): 86748000+0x363c]
[148228.550000][1]8674b63c [stack(dnsmasq): 86748000+0x363c]
[148228.550000][1]8674b5b0 [stack(dnsmasq): 86748000+0x35b0]
[148228.550000][1]80116668 __slab_error.isra.17+0x28/0x40
[148228.550000][1]81616ee4 dpenv_cache_alloc+0x24/0x80 [kdsldmod]
[148228.550000][1]Call Trace:
[148228.550000][1]35b0: [<80021880>] 0x80021880 show_stack+0x80/0xa0
[148228.550000][1]3698: [<80116668>] 0x80116668 __slab_error.isra.17+0x28/0x40
[148228.550000][1]36b0: [<8011798c>] 0x8011798c slab_corrupt.constprop.23+0x4c/0x80
[148228.550000][1]3758: [<80117f08>] 0x80117f08 cache_alloc_refill+0x3e8/0x8e0
[148228.550000][1]37b0: [<801188ac>] 0x801188ac kmem_cache_alloc+0x12c/0x1a0
[148228.550000][1]37d8: [<81616ee4>] 0x81616ee4 dpenv_cache_alloc+0x24/0x80 [kdsldmod]
[148228.550000][1]37f8: [<81622d78>] 0x81622d78 dnsmasq_new.constprop.2+0x58/0x120 [kdsldmod]
[148228.550000][1]3830: [<81622ffc>] 0x81622ffc dnsmasq_snd_packet+0x1bc/0x580 [kdsldmod]
[148228.550000][1]3880: [<81623d9c>] 0x81623d9c dnspreconn_snd_packet+0x9c/0xa60 [kdsldmod]
[148228.550000][1]38d8: [<8167c91c>] 0x8167c91c igmpflt_snd_packet+0x7c/0x480 [kdsldmod]
[148228.550000][1]3928: [<816c19dc>] 0x816c19dc ipfw_user_snd_packet+0x39c/0x8a0 [kdsldmod]
[148228.550000][1]3980: [<81664a7c>] 0x81664a7c pingresp_snd_packet+0x7c/0x3a0 [kdsldmod]
[148228.550000][1]39b8: [<8162e92c>] 0x8162e92c defragment_packet_ipv4+0x32c/0xc00 [kdsldmod]
[148228.550000][1]3a28: [<81665ed0>] 0x81665ed0 send_packet_or_frag+0x1b0/0x940 [kdsldmod]
[148228.550000][1]3aa0: [<8162e92c>] 0x8162e92c defragment_packet_ipv4+0x32c/0xc00 [kdsldmod]
[148228.550000][1]3b10: [<815a1be4>] 0x815a1be4 kdsld_net_xmit+0x244/0x560 [kdsldmod]
[148228.550000][1]3b48: [<804d07dc>] 0x804d07dc dev_hard_start_xmit+0x35c/0x620
[148228.550000][1]3b90: [<80505650>] 0x80505650 sch_direct_xmit+0x170/0x300
[148228.550000][1]3bc0: [<804d0d58>] 0x804d0d58 dev_queue_xmit+0x2b8/0x700
[148228.550000][1]3bf8: [<8052654c>] 0x8052654c ip_finish_output+0x24c/0x4a0
[148228.550000][1]3c38: [<80528e18>] 0x80528e18 ip_send_skb+0x18/0xc0
[148228.550000][1]3c58: [<80554bb8>] 0x80554bb8 udp_send_skb+0x118/0x500
[148228.550000][1]3c90: [<80556e60>] 0x80556e60 udp_sendmsg+0x220/0x9c0
[148228.550000][1]3d70: [<804b0d10>] 0x804b0d10 sock_sendmsg+0xd0/0x100
[148228.550000][1]3e38: [<804b3c60>] 0x804b3c60 SyS_sendto+0xc0/0x120
[148228.550000][1]3f10: [<8000491c>] 0x8000491c stack_done+0x20/0x44
[148228.550000][1]
[148228.550000][1]corrupt-slab::slabhead 810ad8b4:
[148228.550000][1]810ad8b4: 8c88b444 8c88b444 8fc015c0 00000080 ffffffff 01ae0fe1 ffffffff 00000001
[148228.550000][1]slab_bufctl: 810ad8d4 num=40
[148228.550000][1]810ad8d4: 85563020 00000200 8fc01ec0 00000080 00000000 00000000 ffffffff 00000001
[148228.550000][1]810ad8f4: 85564000 00000200 8fc01240 00000080 00000000 00000000 ffffffff 00000001
[148228.550000][1]810ad914: 8cb4b700 00000200 8fc01440 00000080 00000000 00000000 ffffffff 00000001
[148228.550000][1]810ad934: 85566000 00000200 8fe677c0 00000080 00000000 00000000 ffffffff 00000001
[148228.550000][1]810ad954: 85567020 00000200 8fc01ec0 00004000 00000000 00000000 ffffffff 00000001
[148228.550000][1]slab_enh: 810ad974
[148228.550000][1]810ad974: 00000100 00000200 00000000 00008000 00000000 00000000 ffffffff 00000000
[148228.550000][1]810ad994: 800d71a0 00000003 810ad960 00008000 00000000 00000000 ffffffff 00000000
[148228.550000][1]810ad9b4: 00000100 00000200 810ad960 00008000 00000000 00000000 ffffffff 00000000
[148228.550000][1]810ad9d4: 00000100 00000200 810ad960 00008000 00000000 00000000 ffffffff 00000000
[148228.550000][1]810ad9f4: 00000100 00000200 810ad960 00008000 00000000 00000000 ffffffff 00000000
[148228.550000][1]810ada14: 00000100 00000200 810ad960 00008000 00000000 00000000 ffffffff 00000000
[148228.550000][1]810ada34: 00000100 00000200 810ad960 00008000 00000000 00000000 ffffffff 00000000
[148228.550000][1]810ada54: 00000100 00000200 810ad960 00004000 00000000 00000000 ffffffff 00000001
[148228.550000][1]810ada74: 00000100 00000200 00000000 00008000 00000000 00000000 ffffffff 00000000
[148228.550000][1]810ada94: 800d71a0 00000003 810ada60 00008000 00000000 00000000 ffffffff 00000000
[148228.550000][1]810adab4: 00000100 00000200 810ada60 00008000 00000000 00000000 ffffffff 00000000
[148228.550000][1]810adad4: 00000100 00000200 810ada60 00008000 00000000 00000000 ffffffff 00000000
[148228.550000][1]810adaf4: 00000100 00000200 810ada60 00008000 00000000 00000000 ffffffff 00000000
[148228.550000][1]810adb14: 00000100 00000200 810ada60 00008000 00000000 00000000 ffffffff 00000000
[148228.550000][1]810adb34: 00000100 00000200 810ada60 00008000 00000000 00000000 ffffffff 00000000
[148228.550000][1]810adb54: 00000100 00000200 810ada60 00004000 00000000 00000000 ffffffff 00000002
[148228.550000][1]810adb74: 00000100 00000200 00000000 00008000 00000000 00000000 ffffffff 00000000
[148228.550000][1]810adb94: 800d71a0 00000003 810adb60 00008000 00000000 00000000 ffffffff 00000000
[148228.550000][1]810adbb4: 00000100 00000200 810adb60 00008000 00000000 00000000 ffffffff 00000000
[148228.550000][1]810adbd4: 00000100 00000200 810adb60 00008000 00000000 00000000 ffffffff 00000000
[148228.550000][1]Kernel panic - not syncing: corrupt-slab: slabp=810ad8b4 slab->inuse=4294967295 incorrect
[148228.550000][1]set_reboot_status: Soft-Reboot(PANIC) - PANIC(2) SUM(2)
-----

Ich werde nun mal den Lösungsansatz mit den hart eingetragenen DNS-Server versuchen... bin gespannt...
 

hermann72pb

IPPF-Promi
Mitglied seit
6 Nov 2005
Beiträge
3,655
Punkte für Reaktionen
8
Punkte
38
Das Thema wurde ausgiebig im anderen Thread diskutiert. Vor ein Paar Tagen hatte ich dort auch eine etwas elegantere Lösung gepostet (basierend auf Ideen von @PeterPawn ), die quasi "live" auf der Box ausprobiert werden kann. Allerdings weise ich hier nochmal ausdrücklich drauf hin, dass die Lösung erstmal nur für den IPV4-Bereich gedacht und getestet ist. IPV6 bedarf einer separaten Untersuchung und Anpassung.
 

hoewer

Neuer User
Mitglied seit
8 Okt 2018
Beiträge
7
Punkte für Reaktionen
2
Punkte
3
Hallo hermann72pb,

vielen Dank für den Hinweis. Keine Ahnung, warum mir der andere Thread selbst nicht aufgefallen ist. Es ist sowohl schön zu hören, dass ich nicht der einzige mit dem Problem bin und noch besser, dass es aktuelle Lösungsansätze gibt. Ich werde mich nächste Woche mal damit beschäftigen. IPv6 spielt in meiner Umgebung derzeit keine Rolle, daher kann ich das Verfahren durchaus mal testen. Du hast den Ablauf ja so gut beschrieben, das auch ein Halbwissender wie ich es anwenden können sollte. Ich muss mir allerdings erstmal ein Freetz mit onlinechanged-cgi bauen.
Langfristig wäre (nach erfolgreichem Testing) eine Freetz-Integration natürlich eleganter.

VG, hoewer
 

Zurzeit aktive Besucher

3CX PBX - GRATIS
Linux / Win / Cloud

Statistik des Forums

Themen
234,463
Beiträge
2,046,950
Mitglieder
354,258
Neuestes Mitglied
EatMyShorts55