[Gelöst] 7490 - immer wieder Neustart (Kernel Panic?) der Box

vice_pres · 24 Okt 2016

Ich hatte nach der Änderung auch keine reboots mehr...

Massa · 2 Nov 2016

vice_pres schrieb:
Ich hatte nach der Änderung auch keine reboots mehr...

Bei mir läuft die Box seit der Änderung absolut stabil - keinerlei Reboots mehr!

Die Frage, die ich mir allerdings immer noch stelle: was ist die Ursache für den Fehler bzw. was muss man machen (patchen), damit es auch bei eingeschalteter automatischen DNS-Übergabe nicht zu Abstürzen / Reboots kommt?

PeterPawn · 2 Nov 2016

Das hängt sicherlich davon ab, wie das bei AVM intern gespeichert ist und worin genau nun der Unterschied zwischen dem manuell festgelegten DNS-Server und dem automatisch eingetragenen besteht (vielleicht sucht AVM ja auch tatsächlich den Fehler in der Speicherverwaltung?) ... aber wenn man ohnehin Freetz auf der Box hat, könnte man ja mit einem eigenen Skript beim "onlinechanged" (hier sind die verschiedenen Möglichkeiten des Aufrufs aber zu beachten, wenn man nicht alles mehrfach machen will) die Server vom Provider auswerten (stehen normalerweise in "/var/tmp/avm-resolv.conf", unabhängig davon, was ansonsten eingestellt ist) und diese dann - wenn sie sich von den bisher verwendeten unterscheiden, soviel "Intelligenz" würde ich dem Skript spendieren - per Kommando setzen.

Die relevanten Settings sind

Code:

dnscfg:settings/ipv4_use_user_dns
dnscfg:settings/ipv4_user_firstdns
dnscfg:settings/ipv4_user_seconddns
dnscfg:settings/ipv6_use_user_dns
dnscfg:settings/ipv6_user_firstdns
dnscfg:settings/ipv6_user_seconddns

- die kann man wahlweise per "luavar" (ich habe mal "queries.lua" und "set.lua" als Beispiele gemacht, man kann das aber auch gleich komplett im Lua-Skript erledigen lassen wie hier) oder per "ctlmgr_ctl" abfragen und setzen. Es müßte sich halt jemand hinsetzen und es machen ...

Massa · 7 Nov 2016

PeterPawn schrieb:
Das hängt sicherlich davon ab, wie das bei AVM intern gespeichert ist und worin genau nun der Unterschied zwischen dem manuell festgelegten DNS-Server und dem automatisch eingetragenen besteht (vielleicht sucht AVM ja auch tatsächlich den Fehler in der Speicherverwaltung?)

das hängt auch davon ab, wie das ausgewertet wird und wie das an dnsmasqd übergeben wird.

PeterPawn schrieb:
... aber wenn man ohnehin Freetz auf der Box hat, könnte man ja mit einem eigenen Skript beim "onlinechanged" (hier sind die verschiedenen Möglichkeiten des Aufrufs aber zu beachten, wenn man nicht alles mehrfach machen will)

Huh? Da bin ich jetzt nicht mitgekommen...

PeterPawn schrieb:
die Server vom Provider auswerten (stehen normalerweise in "/var/tmp/avm-resolv.conf", unabhängig davon, was ansonsten eingestellt ist) und diese dann - wenn sie sich von den bisher verwendeten unterscheiden, soviel "Intelligenz" würde ich dem Skript spendieren - per Kommando setzen.

Wenn ich Dich richtig verstehe, lassen sich über solche onlincechanged-Skripte die DNS-Hosts für den dnsmasqd setzen (bzw. für "jeden" DNS-Server, der in der Box läuft) ?!
Und wie wird das dann tatsächlich an dnsmasqd übergeben?
Wird das in seine Konfiguration geschrieben und dem Prozess dann per HUP-Signal gesagt, dass er diese neu einlesen soll?
Oder wie wird das gemacht?
Mich interessiert an der Stelle, wie das aktuell gemacht ist - bzw. welche Scripte dafür zuständig sind - sind das die lua-Script, die Du gepostet hast?
Wenn da bereits was schief läuft (z.B. weil dem dnsmasq Schrott übergeben wird und der versucht, den Schrott auszuwerten und deshalb abstürzt), bringt es doch nichts, die mit eigenen Werten aufzurufen?!

PeterPawn schrieb:
Es müßte sich halt jemand hinsetzen und es machen ...

Wenn ich mal Zeit und Muße habe (und v.a. verstehe, was Du genau meinst :wink

werde ich mich mal hinsetzen und das ganze analysieren / Scripte schreiben...

PeterPawn · 7 Nov 2016

Ich bin weiterhin der Meinung, daß das Problem nur sehr peripher mit dem "dnsmasq" zu tun hat. Die Funktionen, in denen der Absturz schließlich auftritt, sind ja (die oberen im Stack jedenfalls) im kdsld von AVM und die Frage, was ein Userland-Programm wie der dnsmasq am Ende mit der Slab-Verwaltung im Kernel zu tun haben sollte, ist für mich immer noch ungeklärt.

Woher Dein dnsmasq seinen "uplink server" ermittelt (ich weiß nicht, ob der dnsmasq selbst als rekursiver Resolver arbeitet bzw. so zu konfigurieren wäre - so einer würde sich ggf. von den Root-Servern des DNS selbst zum zuständigen NS für eine Domain durchhangeln und den direkt befragen), muß ja irgendwo konfiguriert werden.

Wenn das kein fixer Server ist, muß das ja schon irgendwo konfiguriert sein oder sogar schon ein solcher Mechanismus existieren.

Es gibt einen "hook" in der Firmware, wo in einen bestimmten Verzeichnis liegende Skript-Dateien beim Wechsel des Online-Status der Box (getrennt nach IPv4 und IPv6, daher das "mehrfach", wenn man die Parameter nicht richtig auswertet) aufgerufen werden - bei AVM liegt dort die (De-)Aktivierung des Online-Speichers und das Versenden von Fehlerprotokollen nach einem Crash. Ich weiß nicht, was das Freetz-Paket zum dnsmasq da macht bzw. ob Du überhaupt dieses Paket verwendest oder doch etwas eigenes.

Die Lua-Dateien, auf die ich mich bezogen habe, sind jedenfalls nur Beispiele, wie man über das Lua-Variableninterface von AVM selbst Werte auslesen und setzen kann. Das dritte ist nur eine Demonstration, wie man etwas auch komplett in Lua- anstelle von Shell-Code realisieren könnte - je nachdem, was man selbst besser beherrscht oder - wenn das einem selbst egal ist - was besser geeignet ist (für die Aufgabenstellung hier hätte ich selbst keine Präferenz).

hermann72pb · 25 Nov 2019

Ich grabe das alte Thema hier wieder raus, weil ich der Meinung bin, dass das hier gemeldete Verhalten immer noch auftritt. Zumindest beobachte ich es auf einer 7490 mit einem relativ aktuellen FREETZ von etwa Anfang Oktober (nähere Informationen kann ich nachliefern, wenn es denn wirklich wichtig ist). dnsmasq ist drin und Workaround aus diesem Thread war bis heute speziell auf dieser 7490 noch nicht aktiviert. Jetzt habe ich es aktiviert und beobachte es weiter, ob die Box trotzdem ab und zu crasht. Die Support-Datei habe ich von der Box heute gezogen und dort einen interessanten Fehler entdeckt:

Code:

[ 1968.640000][0]865be2e0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[ 1968.640000][0]865be300: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[ 1968.640000][0]865be320: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[ 1982.440000][0]slab error in slab_corrupt(): cache 'dnsmasqentry': corrupt-slab: slabp=810ce454 slab->inuse=4294967295 incorrect
[ 1982.440000][0]CPU: 0 PID: 3534 Comm: dnsmasq Tainted: P    B      O 3.10.107 #1
[ 1982.440000][0]Stack : 00000016 00000001 00000000 00000000 00000000 00000000 808dc0fa 00000041
[ 1982.440000][0]      00000000 808e0000 80703ca8 00000000 00000dce 80990000 8fd538a0 807bc907
[ 1982.440000][0]      80703ca8 00000000 00000dce 808db890 8c500740 8c4fa540 8f067e00 8004bd98
[ 1982.440000][0]      00000016 80047c10 00000000 00000000 807076ac 8c4d3634 8c4d3634 8fd538a0
[ 1982.440000][0]      00000000 00000000 00000000 00000000 00000000 00000000 00000000 8c4d35a8
[ 1982.440000][0]      ...
[ 1982.440000][0]Classified pointer on stack:
[ 1982.440000][0]808dc0fa textbuf.29255+0x2/0x3e0
[ 1982.440000][0]80703ca8 __func__.4154+0x9f578/0x11f2d8
[ 1982.440000][0]80990000 capi_controller+0x10/0x80
[ 1982.440000][0]8fd538a0 [task_struct(dnsmasq): 8fd536d0+0x1d0]
[ 1982.440000][0]807bc907 init_uts_ns+0xc7/0x1a0
[ 1982.440000][0]808db890 buf.15871+0x0/0x18
[ 1982.440000][0]8c500740 [slab: type:kmalloc-64 size:64 start:0x8c500740+0x0]
[ 1982.440000][0]8c4fa540 [slab: type:kmem_cache size:128 start:0x8c4fa540+0x0]
[ 1982.440000][0]80047c10 print_tainted+0x30/0x100
[ 1982.440000][0]807076ac __func__.4154+0xa2f7c/0x11f2d8
[ 1982.440000][0]8c4d3634 [stack(dnsmasq): 8c4d0000+0x3634]
[ 1982.440000][0]8c4d3634 [stack(dnsmasq): 8c4d0000+0x3634]
[ 1982.440000][0]8c4d35a8 [stack(dnsmasq): 8c4d0000+0x35a8]
[ 1982.440000][0]8011a928 __slab_error.isra.17+0x28/0x40
[ 1982.440000][0]Call Trace:
[ 1982.440000][0]35a8: [<80021be0>] 0x80021be0 show_stack+0x80/0xa0
[ 1982.440000][0]3690: [<8011a928>] 0x8011a928 __slab_error.isra.17+0x28/0x40
[ 1982.440000][0]36a8: [<8011bc0c>] 0x8011bc0c slab_corrupt.constprop.23+0x4c/0x80
[ 1982.440000][0]3750: [<8011c1a8>] 0x8011c1a8 cache_alloc_refill+0x3e8/0x920
[ 1982.440000][0]37b0: [<8011cb8c>] 0x8011cb8c kmem_cache_alloc+0x12c/0x1a0
[ 1982.450000][0]37d8: [<81654ee4>] 0x81654ee4 dpenv_cache_alloc+0x24/0x80 [kdsldmod]
[ 1982.450000][0]37f8: [<81660d78>] 0x81660d78 dnsmasq_new.constprop.2+0x58/0x120 [kdsldmod]
[ 1982.450000][0]3830: [<81660ffc>] 0x81660ffc dnsmasq_snd_packet+0x1bc/0x580 [kdsldmod]
[ 1982.460000][0]3880: [<81661d9c>] 0x81661d9c dnspreconn_snd_packet+0x9c/0xa60 [kdsldmod]
[ 1982.460000][0]38d8: [<816ba91c>] 0x816ba91c igmpflt_snd_packet+0x7c/0x480 [kdsldmod]
[ 1982.460000][0]3928: [<816ff9dc>] 0x816ff9dc ipfw_user_snd_packet+0x39c/0x8a0 [kdsldmod]
[ 1982.470000][0]3980: [<816a2a7c>] 0x816a2a7c pingresp_snd_packet+0x7c/0x3a0 [kdsldmod]
[ 1982.470000][0]39b8: [<8166c92c>] 0x8166c92c defragment_packet_ipv4+0x32c/0xc00 [kdsldmod]
[ 1982.480000][0]3a28: [<816a3ed0>] 0x816a3ed0 send_packet_or_frag+0x1b0/0x940 [kdsldmod]
[ 1982.480000][0]3aa0: [<8166c92c>] 0x8166c92c defragment_packet_ipv4+0x32c/0xc00 [kdsldmod]
[ 1982.480000][0]3b10: [<815dfbe4>] 0x815dfbe4 kdsld_net_xmit+0x244/0x560 [kdsldmod]
[ 1982.480000][0]3b48: [<804dd29c>] 0x804dd29c dev_hard_start_xmit+0x35c/0x620
[ 1982.480000][0]3b90: [<80512890>] 0x80512890 sch_direct_xmit+0x170/0x300
[ 1982.480000][0]3bc0: [<804dd818>] 0x804dd818 dev_queue_xmit+0x2b8/0x700
[ 1982.480000][0]3bf8: [<8053400c>] 0x8053400c ip_finish_output+0x24c/0x4c0
[ 1982.480000][0]3c38: [<80536938>] 0x80536938 ip_send_skb+0x18/0xc0
[ 1982.480000][0]3c58: [<80562fb8>] 0x80562fb8 udp_send_skb+0x118/0x520
[ 1982.480000][0]3c90: [<805652a0>] 0x805652a0 udp_sendmsg+0x220/0x9c0
[ 1982.480000][0]3d70: [<804bd0d0>] 0x804bd0d0 sock_sendmsg+0xd0/0x100
[ 1982.480000][0]3e38: [<804c0040>] 0x804c0040 SyS_sendto+0xc0/0x120
[ 1982.480000][0]3f10: [<800048b0>] 0x800048b0 stack_done+0x20/0x40
[ 1982.480000][0]
[ 1982.480000][0]corrupt-slab::slabhead 810ce454:
[ 1982.480000][0]810ce454: 8c500744 8c500744 00000000 00000000 ffffffff 01adf2dd ffffffff 00000001
[ 1982.480000][0]slab_bufctl: 810ce474 num=40
[ 1982.480000][0]810ce474: 00000100 00000200 00000000 00000080 00000000 00000000 ffffffff 00000001
[ 1982.480000][0]810ce494: 865c1040 00000200 8fc11e40 00000000 00000000 00000000 ffffffff 00000000

Da die gesamte Support-Datei ziemlich groß ist, poste ich nur diesen Abschnitt hier, der meiner Meinung nach mit dem besagten Crash was zu tun hat.
Entgegen der Meinung von @PeterPawn damals, dass dieses "dnsmasq" im Log mit dem FREETZ-Package nichts zu tun hat, bin ich einer anderen Meinung. Alleine schon deswegen, weil der oben besagte Workaround auf meiner anderen 7490 seit 3 Jahren anscheinend seine Wirkung zeigt.
Da die Kernel-Meldungen nicht meine Stärke sind, würde ich gerne unsere Experten hier dazu befragen, ob ich den zumindest mit meiner Vermutung richtig liege, dass dnsmasq den Crash verursacht.
Ferner nutze ich speziell bei der besagten Box noch die verbotenen IP-Adressen aus dem Bereich (xxx.200-254), die laut dem Thread eigentlich Tabu wären. Ob das in irgendeiner Weise und/oder vielleicht in Kombination zu dem Crash beiträgt, kann ich nur vermuten, glaube aber eigentlich eher weniger.
Sollte ich in den letzten Jahren hier irgendwas übersehen haben, wo das Problem bereits beschrieben wurde, bitte ich mich darauf hinzuweisen. Ich bin leider letzte Zeit relativ selten hier im Forum.

MfG

PeterPawn · 25 Nov 2019

hermann72pb schrieb:
bin ich einer anderen Meinung.

Gibt es dafür auch eine Begründung?

Wenn Du damit die Aussage in Zweifel ziehst, daß die Funktionen im Stacktrace:

hermann72pb schrieb:
[ 1982.450000][0]37f8: [<81660d78>] 0x81660d78 dnsmasq_new.constprop.2+0x58/0x120 [kdsldmod]
[ 1982.450000][0]3830: [<81660ffc>] 0x81660ffc dnsmasq_snd_packet+0x1bc/0x580 [kdsldmod]

nichts mit dem Prozess "dnsmasq" per se zu tun haben, dann wirf doch einfach mal einen Blick auf die Stelle, wo das LKM angezeigt wird, in dem sich diese Funktionen befinden. Diese Funktionen gibt es auf JEDER FRITZ!Box mit einem "(k)dsld" als WAN-Stack - das kann man schon mit einem einfachen "grep" oder einem zur Architektur passenden "objdump" in einer originalen Firmware jederzeit selbst nachprüfen:

Code:

vidar:/home/FritzBox/FB7490/firmware/113.07.11 $ objdump-mips -t lib/modules/3.10.107/kernel/drivers/dsld/kdsldmod.ko | grep dnsmasq
00000000 l    d  .text.dnsmasq_headerhashkey    00000000 .text.dnsmasq_headerhashkey
00000000 l    d  .text.dnsmasq_unhash   00000000 .text.dnsmasq_unhash
00000000 l    d  .text.dnsmasq_rcv_fragquery    00000000 .text.dnsmasq_rcv_fragquery
00000000 l    d  .text.dnsmasq_rcv_packet       00000000 .text.dnsmasq_rcv_packet
00000000 l    d  .text.dnsmasq_expire_timer     00000000 .text.dnsmasq_expire_timer
00000000 l    d  .text.dnsmasq_flush    00000000 .text.dnsmasq_flush
00000000 l    d  .text.dnsmasq_detach   00000000 .text.dnsmasq_detach
00000000 l    d  .text.dnsmasq_attach   00000000 .text.dnsmasq_attach
00000000 l    d  .text.dnsmasq_exit     00000000 .text.dnsmasq_exit
00000000 l    d  .text.dnsmasq_init     00000000 .text.dnsmasq_init
00000000 l    d  .text.dnsmasq_new.constprop.2  00000000 .text.dnsmasq_new.constprop.2
00000000 l    d  .text.dnsmasq_snd_packet       00000000 .text.dnsmasq_snd_packet
00000000 l     F .text.dnsmasq_headerhashkey    00000078 dnsmasq_headerhashkey
00000000 l     F .text.dnsmasq_unhash   000001a4 dnsmasq_unhash
00000000 l     F .text.dnsmasq_rcv_fragquery    000001f4 dnsmasq_rcv_fragquery
00000000 l     F .text.dnsmasq_rcv_packet       00000828 dnsmasq_rcv_packet
0001ecd8 l     O .data  0000000c dnsmasq_entry_cache
00000000 l     F .text.dnsmasq_expire_timer     00000040 dnsmasq_expire_timer
00000000 l     F .text.dnsmasq_flush    00000194 dnsmasq_flush
00000000 l     F .text.dnsmasq_detach   00000060 dnsmasq_detach
00000000 l     F .text.dnsmasq_attach   00000030 dnsmasq_attach
00000000 l     F .text.dnsmasq_exit     00000014 dnsmasq_exit
00000000 l     F .text.dnsmasq_init     00000014 dnsmasq_init
00000000 l     F .text.dnsmasq_new.constprop.2  00000120 dnsmasq_new.constprop.2
00000000 l     F .text.dnsmasq_snd_packet       00000580 dnsmasq_snd_packet
0001ec94 l     O .data  0000003c dnsmasq_module_struct
00000000 l    d  .text.unlikely.dnsmasq_headerhashkey   00000000 .text.unlikely.dnsmasq_headerhashkey
00000000 l    d  .text.unlikely.dnsmasq_unhash  00000000 .text.unlikely.dnsmasq_unhash
00000000 l    d  .text.unlikely.dnsmasq_rcv_fragquery   00000000 .text.unlikely.dnsmasq_rcv_fragquery
00000000 l    d  .text.unlikely.dnsmasq_rcv_packet      00000000 .text.unlikely.dnsmasq_rcv_packet
00000000 l    d  .text.unlikely.dnsmasq_expire_timer    00000000 .text.unlikely.dnsmasq_expire_timer
00000000 l    d  .text.unlikely.dnsmasq_flush   00000000 .text.unlikely.dnsmasq_flush
00000000 l    d  .text.unlikely.dnsmasq_detach  00000000 .text.unlikely.dnsmasq_detach
00000000 l    d  .text.unlikely.dnsmasq_attach  00000000 .text.unlikely.dnsmasq_attach
00000000 l    d  .text.unlikely.dnsmasq_exit    00000000 .text.unlikely.dnsmasq_exit
00000000 l    d  .text.unlikely.dnsmasq_init    00000000 .text.unlikely.dnsmasq_init
00000000 l    d  .text.unlikely.dnsmasq_new.constprop.2 00000000 .text.unlikely.dnsmasq_new.constprop.2
00000000 l    d  .text.unlikely.dnsmasq_snd_packet      00000000 .text.unlikely.dnsmasq_snd_packet
00000000 l    d  .text.unlikely.dp_dnsmasq_print        00000000 .text.unlikely.dp_dnsmasq_print
00000000 l    d  .text.dp_dnsmasq_print 00000000 .text.dp_dnsmasq_print
00000000 l    d  .text.unlikely.dp_dnsmasq_active_entries       00000000 .text.unlikely.dp_dnsmasq_active_entries
00000000 l    d  .text.dp_dnsmasq_active_entries        00000000 .text.dp_dnsmasq_active_entries
00000000 l    d  .text.unlikely.dp_set_dnsmasq_masquerading     00000000 .text.unlikely.dp_set_dnsmasq_masquerading
00000000 l    d  .text.dp_set_dnsmasq_masquerading      00000000 .text.dp_set_dnsmasq_masquerading
00000000 l    d  .text.unlikely.dp_set_dnsmasq_dnsservers       00000000 .text.unlikely.dp_set_dnsmasq_dnsservers
00000000 l    d  .text.dp_set_dnsmasq_dnsservers        00000000 .text.dp_set_dnsmasq_dnsservers
00000000 l    d  .text.unlikely.dp_set_dnsmasq_overwrite_dnsservers     00000000 .text.unlikely.dp_set_dnsmasq_overwrite_dnsservers
00000000 l    d  .text.dp_set_dnsmasq_overwrite_dnsservers      00000000 .text.dp_set_dnsmasq_overwrite_dnsservers
00000000 l    d  .text.unlikely.dp_set_dnsmasq_dnsservers_notifyfunc    00000000 .text.unlikely.dp_set_dnsmasq_dnsservers_notifyfunc
00000000 l    d  .text.dp_set_dnsmasq_dnsservers_notifyfunc     00000000 .text.dp_set_dnsmasq_dnsservers_notifyfunc
00000000 l    d  .text.unlikely.dp_get_dnsmasq_dnsservers       00000000 .text.unlikely.dp_get_dnsmasq_dnsservers
00000000 l    d  .text.dp_get_dnsmasq_dnsservers        00000000 .text.dp_get_dnsmasq_dnsservers
00000000 l    d  .text.unlikely.dp_get_dnsmasq_used_dnsservers  00000000 .text.unlikely.dp_get_dnsmasq_used_dnsservers
00000000 l    d  .text.dp_get_dnsmasq_used_dnsservers   00000000 .text.dp_get_dnsmasq_used_dnsservers
00000000 l    d  .text.unlikely.dp_set_dnsmasq_transparent      00000000 .text.unlikely.dp_set_dnsmasq_transparent
00000000 l    d  .text.dp_set_dnsmasq_transparent       00000000 .text.dp_set_dnsmasq_transparent
00000000 g     F .text.dp_dnsmasq_active_entries        00000078 dp_dnsmasq_active_entries
00000000 g     F .text.dp_set_dnsmasq_masquerading      00000038 dp_set_dnsmasq_masquerading
0001ec90 g     O .data  00000004 dnsmasq_module_desc
00000000 g     F .text.dp_dnsmasq_print 0000005c dp_dnsmasq_print
00000000 g     F .text.dp_set_dnsmasq_dnsservers_notifyfunc     0000000c dp_set_dnsmasq_dnsservers_notifyfunc
00000000 g     F .text.dp_set_dnsmasq_overwrite_dnsservers      00000014 dp_set_dnsmasq_overwrite_dnsservers
00000000 g     F .text.dp_set_dnsmasq_dnsservers        00000014 dp_set_dnsmasq_dnsservers
00000000 g     F .text.dp_set_dnsmasq_transparent       00000034 dp_set_dnsmasq_transparent
00000000 g     F .text.dp_get_dnsmasq_dnsservers        00000028 dp_get_dnsmasq_dnsservers
00000000 g     F .text.dp_get_dnsmasq_used_dnsservers   00000028 dp_get_dnsmasq_used_dnsservers
vidar:/home/FritzBox/FB7490/firmware/113.07.11 $

Selbst die Frage, warum AVM eine "Sonderbehandlung" für einen fremden Daemon in den WAN-Stack einbauen sollte, wenn man diesen Daemon bei AVM weder nutzt noch unterstützt, muß man dabei noch nicht mal stellen (auch wenn sie sich aufdrängt) ... schon die "Systematik" der gefundenen Funktionsnamen zeigt einigermaßen deutlich, daß bei AVM offenbar auch die Aufgabe, die sich aus der Weiterleitung von DNS-Abfragen von LAN-Clients ergibt (und auch die Internet-Zugriffe der Prozesse auf der FRITZ!Box gehen dabei von einer LAN-Adresse aus, wie man jederzeit in den Tabellen des "connection trackings" überprüfen kann), unter dem Label "DNS Masquerading" segelt und man dafür wohl Funktionsnamen verwendet, die ihrerseits die Zeichenkette "dnsmasq" enthalten.

Das heißt zwar noch lange nicht, daß hier nicht tatsächlich ein laufender "dnsmasq"-Prozess gerade zum Fehlerzeitpunkt der aktuelle ist (auch der müßte für seine DNS-Abfragen ja irgendwie durch den WAN-Stack kommen, ansonsten dürfte ihm das "Wissen" um den Rest der Welt fehlen), aber wenn der nicht gerade seinerseits mit falsch formatierten DNS-Abfragen den entsprechenden Code im AVM-WAN-Stack dann doch noch durcheinanderbringt und damit das Problem triggert, handelt es sich hier um einen Fehler in der Speicherverwaltung des Kernels, der durch den "kdsldmod.ko" hervorgerufen wird.

Das sollte dann allerdings auch jeder andere "dnsmasq"-Daemon im LAN auf die Reihe kriegen, wenn es wirklich an den generierten Abfragen läge, was ich stark bezweifele, weil das Problem bereits bei der Zuweisung eines Objekts aus dem SLAB-Cache (für "dnsmasqentry"-Objekte) zuschlägt, auch wenn der eigentliche Fehler wohl schon bei der letzten Freigabe davor auftrat.

So ein Stacktrace wird jedenfalls immer von unten nach oben gelesen, wenn es um die "Reihenfolge" beim Aufruf geht ... denn beim "return" aus einer aufgerufenen Funktion geht es dann in diesem Stack jeweils um einen Schritt "nach unten".

Schaut man sich jetzt die ersten Zeilen im Stacktrace an (der Call-Trace berücksichtigt nur die angesprungenen Funktionen und keine Parameter, die ggf. auch auf den Stack liegen - daher verwendet ich trotzdem "Stacktrace" und "Call-Trace" synonym):

hermann72pb schrieb:
[ 1982.440000][0]Call Trace:
[ 1982.440000][0]35a8: [<80021be0>] 0x80021be0 show_stack+0x80/0xa0
[ 1982.440000][0]3690: [<8011a928>] 0x8011a928 __slab_error.isra.17+0x28/0x40
[ 1982.440000][0]36a8: [<8011bc0c>] 0x8011bc0c slab_corrupt.constprop.23+0x4c/0x80
[ 1982.440000][0]3750: [<8011c1a8>] 0x8011c1a8 cache_alloc_refill+0x3e8/0x920
[ 1982.440000][0]37b0: [<8011cb8c>] 0x8011cb8c kmem_cache_alloc+0x12c/0x1a0
[ 1982.450000][0]37d8: [<81654ee4>] 0x81654ee4 dpenv_cache_alloc+0x24/0x80 [kdsldmod]
[ 1982.450000][0]37f8: [<81660d78>] 0x81660d78 dnsmasq_new.constprop.2+0x58/0x120 [kdsldmod]

, sieht man deutlich, daß im "kdsldmod" als letztes eine Funktion "dpenv_cache_alloc" aufgerufen wurde, die ihrerseits dann "kmem_cache_alloc" aufruft und das stellt dann fest, daß irgendwelche Kontrollelemente für die Speicherverwaltung einen ungültigen Inhalt haben und gibt die entsprechenden Fehlermeldungen aus. Den Teil ab "kmem_cache_alloc" kann man sich sogar wieder in den Kernel-Quellen ansehen (in "mm/slab.c"), denn das ist nicht mehr innerhalb des "kdsldmod", der bekanntlich "Closed Source" ist.

Wer das dann immer noch nicht glaubt, kann ja mal eine Support-Datei einer beliebigen FRITZ!Box mit einer halbwegs aktuellen Firmware-Version durchsuchen ... am besten von einer, auf der tatsächlich eine originale AVM-Firmware oder zumindest eine modifizierte ohne "dnsmasq" installiert ist. Auch dort wird sich beim Durchsuchen der Supportdatei der Objekt-Cache mit dem Namen "dnsmasqentry" finden, in dem offenbar hier im Fehlerfall zuviele Freigaben erfolgen. Das "inuse" mit dem Wert "4294967295" ist wohl am Ende nichts anderes, als ein "underflow" des Zählers in "inuse" (slab.c, Zeile 2934 - ansonsten steht in "inuse" die Anzahl der aktiven Objekte in diesem Cache) und die Tatsache, daß da so eine Riesenzahl erscheint, ist nur dem Umstand geschuldet, daß der Wert hier als "unsigned integer" behandelt wird (slab.c, Zeile 3267).

Was SLAB jetzt für die Kernel-Speicherverwaltung leistet bzw. was das Prinzip dahinter genau bzw. "ausführlich" ist, erkläre ich nicht ... kann man sich mit einfacher Google-Suche selbst ansehen. Für das Verständnis des Problems reicht es aus, wenn man sich das als Caches für kleine Memory-Objekte vorstellt, die immer wieder in schneller Folge angefordert und freigegeben werden und wo man die Verwaltungsinformationen für die dafür verwendeten "Speicherseiten" nur einmalig anlegt/initialisiert - das spart dann am Ende eine aufwändigere Speicherverwaltung über eine MMU, erfordert aber auch eine passende und vor allem dauerhafte "Reservierung" der entsprechenden Speicherseiten (die ja die Verwaltungsinfos für diesen speziellen Cache enthalten) und dieser Platz steht dann i.d.R. nicht für anderes zur Verfügung.

AVM hat jedenfalls bei der SLAB-Verwaltung noch einiges an Protokollierung nachgerüstet und auch diese Infos in aller Ausführlichkeit in die Supportdatei übernommen ... man war/ist dort wohl auf der Suche nach Fehlern beim Anfordern und Freigeben von Kernel-Speicher durch die verschiedenen Module und Prozesse - was angesichts der zusätzlichen Komplexität durch den üblicherweise verwendeten "packet accelerator" schnell mal in die Hose gehen kann und dann unschöne Speicherlecks hinterläßt oder sogar zu den gefürchteten "double frees" führt, die im Kontext von Angriffen immer wieder eine Rolle spielen (wenn hier auch meist auf dem Heap eines Prozesses).

Es kommt hier also offenbar zu einem überzähligen "kmem_cache_free" für einen solchen Cache-Eintrag (wenn ich raten sollte, handelt es sich bei dem "dp" im Namen "dpenv_cache_alloc" um die "deep packet"-Inspektion) und es mag sogar sein, daß der nur dann auftritt, wenn anstelle des "multid" von AVM ein anderes Programm als DNS-Server verwendet wird - nur sollte es dann (sofern nicht doch ein "komisches Format" einer Abfrage durch den "dnsmasq"-Daemon das Ganze erst ins Rollen bringt) mit jedem anderen DNS-Server anstelle des "dnsmasq" ebenso auftreten - vielleicht geschieht das aber auch erst, wenn da etwas "Stress" aufkommt und eine gewisse Anzahl von Abfragen (die dann jeweils ein entsprechendes Objekt aus dem "dnsmasqentry"-Cache brauchen) parallel ausgeführt wird bzw. wurde.
Alternativ wäre noch denkbar, daß da jemand mit diesem Object-Pointer wild in der Gegend herumschreibt und dabei sogar die Verwaltungsinfos der Page löscht ... allerdings wäre dann wohl nicht nur der "inuse"-Counter davon betroffen - das klingt also unwahrscheinlicher als eine überzählige Freigabe, zumal diese durch ein fehlendes Locking für den Cache bei parallelen Aufrufen auch leicht mal als "race condition" auftreten könnte.
Solange nicht jede SLAB-Zuweisung bzw. -Freigabe (also "kmem_cache_alloc" und "kmem_cache_free") dort protokolliert wird (was wohl nur im Debug-Kernel von AVM erfolgt, die "trace_kmem_*"-Funktionen finde ich in den Quellen gar nicht, das muß wohl auf einen Dummy per Pre-Processor hinauslaufen in den veröffentlichten Sourcen), wird man auch Probleme haben, den wirklich schuldigen Code-Teil zu isolieren ... der Teil, wo eine doppelte Freigabe direkt festgestellt würde, wird nur bei aktiviertem "DEBUG"-Symbol eingeschlossen (in slab.c):

C:

2917 static void slab_put_obj(struct kmem_cache *cachep, struct slab *slabp,
2918                                 void *objp, int nodeid)
2919 {
2920         unsigned int objnr = obj_to_index(cachep, slabp, objp);
2921
2922 #if DEBUG
2923         /* Verify that the slab belongs to the intended node */
2924         WARN_ON(slabp->nodeid != nodeid);
2925
2926         if (slab_bufctl(slabp)[objnr] + 1 <= SLAB_LIMIT + 1) {
2927                 printk(KERN_ERR "slab: double free detected in cache "
2928                                 "'%s', objp %p\n", cachep->name, objp);
2929                 BUG();
2930         }
2931 #endif
2932         slab_bufctl(slabp)[objnr] = slabp->free;
2933         slabp->free = objnr;
2934         slabp->inuse--;
2935 }

Dadurch scheppert es erst bei der nächsten Anforderung eines Objekts aus dem Cache ... die dabei zusätzlich ausgeführte Gültigkeitsprüfung für "inuse" stellt dann den zu großen Wert durch den "underrun" fest und bricht an dieser Stelle ab.

Schlauer wäre es, wenn bei der Freigabe/Rückgabe bereits geprüft würde, ob der Zähler vor dem Dekrementieren (in Zeile 2934) schon "0" ist ... dann hat entweder ein Unberechtigter in das "inuse"-Feld geschrieben oder diese SLAB-Seite enthält schon vor der versuchten Freigabe vermeintlich keine weiteren Objekte in diesem Cache.

So erkläre ich mir jedenfalls das Problem ... einen direkten Zusammenhang mit der Verwendung von "dnsmasq" als alternativem DNS-/DHCP-Server kann ich da nur insoweit erkennen, als daß der wohl UDP-Pakete erzeugen wird (und Ausgangspunkt ist hier ein Versuch des Sendens eines UDP-Paketes, wie man weiter unten im Call-Trace sehen kann) und diese dann durch die "deep packet inspection" von AVM einer "Sonderbehandlung" unterzogen werden (warum die notwendig ist, kommt gleich noch). Die im Call-Trace zu sehenden Funktionen wirst Du jedenfalls im "dnsmasq"-Quelltext auch nur mit sehr geringer Wahrscheinlichkeit finden - aber Du kannst es ja mal genauer untersuchen.

Da bei DNS over TLS die DPI durch AVM ja keinen Sinn ergibt (schließlich wäre die Abfrage und die Antwort verschlüsselt), sollte es auch möglich sein, den "dnsmasq" einfach mit DoT zu betreiben (und ohne die 192.168.180.1/192.168.180.2-Adressen als vermeintliche Forwarder) ... auch dann sollte es im "kdsldmod" zumindest nicht in den Teil mit der Sonderbehandlung führen (nochmal: die gilt für DNS-Abfragen per se und hat mit dem "dnsmasq"-Prozess nicht wirklich etwas zu tun - eventuell/wahrscheinlich hingegen mit der notwendigen Umsetzung von 192.168.180.1 auf die erste (bzw. auf die zweite bei .2) DNS-Server-Adresse vom Provider) und - wenn alles gut geht - dann auch nicht zu diesem Fehler kommen.

Was genau AVM den DNS-Paketen da nun als Sonderbehandlung angedeihen läßt, weiß ich naturgemäß auch nicht; ich bin also auf "qualified guessing" angewiesen ... die Funktionsnamen mit Bezug auf "dnsmasq" sollten aber bei jedem auch eigene Vorstellungen auslösen können. Und daß AVM die DNS-Pakete an die 192.168.180.1 und 192.168.180.2 einer solchen Sonderbehandlung unterziehen MUSS, dürfte auch jedem einleuchten ... schließlich stehen diese internen IP-Adressen als Synonym für den ersten und den zweiten DNS-Server, den die Box per DHCP oder LCP/NCP vom Provider "gelernt" hat.

Wenn sie diese Abfragen NICHT selbst per Masquerading auf die korrekten DNS-Adressen umsetzen würde, kämen die wohl nie an. Wofür diese Adressen stehen/benutzt werden, kann auch wieder jeder selbst erkunden (wenn er das mit dem "Synonym für DNS-Server" nicht glauben möchte) ... man braucht nur mal einen Paketmitschnitt auf der Internet-Verbindung starten und dann entsprechende DNS-Abfragen an diese 192.168.180.1/.2 senden.

Eigentlich sollten (zumindest nach meinem bisherigen Verständnis, aber AVM baut wohl daran, DoT in die Box zu kriegen auch ohne "dnsmasq" - da könnte sich also in den neuen Laborversionen etwas ändern) auch nur DNS-Pakete an die 192.168.180.1 und 192.168.180.2 von dieser Sonderbehandlung betroffen sein ... verwendet man - wie im verlinkten Workaround vorgeschlagen - andere DNS-Server, hat der WAN-Stack normalerweise keinen Grund, diese DNS-Pakete irgendwie anders zu behandeln als jedes andere Datenpaket beliebigen Inhalts.

Und wenn ich #26 richtig verstehe, wurden beim Auftreten des Problems wieder die Adressen 192.168.180.1 und 192.168.180.2 benutzt ... ggf. verwendet AVM diese auch gar nicht mehr selbst (schließlich kann der "multid" diese externen DNS-Server-Adressen auch anders ermitteln - wie das machbar wäre, habe ich weiter vorne schon für @Massa beschrieben) und schert sich deshalb mittlerweile einen Dreck um den Fehler in der Behandlung von Abfragen an die 192.168.180.1/192.168.180.2 - zumal das ja offenbar auch nicht bei jedem Request sofort knallt, denn dann käme die Box bei den Betroffenen ja gar nicht mehr aus dem Tee.

Wenn man also meinen Ausführungen nicht glauben will (was das gute Recht eines jeden ist und letztlich kann ich es - mangels "kdsldmod"-Quellen - auch nicht wirklich "beweisen"), dann wäre etwas mehr Argumentation als:

hermann72pb schrieb:
bin ich einer anderen Meinung. Alleine schon deswegen, weil der oben besagte Workaround auf meiner anderen 7490 seit 3 Jahren anscheinend seine Wirkung zeigt.

schon angebracht in meinen Augen ... zumal die Begründung, daß der Fehler bei Nichtbenutzung der 192.168.180.1 bzw. 192.168.180.2 NICHT auftritt, ja nun in keinster Weise im Widerspruch zu dem steht, was ich bisher (und hier erneut) geschrieben habe. Oder wo genau irre ich mich da (und habe das anders beschrieben)? Hier wäre es nett, die konkrete Aussage zu zitieren (und natürlich zu verlinken), die so etwas beinhalten soll.

Die anderen Vorschläge für Workarounds (nämlich das Auslesen der echten IP-Adressen der DNS-Server vom Provider und die Verwendung dieser Adressen anstelle von 192.168.180.1/.2) stehen auch schon weiter vorne in diesem Thread ... man muß also nicht zwangsläufig Google oder Cloudflare oder wen auch immer mit seiner DNS-Historie füttern - man kann (mit etwas eigenem Aufwand, weil man die Server halt nach jeder "Internet-Anmeldung" neu auslesen muß - dafür gibt es oben auch den Hinweis auf "onlinechanged") auch einfach die Provider-Server direkt befragen (dann natürlich wieder nicht über die Option im "dnsmasq"-GUI, weil die ja die 192.168.180.1/.2 verwendet).

hermann72pb · 25 Nov 2019

@PeterPawn : Danke für die ausführliche Antwort und Erklärungen! Nein, ich habe keine solchen Argumente. Mir ging es nur darum, dass damals 2016 die Diskussion in meinen Augen etwas "eingeschlafen" war, ohne, dass es so ausführlich erklärt wurde. Meine etwas andere Meinung galt deinem Nichtglauben, dass es mit dem dnsmasq-Daemon zu tun hat. Ich gebe zu, dass die zu sehenden "dnsmasq"-Einträge im Crash-Log gar nicht mit dem dnsmasq-Daemon erstmal zu tun haben, obwohl es perverser weise irgendwie dadurch hervorgerufen werden. Aber darauf kann ich mit meinem Halbwissen gar nicht kommen. Darum nochmals Danke für Erklärung, warum dnsmasq ungleich dnsmasq ist.
Nun eine Ergänzung konkret zu dem Fall. Der Crash trat auf, als aus dem internen Netz von einem Windows-PC eine VPN-Verbindung zum Uni-Netz aufgebaut wurde. Bzw. sehr vieles deutet darauf, dass die Crashes vermehrt auftreten, wenn diese VPN-Verbindung aufgebaut wird. Passt das nicht zufälligerweise in die von dir gefundene Sonderbetrachtung der UDP-Pakete? Ich kenne derzeit nicht, was das für ein VPN ist, muss erstmal nachschauen. Was ich mir auch in dem Zusammenhang vorstellen kann, sind falsche MTU-Werte, die dann mal gerne ein wiederholtes Senden der Pakete verursachen. Dies würde wiederum in deine These mit wiederholten bzw. vermehrten Anfragen und Parallelinstanzen passen. Denn auch hier wurde neben VPN noch kräftig von einem zweiten Rechner gesurft, was wiederum meine Erfahrungen aus 2016 nur bestätigt.
Kannst du bitte es mit diesen beiden 192.168.180.x-Adressen erklären? Hat man sie damals einfach in die GUI/Einstellungen stumm eingetragen, weil AVM sie früher auch genutzt hat? Nutzt AVM sie mittlerweile nicht mehr? Ich bin da kein DNS-Guru und kenne die Sonderrolle dieser beiden Adressen nicht.
Danke!

PeterPawn · 25 Nov 2019

Als die Benutzung dieser 192.168.180.1/.2 in Freetz Einzug hielt, war ich noch nicht mit Freetz befaßt oder daran interessiert - daher weiß ich auch nicht, woher diese Idee/Entscheidung kommt.

DASS diese beiden Adressen im FRITZ!OS nach wie vor eine Sonderbehandlung erfahren, kann man sich einfach mittels "nslookup" auf einer FRITZ!Box verdeutlichen, wobei es da auch Unterschiede zwischen den Modellen/Plattformen gibt - wobei die wohl eher auf Abweichungen im "nslookup"-Code der BusyBox basieren.

Bash:

root@fb7490:~ $ nslookup
BusyBox v1.27.2 multi-call binary.

Usage: nslookup [HOST] [SERVER]

Query the nameserver for the IP address of the given HOST
optionally using a specified DNS server
root@fb7490:~ $ nslookup ip-phone-forum.de 127.0.0.1
Server:    127.0.0.1
Address 1: 127.0.0.1 localhost

Name:      ip-phone-forum.de
Address 1: 2606:4700:20::681a:7cb
Address 2: 2606:4700:20::681a:6cb
Address 3: 104.26.6.203
Address 4: 104.26.7.203
root@fb7490:~ $ ip address show dev lan
14: lan: <BROADCAST,MULTICAST,UP,LOWER_UP200> mtu 1500 qdisc noqueue
    link/ether 08:96:d7:xx:xx:xx brd ff:ff:ff:ff:ff:ff
    inet 192.168.130.1/28 brd 192.168.130.15 scope global lan
       valid_lft forever preferred_lft forever
    inet 169.254.1.1/16 brd 169.254.255.255 scope global lan:0
       valid_lft forever preferred_lft forever
    inet6 2a02:8109:89xx:xxxx:a96:d7ff:fexx:xxxx/64 scope global dynamic
       valid_lft 6076sec preferred_lft 2476sec
    inet6 fd00::a96:d7ff:fexx:xxxx/64 scope global
       valid_lft forever preferred_lft forever
    inet6 fe80::a96:d7ff:fexx:xxxx/64 scope link
       valid_lft forever preferred_lft forever
root@fb7490:~ $ nslookup ip-phone-forum.de 192.168.180.1
Server:    192.168.180.1
Address 1: 192.168.180.1

Name:      ip-phone-forum.de
Address 1: 2606:4700:20::681a:7cb
Address 2: 2606:4700:20::681a:6cb
Address 3: 104.26.7.203
Address 4: 104.26.6.203
root@fb7490:~ $ nslookup ip-phone-forum.de 192.168.180.2
Server:    192.168.180.2
Address 1: 192.168.180.2

Name:      ip-phone-forum.de
Address 1: 2606:4700:20::681a:6cb
Address 2: 2606:4700:20::681a:7cb
Address 3: 104.26.6.203
Address 4: 104.26.7.203
root@fb7490:~ $ nslookup ip-phone-forum.de 192.168.180.3
Server:    192.168.180.3
Address 1: 192.168.180.3

nslookup: can't resolve 'ip-phone-forum.de': Name or service not known
root@fb7490:~ $ nslookup ip-phone-forum.de 83.169.184.33
Server:    83.169.184.33
Address 1: 83.169.184.33 83-169-184-33-isp.superkabel.de

Name:      ip-phone-forum.de
Address 1: 2606:4700:20::681a:6cb
Address 2: 2606:4700:20::681a:7cb
Address 3: 104.26.7.203
Address 4: 104.26.6.203
root@fb7490:~ $ ip route show | grep 180
192.168.180.1 dev dsl scope link  metric 2
192.168.180.2 dev dsl scope link  metric 2
root@fb7490:~ $

Was sieht man oben?

Das generelle Format des BusyBox-Applets "nslookup", wenn man einen bestimmten DNS-Server befragen will (erst die gesuchte Info, dann die Server-Adresse).
Fragt man den AVM-Forwarder über die "localhost"-Adresse ab, kriegt man eine Antwort ... in dieser ist u.a. auch der DNS-Name des Servers (hier eben "localhost") enthalten, es erfolgt also eine "Rückwärtsauflösung" für den Servernamen.
Die verwendete Box hat NICHT das Netz 192.168.180.0/24 in ihrer LAN-Konfiguration (IPv6-Adressen maskiert, weil sie sowohl die MAC-Adresse der Box als auch die öffentliche IPv6 zeigen würden - die Box hier ist eine 7490, die als kaskadierter Router hinter einer anderen FRITZ!Box am Vodafone-Netz (Cable) hängt).
Eine "nslookup"-Abfrage an 192.168.180.1 liefert trotzdem eine Antwort, ebenso eine solche an 192.168.180.2.
Die gleiche Abfrage an 192.168.180.3 liefert (hier) einen Fehler ... es werden nur die beiden Adressen 192.168.180.1 und 192.168.180.2 gesondert behandelt.
Befragt man direkt einen externen Name-Server (hier einen von Vodafone), wird auch dessen Adresse wieder in einen Namen übersetzt - das erfolgt für diese "Synonyme" 192.168.180.1/.2 nicht, obwohl es auch versucht wird vom Applet (sieht man in einem Packet-Dump, daß da nach passenden PTR-Records gesucht wird für diese beiden Adressen).
Es existieren sogar zwei Host-Routen für diese beiden Adressen in der Routing-Table ... das stellt dann sicher, daß Pakete an eine dieser beiden Adressen auch tatsächlich beim AVM-WAN-Stack ankommen - denn der steckt ja hinter dem "dev dsl".
Fazit: Dem "nslookup"-Applet ist der Unterschied offensichtlich nicht geläufig (es behandelt die beiden Adressen wie jede andere auch) ... daraus folgt ja, daß diese Sonderbehandlung erst im FRITZ!OS-Kernel erfolgen kann - hier halt im "kdsldmod" als nachgeladenes LKM (das ist ja im Prinzip der AVM-eigene WAN-Stack). Ohne eine - wie auch immer geartete - Umsetzung von der 192.168.180.1 auf eine reale Server-Adresse, würde man auch keine Antworten erhalten, wenn man den DNS-Server über eine der beiden speziellen Adressen anspricht - man sieht auch die DNS-Abfragen an den "richtigen" Server im Packet-Dump, wenn man selbst diese spezielle Adresse als DNS-Server befragt.

Ob die Adressen tatsächlich nach wie vor für die beiden Server stehen (zumindest in der Vergangenheit war das m.E. und nach früheren Tests mal so, iirc), kann man leider nur auf einem Edge-Router auch sinnvoll testen ... in einer FRITZ!Box-Kaskade kriegen die kaskadierten Router ja nur dieselben Infos per DHCP, wie jeder andere LAN-Client auch und damit erhalten sie nicht länger zwei DNS-Server zur Auswahl, sondern nur eine einzelne Adresse für den DNS-Server - entweder "automatisch" (für den in der ersten FRITZ!Box) oder als explizite Konfiguration eines Name-Servers für's LAN. Da auch in dieser Konfiguration (also mit nur einem DNS-Server auf der WAN-Seite auf einer kaskadierten Box) die Abfrage über 192.168.180.2 funktioniert, wird es wohl keine 1:1-Zuordnung mehr sein - ansonsten sollte man in dieser Konstellation ja keine Antwort erhalten.

Wie auch immer man das jedenfalls heutzutage angeht mit der "Nachnutzung" von DNS-Server-Adressen ... ich würde mich hier nicht länger auf dieses "DNS Masquerading" von AVM für 192.168.180.1/.2 verlassen (und "Masquerading" bedeutet in diesem Kontext ja nur, daß da Adressen ersetzt werden ... das gibt es als S-NAT und als D-NAT im Linux und bei AVM ist es wohl letzteres an dieser Stelle) und stattdessen lieber die jeweiligen Server direkt befragen.

Erstens umgeht man damit auch DNS-basierte Sperren bei seinem Provider (wenn man einen "offenen" DNS-Server benutzt) oder - wenn man eben gerade die Server des Providers nutzen will - die (mehr oder weniger permanente) Auswahl eines "bevorzugten" DNS-Servers durch das FRITZ!OS (denn von zwei angebotenen Servern wird ja immer einer ausgewählt, wie man auch in der Anzeige im GUI sehen kann und erst wenn der nicht erreichbar ist (und nicht, wenn der "kenne ich nicht" antwortet), wird der andere befragt).

Dann kommt noch hinzu, daß AVM für FRITZ!OS 7 etwas sybillinisch von "Optimierungen zur DNS-Auflösung" redet unter dem Stichwort "Verbesserungen Internet" - was das am Ende genau bedeutet und wie sich damit FRITZ!OS 7 von den vorherigen Versionen unterscheidet, muß man wohl erst wieder mühsam erkunden ... das ist etwas, wozu ich so gar keine Lust habe. Mir reicht die Feststellung, daß diese beiden Adressen nach wie vor irgendwie gesondert behandelt werden (die Tests oben, sind alle mit der 113.07.11 erfolgt) und man daher nach Kräften vermeiden sollte, eine LAN-Konfiguration mit 192.168.180.0/24 zu verwenden. Punkt.

Alles andere, was AVM da noch verbrechen könnte im Hinblick auf Veränderungen des Datenverkehrs, kann man eben vermeiden, wenn man diese Adressen gar nicht erst benutzt. Die Vermutung, daß das alter, grottiger und lange schon nicht mehr gepflegter Code im WAN-Stack ist, erscheint mir nicht soooo abwegig ... es gibt so viele "Dreckecken" in der Firmware (bei Skript-Code - von Shell bis Lua - kann man sich das halt genauer ansehen, beim Rest muß man sich auf Funktionsnamen in Libraries o.ä. stützen), daß so ein Überbleibsel aus längst vergangenen Tagen alles andere als überraschend wäre.

hermann72pb · 30 Nov 2019

@PeterPawn : Entschuldige meine verspätete Antwort. Da ich mit dem Workaround die immer wieder rebootete Box doch erstmal zum Schweigen gebracht habe, war das Problem an der Stelle schon nicht mal so akut. Heute bin ich endlich wieder auf das Thema zurück gekommen. Diesmal bei meiner eigener Box, die bereist seit Jahren diesen Google-DNS-Workaround verwendet. Heute ging es mir eigentlich um das Thema DNS allgemein, und ich wollte die GOOGLE-Server endlich los werden. Deine Idee aus #23 wird direkt und unmittelbar so nicht funktionieren und zwar aus folgenden Gründen.
1. Zumindest bei meiner 7490 mit 7.12-Firmware und FREETZ habe ich nicht in ar7.cfg (und auch nicht über ctlmgr_ctl) die oben angedeutete Section gefunden, dafür aber:

Code:

servercfg {
        hostname = "meinebox";
        dhcpc_hostname = "fritz.box";
        dns1 = 192.168.180.1;
        dns2 = 192.168.180.2;
        dns_rebind_protection_excepted_domains = "box", "meinebox.domain.tld",
                                                 "home.domain.tld",
                                                 "meinebox.domain.tld";
        use_user_dns_for_ipv4 = no;
        user_dns1_for_ipv4 = 0.0.0.0;
        user_dns2_for_ipv4 = 0.0.0.0;
        use_user_dns_for_ipv6 = no;
        user_dns1_for_ipv6 = ::;
        user_dns2_for_ipv6 = ::;
        wpad_protection = yes;
}

Vermutlich liest dnsmasq-Paket genau diese beiden dns1- und dns2-Einträge.
2. Das, was du oben meintest, wären vermutlich "user_dns1_for_ipv4" und "user_dns2_for_ipv4"-Einträge, die bei mir ja 0.0.0.0 sind, weil automatisch vom Provider zugewiesen. Von daher wäre es wahrscheinlich blöd, diese 0.0.0.0-Werte da auszulesen und dem dnsmasq-Paket mitzuteilen. Darum sollte man schon irgendwie an die dynamisch vom Provider zugewiesen Werte kommen.

Übrigens, IPV6 macht mein Provider gar nicht, was in diesem Fall die Sache zunächst etwas erleichtert, weil man sich nur auf IPV4 voll konzentrieren kann.

Ich vermute mal, dass AVM diese beiden 180-IPs quasi als Mapping-Adressen (entschuldige diese Umgangsbezeichnung) verwendet, damit man darüber an die dynamischen DNS des Providers kommt. Oder zumindest hat AVM es vielleicht früher zu den Urzeiten so gemacht.

Wie kommen wir anders an diese dynamischen DNS-Server des Providers?

PeterPawn · 30 Nov 2019

ctlmgr_ctl u dnsserver
- sollte ab 06.8x funktionieren.

EDIT: Das mit dem "u" natürlich nur, um erst mal die Werte zu erkunden ... abfragen ist mit "l" oder "r" dann einfacher (oder gleich über "luavar").

hermann72pb · 30 Nov 2019

Danke! Mit "u" kannte ich es bis jetzt noch gar nicht.

Code:

ctlmgr_ctl u dnsserver
dnsserver:status/
 dnsserver0/
  state=enabled
  addr=AAA.BBB.CCC.DDD # ausgeblendet
  tcclass=dns
  domains=
 dnsserver1/
  state=enabled
  addr=AAA.BBB.CCC.EEE # ausgeblendet
  tcclass=dns
  domains=

Und das Auslesen mit:

Code:

ctlmgr_ctl r dnsserver dnsserver:status/dnsserver0/addr
ctlmgr_ctl r dnsserver dnsserver:status/dnsserver1/addr

Bleibt nur die Frage, wo man es am Besten hinpackt. Temporär zunächst mal irgendwohin in "onlinechanged"-Skript (ich schleppe es glücklicherweise immer mit durch all meine Images, obwohl ich es bis jetzt kaum benutzt hatte). Ich suche noch die passende Stelle im dnsmasq-Paket, um die Werte da hin zu schreiben und danach natürlich

Code:

/etc/init.d/rc.dnsmasq restart

Wenn ich es fertig habe und es funktioniert, poste ich hier das neue Workaround für "onlinechanged".

PeterPawn · 1 Dez 2019

Wobei man das in der Realität vermutlich gar nicht wiederholt auslesen muß (oder zumindest nicht immer ändern) ... nur der erste Versuch und damit der Start des "dnsmasq"-Servers sollte so lange verzögert werden, bis die erste Internet-Verbindung steht, denn erst dann sind die Adressen gültig. Dazu ist dann "onlinechanged" sicherlich sinnvoll als Mechanismus ... aber man muß jetzt nicht beim "offline gehen" bzw. bei jeder neuen Verbindung auch den "dnsmasq" stoppen (unter Verlust der Einträge in einem Cache) und neu konfiguriert starten.

Zumindest nicht, solange sich die Adressen nicht geändert haben ... was in der Realität nur sehr selten der Fall sein wird, weil wohl kein Provider regelmäßig seine DNS-Adressen wechselt und wenn es da tatsächlich mal ein "Pooling" (oder auch eine Failover-Lösung) gibt, ist das meist ein Loadbalancer unter ebendieser IP-Adresse, von dem die Kunden ohnehin nichts bemerken.

Wenn man also nicht bei jeder neuen Internetverbindung auch den DNS-Cache "verlieren" will (oder bei einem Internetausfall gar den ganzen "dnsmasq", der ja häufig auch der DNS-Server fürs LAN ist), prüft man vor dem Stoppen/Rekonfigurieren/Starten des "dnsmasq" als erstes, ob sich tatsächlich etwas an der Konfiguration ändern würde, was beim Reboot i.d.R. ja impliziert ist.

Am besten startet man den "dnsmasq" sogar unabhängig vom Zustand der Internetverbindung nach einem Reboot immer erst einmal ohne Upstream-Server (damit er im LAN immer verfügbar ist, auch wenn das Internet klemmt) und nimmt das erste "online" zum Anlaß, die Konfiguration entsprechend zu ändern.

Vielleicht findet man im Handbuch zum "dnsmasq" sogar eine Möglichkeit, den Daemon ohne Cache-Verlust einfach nur zum Reload der Einstellungen zu veranlassen ... das wäre dann der sauberste und effektivste Weg. Irgendwo habe ich (von den Untersuchungen beim Problem mit der Uhrzeit und der Validierung von DNSSEC-Antworten) im Hinterkopf einen Aufbau des "dnsmasq"-Codes, bei dem tatsächlich fast alles neu konfiguriert werden kann über irgendein Signal (also mit einem "kill -<signal> <pid>").

hermann72pb · 1 Dez 2019

Du vergisst Peter, dass dnsmasq da als Ersatz von multid fungiert und damit man dem multid den Wind aus den Segeln nimmt, nutzt man da einen Wrapper dafür, der dnsmasq zu einem relativ frühen Zeitpunkt startet. Zumindest war das früher so, wenn ich mich richtig an die dunklen Zeiten vor 10-14 Jahren erinnere (ja, solange ist es schon her). Von daher dnsmasq zu Beginn verzögern, wäre keine so wirklich gute Idee. "Never touch a running system!" so zu sagen.
An "reload" hatte ich auch gedacht, als ich meine Experimente hier gerade veranstaltet habe. Ich hatte sogar nie "restart" genutzt und mit sh -x den rc.dnsmasq beim reload getrackt. Und ja, es genügt vollkommen: Er liest diese Adressen beim "reload" aus.
Ich bin gerade dabei einen so genannten "Live Patch" zu basteln und zu testen. Da ich schon lange mich mit dem sed nicht beschäftigt habe, hat es alleine schon 1-2 Stunden gedauert, eine passende sed-Sequenz zu schreiben, die all diese Sonderzeichen a-la | und Co. erkennt und richtig ersetzt. Gerade vor 5 Minuten hat es endlich geklappt. Ich teste mein Script und poste es nachher hier für die Allgemeinheit. Dann hast du wieder genügend Stoff dich hier über meine Misskünste in Shell-Programmierung zu amüsieren.
Das reloaden von dnsmasq ist von meinem "Live Patch" unabhängig und kann auch z.B. in rc.custom platziert werden oder komplett weg gelassen werden. Die richtigen Provider-Adressen werden jetzt in der dnsmasq-cgi korrekt angezeigt. Man kann ja auch die von dort auslesen und per copy-paste in die "custom" eintragen und dann sie dauerhaft nutzen, wenn das ständige reloaden nerven sollte.

PeterPawn · 1 Dez 2019

hermann72pb schrieb:
dnsmasq da als Ersatz von multid fungiert

Das ist nicht zwingend ... FREETZ_PACKAGE_DNSMASQ_DISABLE_DNS ist eine optionale Einstellung und ein geänderter Ablauf sollte natürlich alle Eventualitäten berücksichtigen.

Wobei ich ohnehin der Meinung war, daß sich an der Startreihenfolge gar nichts ändert ... iirc wird nur verhindert, daß sich der "multid" schon früher den DNS-Port krallt und damit kann der "dnsmasq" den auch nachträglich noch nutzen. Aber das ist auch nur aus dem Gedächtnis ... das jetzt im Source-Code nachzuverfolgen (wenn sich die Startdateien bei den Paketen auf die "files"-Verzeichnisse verteilen), ist mir zu kompliziert - das geht mit einem fertigen Image dann einfacher.

Findet da tatsächlich ein so früher Start statt (das sollte man in einem Freetz-Log ja sehen, wann der von wo gestartet wurde), ist das ja ähnlich dem Fall, wo (aus welchem Grund auch immer) eine Weile keine Internetverbindung zustande kommt - auch da könnte/sollte man ja erst mal ohne Upstream-Server starten (das verhindert auch, daß zu diesem Zeitpunkt Anfragen erst auf ein Timeout von einem Upstream-Server warten, wenn der "dnsmasq" gar kein Forwarder ist und nur lokale Zonen verwaltet) und erst beim "online" dann die Konfiguration ändern. Genau das war bisher aber nicht notwendig, weil wohl der "dsld" von AVM dann selbst gleich abgewunken hat, wenn man von 192.168.180.1 irgendetwas wollte und noch gar keine Internetverbindung bestand.

Nur sind das eben zwei unabhängige Ereignisse (zumindest wenn man den "dnsmasq" auch ohne Internetverbindung als lokalen DNS-Server nutzen will) und deren Synchronisation ist nicht trivial ... spätestens wenn das o.a. Symbol nicht gesetzt ist in der Konfiguration, kann niemand vorhersagen, ob zuerst der "dnsmasq" gestartet werden soll (die anderen Freetz-Services starten ja erst am Ende der Initialisierung) oder ob die Box zuerst online geht (das macht der "dsld" bei seinem Start und das ist damit - iirc - schon in Gruppe 4) und damit Erfolg hat.

Das ist aber auch kein Grund für irgendein Amüsement meinerseits (hier verwechselst Du ohnehin Hinweise auf Verbesserungspotential mit (Schaden-)Freude über die Existenz eines solchen) ... das ist sogar ein einigermaßen kompliziertes Gebilde, wenn man das tatsächlich für alle bereits existierenden Konfigurationsoptionen sauber umsetzen will. Hier treffen sequentielle (init-Abarbeitung) und event-getriebene Abläufe (Online-Verbindung) aufeinander ... das macht die Synchronisation nicht wirklich einfacher.

Denn mit Shell-Kommandos ist es auch nicht ganz trivial, so etwas wie eine sichere "locked region" in der Ausführung zu kreieren - besonders blöd ist es nämlich, wenn beide Aktionen gar nicht nacheinander, sondern sogar parallel ablaufen ... was durchaus auch vorkommen kann.

Dann muß man schon entscheiden, wer jetzt welche Konfiguration schreibt und wer so lange wartet, bis der andere "fertig" ist - ansonsten hat man die schönste "race condition", wenn das "onlinechanged"-Skript da DNS-Forwarder einträgt und das (schon gestartete, aber von anderen Prozessen unterbrochene) Start-Skript für den DNS-Server die danach wieder mit einer anderen Konfiguration überschreibt, wenn es wieder zum Zuge kommt.

Für die Aufnahme ins Freetz-Repo muß man das dann wohl auch noch auf aktuelle Versionen beschränken ... schon das "ctlmgr_ctl r dnsserver ..." funktioniert bei älteren Versionen nicht. Dafür geht dort dann halt die Verwendung der 192.168.180.1/.2 vermutlich wieder - ich weiß jedenfalls nicht, seit wann das bei AVM zu diesem Problem führt ... aber der entsprechende Trace-Code in der SLAB-Verwaltung wird vermutlich auch erst mit Kernel 3.10 Einzug gehalten haben (reine Vermutung, also nur "geraten").

hermann72pb · 1 Dez 2019

Live-Patch zum Einlesen providerspezifischer DNS

Voraussetzungen:
- Firmware >= 6.86
- FREETZ mit dnsmasq
- "dnsmasq vor multid starten" als Option ausgewählt
- onlinechanged ist in FREETZ integriert

Vorbereitungen:
a1)
- Angehängte Datei als .sh-Datei auf der Box z.B. auf einer ext2-Partition (z.B. USB-Stick) platzieren und mit chmod 755 ausführbar machen
- Danach den Pfad zur Datei in rc.custom (über FREETZ-WebIF) eintragen

oder

a2) Den Inhalt der angehängten Datei (ausgenommen erster Zeile mit #!/bin/sh) in rc.custom (über FREETZ-WebIF) eintragen

danach

b) In der "online"-Sektion von onlinechanged (über FREETZ-WebIF) Folgendes eintragen:

Code:

   provider_dns1=$(ctlmgr_ctl r dnsserver dnsserver:status/dnsserver0/addr)
   provider_dns2=$(ctlmgr_ctl r dnsserver dnsserver:status/dnsserver1/addr)
   dns1_match=$(cat /mod/etc/dnsmasq.conf | sed -ne "/^server=$provider_dns1/p")
   dns2_match=$(cat /mod/etc/dnsmasq.conf | sed -ne "/^server=$provider_dns2/p")
   [ -z "$dns1_match" -o -z "$dns2_match" ] && /etc/init.d/rc.dnsmasq restart

c) Die Box rebooten und ggf. die Logs beobachten. Wie man erkennt, ob die providerspezifischen Server richtig eingetragen wurden, steht weiter unten.

@PeterPawn : Das ist nur online live Patch, wie bereits oben erwähnt. Vor einer wirklichen Integration in FREETZ sollte man natürlich deine Bedenken gründlich überprüfen, mein Bauchgefühl sagt mir aber, dass in 99% der Fälle es schon klappen würde, wenn man z.B. die alten Firmware-Versionen auf irgendeine Art und Weise abfängt. Man kann diese Veränderung auch als optional anbieten, dann ist jeder erwachsen genug, um zu entscheiden, ob und wie er es verwendet.
Bzgl. dnsmasq vor multid. Ja, es ist zumindest bei mir so. Der dnsmasq wird sogar gestartet, bevor mein Patch überhaupt in der Lage ist, aus rc.custom da was zu verändern. Daher stehen am Anfang da die alten 180-ger Server:

Code:

/var/mod/root# cat /mod/etc/dnsmasq.conf
domain-needed
log-async=10
no-resolv
server=192.168.180.1
server=192.168.180.2
bogus-priv
dhcp-range=192.168.178.20,192.168.178.200,12h
domain=meine.domain.tld
expand-hosts
read-ethers
stop-dns-rebind
log-queries
### content of /tmp/flash/dnsmasq/dnsmasq.extra

Zu dem Zeitpunkt funktioniert aber die interne DNS-Auflösung, DHCP-Leases werden auch vom dnsmasq fleißig vergeben. Er wartet also nicht.
Da bei mir nach dem reboot ziemlich lange dauert (3-5 Minuten), bis mein VDSL ausgehandelt ist und die Verbindung steht, ändert es sich irgendwann mal zu:

Code:

/var/mod/root# cat /mod/etc/dnsmasq.conf
domain-needed
log-async=10
no-resolv
server=XXX.YYY.ZZZ.AAA
server=XXX.YYY.ZZZ.AAA
bogus-priv
dhcp-range=192.168.178.20,192.168.178.200,12h
domain=meine.domain.tld
expand-hosts
read-ethers
stop-dns-rebind
log-queries
### content of /tmp/flash/dnsmasq/dnsmasq.extra

Speziell für meinen Fall scheint es zu funktionieren. Ich werde es noch auf 3-5 weiteren Boxen testen, die sich in meinem Betreuungsbereich befinden. Dort gibt es neben 7490 einige 7390 und sogar eine 7590. Provider und SYNC-Bedingungen sind auch unterschiedlich. Von daher wird die Praxis dann zeigen, ob es mit diesem Workaround zuverlässig funktioniert. Wenn es noch jemand testen würde, wäre er herzlich dazu eingeladen.

MfG

hermann72pb · 1 Dez 2019

Ich schreibe es hier separat, um die Diskussion von dem Posting mit dem eigentlichen Vorschlag abzutrennen. In dem Posting #36 werde ich die Informationen natürlich nachträglich ändern, sobald ich aus meinen Tests weitere Erkenntnisse gewinne.

Nun eröffne ich wieder die Diskussion. Wie @PeterPawn zurecht angezweifelt hat, wäre es zu einfach, wenn alles auf einmal funktionieren würde. Ich hatte mich gestern doch etwas zu früh gefreut. Nachdem ich relativ spät abends mit dem Scripten und posten hier fertig war, wollte ich noch mal kurz im Internen nach ein Paar Sachen googeln, die ich auswählen und bestellen wollte. Hierbei ist mir die Box mehrfach abgestürzt. Diesmal meine eigene. Also, das Verhalten ist wie vor ein Paar Postings oben hier reproduzierbar. Diesmal durch ein bloßes Surfen (ohne VPN und andere Sachen) und das Aufrufen mehrerer Webseiten (Google, Ebay, etc.). Hier ist der Auszug aus meiner Support-Datei mit den alten Verdächtigen "dnsmasqentry" und "slab":

Code:

[ 1001.680000][0]slab error in cache_free_debugcheck(): cache 'dnsmasqentry': corrupt-slab: slabp=8c450020 objp=8c450450 objnr=3 bufctl=0xffffffff
[ 1001.680000][0]CPU: 0 PID: 0 Comm: swapper/0 Tainted: P           O 3.10.107 #1
[ 1001.680000][0]Stack : 00000016 00000001 00000000 00000000 00000000 00000000 808dc0fa 00000040
[ 1001.680000][0]      00000000 808e0000 80703ca8 00000000 00000000 81641220 807bcbc0 807bc907
[ 1001.680000][0]      80703ca8 00000000 00000000 808db890 8c450020 81780000 817788cc 8004bd98
[ 1001.680000][0]      00000016 80047c10 00000000 00000000 807076ac 807aba5c 807aba5c 807bcbc0
[ 1001.680000][0]      00000000 00000000 00000000 00000000 00000000 00000000 00000000 807ab9d0
[ 1001.680000][0]      ...
[ 1001.680000][0]Classified pointer on stack:
[ 1001.680000][0]808dc0fa textbuf.29255+0x2/0x3e0
[ 1001.680000][0]80703ca8 __func__.4154+0x9f578/0x11f2d8
[ 1001.680000][0]81641220 ctimer_internal_docallouts+0x320/0x5a0 [kdsldmod]
[ 1001.680000][0]807bcbc0 init_task+0x1d0/0x490
[ 1001.680000][0]807bc907 init_uts_ns+0xc7/0x1a0
[ 1001.680000][0]808db890 buf.15871+0x0/0x18
[ 1001.680000][0]81780000 [page: type:reserved]
[ 1001.680000][0]80047c10 print_tainted+0x30/0x100
[ 1001.680000][0]807076ac __func__.4154+0xa2f7c/0x11f2d8

Meine Vermutung (ohne, dass ich es jetzt geprüft habe): Das Reloaden von dnsmasq bewirkt vermutlich nicht das Ändern der "server"-Einträge oder speziell in der FREETZ-Umsetzung läuft etwas mit dem reloaden schief. Ich hatte mich gestern schön auf die Config-Datei verlassen (s. oben) unter der Vermutung, dass wenn sie schon mal neu generiert wurde, dann wird sie ja auch hoffentlich neu eingelesen sein. Die Praxis zeigt, dass es doch nicht so einfach ist...
Nächste Schritte:
1. Ich mache zunächst mal restart von dnsmasq und beobachte, ob dadurch die crashes erstmal weg sind. Vermutlich wird das schon mal helfen.
2. Langfristig sollte man sich schon etwas Intelligentes überlegen, damit man dnsmasq nur dann restartet, wenn die DNS-Einträge sich wirklich geändert haben und nicht bei jedem DSL-recsync oder -reconect. Da hat @PeterPawn schon Recht.

Ich melde mich wieder, wenn ich weitere Erkenntnisse habe.

Edit1: Ich habe im Netz einige Bestätigungen dazu gefunden, dass beim reload von dnsmasq die conf-Datei nicht neu eingelesen wird (2004 und 2009). Es ist zwar schon etwas her, ich glaube aber nicht, dass an den neuen Versionen etwas Grundsätzliches diesbezüglich geändert wurde. Also, es bleibt beim restart und ich schreibe eine kleine Erkennung, ob zumindest einer der beiden DNS sich geändert hat und dann "rc.dnsmasq restart".

Edit2: Für die "online"-Sektion von "onlinechanged" habe ich nun anstelle von "reload" die Erkennung eingebaut. Die Anleitung oben ist entsprechend angepasst.

hoewer · 24 Dez 2019

Ich habe das Skript von @hermann72pb (vielen Dank für die Mühe) seit ca. 1 Woche im Einsatz und es funktioniert bislang tadellos. Trotz diverser Experimente (Neuverbinden, Leitung zurücksetzen, neues Image einspielen etc.) gab es keinen außerplanmäßigen Crash mehr.
Einzige Einschränkung dieser Bewertung ist, das - entsprechend der Einschätzung von @PeterPawn aus Post #33 - mein Provider seine kundenseitigen DNS-Server bislang nicht verändert hat; der Funktionsnachweis für diesen Fall stünde also eigentlich noch aus. Doch aufgrund der Funktionsweise des Skript habe ich da eigentlich keine Bedenken...

[Gelöst] 7490 - immer wieder Neustart (Kernel Panic?) der Box

Mitglied

Mitglied

IPPF-Urgestein

Mitglied

IPPF-Urgestein

IPPF-Promi

IPPF-Urgestein

IPPF-Promi

IPPF-Urgestein

IPPF-Promi

IPPF-Urgestein

IPPF-Promi

IPPF-Urgestein

IPPF-Promi

IPPF-Urgestein

IPPF-Promi

Anhänge

IPPF-Promi

Neuer User

Statistik des Forums