iptables in ds26-14.3 stützt ab

[olistudent]

Nach 1.30h Laufzeit tauchen erste seltsame Einträge im Syslog auf:

/ $ logread
Apr 26 18:08:32 fritz user.warn kernel: printk: 7 messages suppressed.
Apr 26 18:08:32 fritz user.warn kernel: ip_conntrack: table full, dropping packet.
Apr 26 18:08:32 fritz user.warn kernel: ip_conntrack: table full, dropping packet.
Apr 26 18:08:32 fritz user.warn kernel: ip_conntrack: table full, dropping packet.
Apr 26 18:08:32 fritz user.warn kernel: ip_conntrack: table full, dropping packet.
Apr 26 18:08:32 fritz user.warn kernel: ip_conntrack: table full, dropping packet.
Apr 26 18:08:32 fritz user.warn kernel: ip_conntrack: table full, dropping packet.
Apr 26 18:08:32 fritz user.warn kernel: ip_conntrack: table full, dropping packet.
Apr 26 18:08:38 fritz user.warn kernel: printk: 11 messages suppressed.
Apr 26 18:08:38 fritz user.warn kernel: ip_conntrack: table full, dropping packet.
Apr 26 18:08:43 fritz user.warn kernel: printk: 8 messages suppressed.
Apr 26 18:08:43 fritz user.warn kernel: ip_conntrack: table full, dropping packet.
Apr 26 18:08:48 fritz user.warn kernel: printk: 8 messages suppressed.
Apr 26 18:08:48 fritz user.warn kernel: ip_conntrack: table full, dropping packet.
Apr 26 18:08:53 fritz user.warn kernel: printk: 2 messages suppressed.
Apr 26 18:08:53 fritz user.warn kernel: ip_conntrack: table full, dropping packet.
Apr 26 18:08:58 fritz user.warn kernel: printk: 2 messages suppressed.
Apr 26 18:08:58 fritz user.warn kernel: ip_conntrack: table full, dropping packet.
Apr 26 18:09:06 fritz user.warn kernel: printk: 2 messages suppressed.
Apr 26 18:09:06 fritz user.warn kernel: ip_conntrack: table full, dropping packet.
Apr 26 18:09:06 fritz user.err kernel: extract_dst: dev dsl not of type ETHER
Apr 26 18:09:07 fritz user.warn kernel: printk: 2 messages suppressed.
Apr 26 18:09:07 fritz user.warn kernel: ip_conntrack: table full, dropping packet.
Apr 26 18:09:12 fritz user.warn kernel: printk: 4 messages suppressed.
Apr 26 18:09:12 fritz user.warn kernel: ip_conntrack: table full, dropping packet.
Apr 26 18:09:18 fritz user.warn kernel: printk: 8 messages suppressed.
Apr 26 18:09:18 fritz user.warn kernel: ip_conntrack: table full, dropping packet.
Apr 26 18:09:23 fritz user.warn kernel: printk: 3 messages suppressed.
Apr 26 18:09:23 fritz user.warn kernel: ip_conntrack: table full, dropping packet.
Apr 26 18:09:28 fritz user.err multid[2080]: mrouter: lan: send general v3 query failed (len=12) - Operation not permitted (1)
Apr 26 18:09:28 fritz user.warn kernel: printk: 3 messages suppressed.
Apr 26 18:09:28 fritz user.warn kernel: ip_conntrack: table full, dropping packet.
Apr 26 18:09:33 fritz user.warn kernel: printk: 6 messages suppressed.
Apr 26 18:09:33 fritz user.warn kernel: ip_conntrack: table full, dropping packet.
Apr 26 18:09:38 fritz user.warn kernel: printk: 3 messages suppressed.
Apr 26 18:09:38 fritz user.warn kernel: ip_conntrack: table full, dropping packet.
Apr 26 18:11:24 fritz user.warn kernel: printk: 3 messages suppressed.
Apr 26 18:11:24 fritz user.warn kernel: ip_conntrack: table full, dropping packet.
Apr 26 18:11:24 fritz user.warn kernel: ip_conntrack: table full, dropping packet.
Apr 26 18:11:24 fritz user.warn kernel: ip_conntrack: table full, dropping packet.
Apr 26 18:11:24 fritz user.warn kernel: ip_conntrack: table full, dropping packet.
Apr 26 18:11:24 fritz user.warn kernel: ip_conntrack: table full, dropping packet.
Apr 26 18:11:24 fritz user.warn kernel: ip_conntrack: table full, dropping packet.
Apr 26 18:11:24 fritz user.warn kernel: ip_conntrack: table full, dropping packet.
Apr 26 18:11:24 fritz user.warn kernel: ip_conntrack: table full, dropping packet.
Apr 26 18:11:24 fritz user.warn kernel: ip_conntrack: table full, dropping packet.
Apr 26 18:11:24 fritz user.warn kernel: ip_conntrack: table full, dropping packet.
Apr 26 18:11:29 fritz user.notice free:               total         used         free       shared      buffers
Apr 26 18:11:29 fritz user.notice free:   Mem:        30368        27480         2888            0         1492
Apr 26 18:11:29 fritz user.notice free:  Swap:            0            0            0
Apr 26 18:11:29 fritz user.notice free: Total:        30368        27480         2888
Apr 26 18:11:29 fritz user.notice meminfo: MemFree:          2912 kB
Apr 26 18:11:29 fritz user.notice meminfo: Cached:          10320 kB
Apr 26 18:11:29 fritz user.notice meminfo: SwapFree:            0 kB
Apr 26 18:11:29 fritz user.notice tffs: fill=73
Apr 26 18:11:29 fritz user.notice conntrack-wc-l: 128
Apr 26 18:11:29 fritz user.notice slabinfo: # name            <active_objs> <num_objs> <objsize> <objperslab> <pagesperslab> : tunables <limit> <batchcount> <sharedfactor> : slabdata <active_slabs> <num_slabs> <sharedavail>
Apr 26 18:11:29 fritz user.notice slabinfo: ip_conntrack_expect      0      0     88   45    1 : tunables  120   60    0 : slabdata      0      0      0
Apr 26 18:11:29 fritz user.notice slabinfo: ip_conntrack         133    144    248   16    1 : tunables  120   60    0 : slabdata      9      9      0
Apr 26 18:11:29 fritz user.warn kernel: printk: 16 messages suppressed.
Apr 26 18:11:29 fritz user.warn kernel: ip_conntrack: table full, dropping packet.
Apr 26 18:11:33 fritz user.err multid[2080]: mrouter: lan: send general v3 query failed (len=12) - Operation not permitted (1)
Apr 26 18:11:35 fritz user.warn kernel: printk: 7 messages suppressed.
Apr 26 18:11:35 fritz user.warn kernel: ip_conntrack: table full, dropping packet.
Apr 26 18:11:40 fritz user.warn kernel: printk: 3 messages suppressed.
Apr 26 18:11:40 fritz user.warn kernel: ip_conntrack: table full, dropping packet.
Apr 26 18:11:49 fritz user.warn kernel: printk: 2 messages suppressed.
Apr 26 18:11:49 fritz user.warn kernel: ip_conntrack: table full, dropping packet.
Apr 26 18:11:52 fritz user.warn kernel: printk: 2 messages suppressed.
Apr 26 18:11:52 fritz user.warn kernel: ip_conntrack: table full, dropping packet.
Apr 26 18:11:55 fritz user.warn kernel: printk: 5 messages suppressed.
Apr 26 18:11:55 fritz user.warn kernel: ip_conntrack: table full, dropping packet.
Apr 26 18:12:00 fritz user.warn kernel: printk: 5 messages suppressed.
Apr 26 18:12:00 fritz user.warn kernel: ip_conntrack: table full, dropping packet.
Apr 26 18:12:06 fritz user.warn kernel: printk: 6 messages suppressed.
Apr 26 18:12:06 fritz user.warn kernel: ip_conntrack: table full, dropping packet.
Apr 26 18:12:11 fritz user.warn kernel: printk: 3 messages suppressed.
Apr 26 18:12:11 fritz user.warn kernel: ip_conntrack: table full, dropping packet.
Apr 26 18:12:16 fritz user.warn kernel: printk: 3 messages suppressed.
Apr 26 18:12:16 fritz user.warn kernel: ip_conntrack: table full, dropping packet.
Apr 26 18:12:21 fritz user.warn kernel: printk: 4 messages suppressed.
Apr 26 18:12:21 fritz user.warn kernel: ip_conntrack: table full, dropping packet.
Apr 26 18:12:25 fritz user.warn kernel: printk: 2 messages suppressed.
Apr 26 18:12:25 fritz user.warn kernel: ip_conntrack: table full, dropping packet.
Apr 26 18:12:31 fritz user.warn kernel: printk: 12 messages suppressed.
Apr 26 18:12:31 fritz user.warn kernel: ip_conntrack: table full, dropping packet.
Apr 26 18:12:37 fritz user.warn kernel: printk: 3 messages suppressed.
Apr 26 18:12:37 fritz user.warn kernel: ip_conntrack: table full, dropping packet.
Apr 26 18:12:43 fritz user.warn kernel: printk: 2 messages suppressed.
Apr 26 18:12:43 fritz user.warn kernel: ip_conntrack: table full, dropping packet.
Apr 26 18:12:46 fritz user.warn kernel: printk: 3 messages suppressed.
Apr 26 18:12:46 fritz user.warn kernel: ip_conntrack: table full, dropping packet.
Apr 26 18:12:51 fritz user.warn kernel: printk: 2 messages suppressed.
Apr 26 18:12:51 fritz user.warn kernel: ip_conntrack: table full, dropping packet.
Apr 26 18:13:06 fritz user.warn kernel: printk: 2 messages suppressed.
Apr 26 18:13:06 fritz user.warn kernel: ip_conntrack: table full, dropping packet.
Apr 26 18:13:06 fritz user.warn kernel: ip_conntrack: table full, dropping packet.
Apr 26 18:13:06 fritz user.warn kernel: ip_conntrack: table full, dropping packet.
Apr 26 18:13:17 fritz user.warn kernel: printk: 2 messages suppressed.
Apr 26 18:13:17 fritz user.warn kernel: ip_conntrack: table full, dropping packet.
Apr 26 18:13:17 fritz user.warn kernel: ip_conntrack: table full, dropping packet.
Apr 26 18:13:24 fritz user.warn kernel: printk: 2 messages suppressed.
Apr 26 18:13:24 fritz user.warn kernel: ip_conntrack: table full, dropping packet.
Apr 26 18:13:27 fritz user.warn kernel: printk: 2 messages suppressed.
Apr 26 18:13:27 fritz user.warn kernel: ip_conntrack: table full, dropping packet.
Apr 26 18:13:33 fritz user.warn kernel: printk: 3 messages suppressed.
Apr 26 18:13:33 fritz user.warn kernel: ip_conntrack: table full, dropping packet.
Apr 26 18:13:37 fritz user.warn kernel: printk: 2 messages suppressed.
Apr 26 18:13:37 fritz user.warn kernel: ip_conntrack: table full, dropping packet.
Apr 26 18:13:38 fritz user.debug kernel: mcfw: group 0.0.0.0: query cpmac:0,1,2,3 10sec
Apr 26 18:13:45 fritz user.warn kernel: printk: 3 messages suppressed.
Apr 26 18:13:45 fritz user.warn kernel: ip_conntrack: table full, dropping packet.
Apr 26 18:13:45 fritz user.warn kernel: ip_conntrack: table full, dropping packet.
Apr 26 18:13:54 fritz user.warn kernel: printk: 5 messages suppressed.
Apr 26 18:13:54 fritz user.warn kernel: ip_conntrack: table full, dropping packet.
Apr 26 18:13:57 fritz user.warn kernel: printk: 2 messages suppressed.
Apr 26 18:13:57 fritz user.warn kernel: ip_conntrack: table full, dropping packet.
Apr 26 18:15:43 fritz user.debug kernel: mcfw: group 0.0.0.0: query cpmac:0,1,2,3 10sec
Apr 26 18:15:50 fritz user.warn kernel: printk: 2 messages suppressed.
Apr 26 18:15:50 fritz user.warn kernel: ip_conntrack: table full, dropping packet.
Apr 26 18:16:18 fritz user.err igdd[977]: 0.0.0.0:1900: failed to send UDP-datagram to 239.255.255.250:1900 - Operation not permitted (1)
Apr 26 18:16:18 fritz user.err igdd[977]: 0.0.0.0:1900: failed to send UDP-datagram to 239.255.255.250:1900 - Operation not permitted (1)
Apr 26 18:16:18 fritz user.err igdd[977]: 0.0.0.0:1900: failed to send UDP-datagram to 239.255.255.250:1900 - Operation not permitted (1)
Apr 26 18:16:18 fritz user.err igdd[977]: 0.0.0.0:1900: failed to send UDP-datagram to 239.255.255.250:1900 - Operation not permitted (1)
Apr 26 18:16:18 fritz user.err igdd[977]: 0.0.0.0:1900: failed to send UDP-datagram to 239.255.255.250:1900 - Operation not permitted (1)
Apr 26 18:16:18 fritz user.err igdd[977]: 0.0.0.0:1900: failed to send UDP-datagram to 239.255.255.250:1900 - Operation not permitted (1)
Apr 26 18:16:18 fritz user.err igdd[977]: 0.0.0.0:1900: failed to send UDP-datagram to 239.255.255.250:1900 - Operation not permitted (1)
Apr 26 18:16:18 fritz user.err igdd[977]: 0.0.0.0:1900: failed to send UDP-datagram to 239.255.255.250:1900 - Operation not permitted (1)
Apr 26 18:16:18 fritz user.err igdd[977]: 0.0.0.0:1900: failed to send UDP-datagram to 239.255.255.250:1900 - Operation not permitted (1)
Apr 26 18:16:18 fritz user.err igdd[977]: 0.0.0.0:1900: failed to send UDP-datagram to 239.255.255.250:1900 - Operation not permitted (1)
Apr 26 18:16:18 fritz user.err igdd[977]: 0.0.0.0:1900: failed to send UDP-datagram to 239.255.255.250:1900 - Operation not permitted (1)
Apr 26 18:16:18 fritz user.warn kernel: ip_conntrack: table full, dropping packet.
Apr 26 18:16:18 fritz user.warn kernel: ip_conntrack: table full, dropping packet.
Apr 26 18:16:18 fritz user.warn kernel: ip_conntrack: table full, dropping packet.
Apr 26 18:16:18 fritz user.warn kernel: ip_conntrack: table full, dropping packet.
Apr 26 18:16:18 fritz user.warn kernel: ip_conntrack: table full, dropping packet.
Apr 26 18:16:18 fritz user.warn kernel: ip_conntrack: table full, dropping packet.
Apr 26 18:16:18 fritz user.warn kernel: ip_conntrack: table full, dropping packet.
Apr 26 18:16:18 fritz user.warn kernel: ip_conntrack: table full, dropping packet.
Apr 26 18:16:18 fritz user.warn kernel: ip_conntrack: table full, dropping packet.
Apr 26 18:16:18 fritz user.warn kernel: ip_conntrack: table full, dropping packet.
Apr 26 18:16:18 fritz syslog.info -- MARK --
Apr 26 18:16:29 fritz user.notice free:               total         used         free       shared      buffers
Apr 26 18:16:29 fritz user.notice free:   Mem:        30368        27516         2852            0         1492
Apr 26 18:16:29 fritz user.notice free:  Swap:            0            0            0
Apr 26 18:16:29 fritz user.notice free: Total:        30368        27516         2852
Apr 26 18:16:29 fritz user.notice meminfo: MemFree:          2912 kB
Apr 26 18:16:29 fritz user.notice meminfo: Cached:          10320 kB
Apr 26 18:16:29 fritz user.notice meminfo: SwapFree:            0 kB
Apr 26 18:16:29 fritz user.notice tffs: fill=73
Apr 26 18:16:30 fritz user.notice conntrack-wc-l: 128
Apr 26 18:16:30 fritz user.notice slabinfo: # name            <active_objs> <num_objs> <objsize> <objperslab> <pagesperslab> : tunables <limit> <batchcount> <sharedfactor> : slabdata <active_slabs> <num_slabs> <sharedavail>
Apr 26 18:16:30 fritz user.notice slabinfo: ip_conntrack_expect      0      0     88   45    1 : tunables  120   60    0 : slabdata      0      0      0
Apr 26 18:16:30 fritz user.notice slabinfo: ip_conntrack         128    144    248   16    1 : tunables  120   60    0 : slabdata      9      9      0
Apr 26 18:17:48 fritz user.debug kernel: mcfw: group 0.0.0.0: query cpmac:0,1,2,3 10sec
/ $

Nachdem ich im Webinterface die Anrufliste aufgerufen habe hat der telefon für ca. 30s 100% Prozessorauslastung und ich kann keine Seiten im Internet mehr aufrufen.
Mal schauen wie es weitergeht.

MfG Oliver

p.s. Ich hatte das ip_conntrack-Modul mit hashsize=16 geladen. Um den Beitrag abzuschicken musste ich das Modul entfernen. Vorher ging nichts mehr.

edit: Nach 3 Stunden ip_conntrack gabs einen Neustart der Box (hashsize=256).

 

[derheimi]

@olistudent: Super, danke.

Also für ein paar Verbindungen ist die FB wohl selbst verantwortlich, z.B. Uhrzeit via NTP abgleichen, ein bisschen Multicast, auch lokale Verbindungen innerhalb der FB erfasst das conntrack.
Man müsste jetzt mal sehen, was so in der Tabelle drinsteht. Ich könnte mir gut vorstellen, dass die meisten Einträge von Verbindungsversuchen von außerhalb kommen (z.B. P2P-Clients, die unter der aktuellen IP noch einen anderen P2P-Client vermuten - falls das die AVM-Firewall zu diesem Zeitpunkt noch nicht weggefischt hat).
Nichts destotrotz sind 120 Verbindungen eher ein Lacher, das müsste die Box locker wegstecken.

Der Hashsize-Parameter bestimmt zunächst die Größe der Hashtabelle, die ist 8 Byte/Eintrag * Anzahl Einträge. Dabei wird bei ungünstiger Wahl der Anzahl mehr oder weniger Speicher "verschwendet", weil der Speicher in Blöcken von 4kB geholt wird (aber auch nicht linear, sondern quadratisch *bäh* :-( ).

Dann wirkt sich die Hashsize noch indirekt aus:

ip_conntrack_max = 8 * ip_conntrack_htable_size;

Ich gehe davon aus, dass ip_conntrack_max dabei die maximale Anzahl an gleichzeitigen Verbindungen ist, denn an anderer Stelle gibt es einen Vergleich mit dieser Variablen und dort wird zumindest eine Fehlermeldung "Paket wird verworfen, Tabelle voll" erzeugt. (Bestätigung siehe Olis Log; sein Posting hat sich mit meinem langsamen Schreiben überschnitten...)

Aus den Logs kannst Du den tatsächlcihen Speicherverbrauch relativ einfach errechnen: in den ersten Log gibt es doch die Spalten <num_slabs> und <pagesperslab> (siehe we. Eine Page ist hier immer 4 kB. Bei Dir waren 8 Slabs (so ne Verwaltungsstruktur, die mehrere conntrack-Objekte zusammenfasst) erzeugt worden: 8 Slabs * 1 Page/Slab * 4 kB/Page => 32 kB. Zu diesen 32 kB würde dann noch die Hashtabelle dazukommen.

Und die erste Spalte <active_objs> zeigt an, wieviele "Objekte" grad in Gebrauch sind. Das wird nach meinen Verständnis durch ip_conntrack_max nach oben begrenzt werden. (Vermutung durch Olis Log bestätigt.)

Rechnen wir doch mal mit einer Hashsize von 512 (weil dort genau 1 Page für die Hashtabelle verwendet wird und kein Platz "verschwendet" wird). ip_conntrack_max wird 4096, d.h. max. 4096 Verbindungen == max. 4096 Conntrack-Objekte. 4096 Obj. geteilt durch 16 (<objperslab>) macht 256 Slabs. 1 Page/Slab (s.o.) * 256 Slabs * 4kB/Page = 1 MByte.
Nimmt man den Defaultwert 256 (siehe oben) sind es max. 512 kB, wobei ich hier jetzt immer die 4kB für die Hashtabelle weggelassen habe.

Abgesehen davon, müsste es eigentlich auch noch einen SLAB namens ip_conntrack_expect geben. Der braucht auch noch Speicher, allerdings hängt dies IMO von den jeweiligen Protokollen ab, will sagen: es gibt keine pauschale Relation zwischen Anzahl Verbindungen und benötigtem Speicher für diese Objekte.

 

[dsteinkopf]

hm. Ich bin mir nicht sicher, ob ich alles verstanden habe. Ich versuche es mal zusammen zu fassen. Wenn was dran falsch ist, dann korrigiere mich bitte:

* Ein Slab ist ein Speicherbereich für eine Anwendung
* Es gibt immer einen oder mehrere Slabs für ip_conntrack. Die Anzahl sieht man unter active_slabs und num_slabs.
* Die Slabs enthalten viele Objekte, die Anzahl kann dynamisch wachsen. Die Anzahl sieht man unter active_objs und num_objs. Die Größe unter objsize, sie ist fest 248 bei uns.
* In einem Object wird genau eine Conntrack-Verbindung gespeichert.
* Die belegt Gesamtgröße der Slabs ist num_slabs * pages_per_slab * 4kb
* 1 bucket = 1 object (wirklich??? oder: 1 bucket = 1 Hashtable-Eintrag?, nicht so wichtig)
* Dazu gibt es die Hashtable, deren Größe (Anzahl Einträge) man über den Modulparameter hashsize (=ip_conntrack_htable_size) steuern kann (default=2816??).
* Ein Eintrag in der Hashtable belegt 8 Byte.
* Offenbar wird micht 8-facher "Überbelegung" der Hashtable gerechnet, daher können 8*hashsize Conntrack-Einträge gespeichert werden (=ip_conntrack_max)
* Wo wird die Hashtable gespeichert?

Aus dem ganzen kann ich weder ablesen, dass der Speicherverbrauch ein Problem sein könnte, noch dass die Conntrack-Tabelle überlaufen würde; außer, wenn man sie - wie olistudent - sehr klein wählt, was aber gut abgefangen wird und nicht direkt zum Absturz führt.

Welche andere Table könnte also überlaufen? Was führt zum Absturz?

Hat eigentlich jemand eine Konsole an der Box und kann sehen, ob es Konsolenmeldungen im Moment des Absturzes gibt?



Dirk

 

[dsteinkopf]

Hallo nochmal,

ich habe mal versucht, in ds26-14.3/source/avm-gpl-04.29/GPL/kernel_8mb_26_build/kernel/linux-2.6.13.1/net/ipv4/netfilter/ip_conntrack_core.c die Debug-Ausgaben einzuschalten:

#if 1
#define DEBUGP printk
...

Das Modul ist danach 56k groß. Auch lsmod bestätigt das größere Module (lsmod: "...ip_conntrack 41040..")

Trotzdem sehe ich keine der Debug-Ausgaben. Kann da jemand was zu sagen? Müsste das nicht gehen?


Dirk

 

[derheimi]

Linux-Memory-Management in 5min verstanden

Ich bin mal so frei und quote etwas platzsparender.
>> * Ein Slab ist ein Speicherbereich für eine Anwendung <<
Im Prinzip ja, wobei ich unter Anwendung mehr ein Userspace-Programm verstehe. Slabs existieren nur im Kernel und stellen so eine Art "Speicheranforderungscache" dar. Speicher wird unter Linux in mehreren Ebenen verwaltet. Am hardware-nahesten erfolgt die Vergabe immer als 4kB-Block (= als eine "Page"). Wenn Du aber häufig nur 200 B brauchst, würde Dir der Kernel aber trotzdem jedesmal 4kB geben -> es wären 3896 B ungenutzt, die der Kernel auch nicht neu vergeben kann, weil die Einteilung auf dieser Ebene halt so groß ist. Die SLAB-Verwaltung steht jetzt eine Ebene darüber und fasst mehrere kleinere Speicherbereiche (der jeweils gleichen Art) zusammen.

>> * Es gibt immer einen oder mehrere Slabs für ip_conntrack. Die Anzahl sieht man unter active_slabs und num_slabs.<<
Genau, wobei active heißt "aktiv verwendet" und num_slabs für "Platz reserviert". Der überflüssig-reservierte Platz wird bei Bedarf auch wieder freigegeben.

>>* Die Slabs enthalten viele Objekte, die Anzahl kann dynamisch wachsen.
Die Anzahl sieht man unter active_objs und num_objs. Die Größe unter objsize, sie ist fest 248 bei uns.<<
Jein: Die Größe eines einzelnen Objekt bestimmt, wieviele Objekte in einen Slab passen und ist damit "statisch" festgelegt. Die Größe eines Slabs ist in der Regel genau 1 Page, daher round_down(4096/248 ) = 16 (<objperslab>). Bei Bedarf steigt also die Anzahl der Slabs <active_slabs> bzw. <num_slabs> um mehr Objekte aufnehmen zu können. Die Gesamtzahl aller Slabs einer Art wird -wie so vieles- als "Cache" bezeichnet. Das ip_conntrack-Modul verwendet zwei Caches "ip_conntrack" und "ip_conntrack_expected" (oder so).

>>* In einem Object wird genau eine Conntrack-Verbindung gespeichert.
* Die belegt Gesamtgröße der Slabs ist num_slabs * pages_per_slab * 4kb<<<
Richtig.
>>* 1 bucket = 1 object (wirklich??? oder: 1 bucket = 1 Hashtable-Eintrag?, nicht so wichtig)<<
Ein bucket ist ein Hashtable-Eintrag. Ob es da eine 1:1 Beziehung zu den Objects gibt, bin ich nicht sicher, vermute ich aber.

>>* Dazu gibt es die Hashtable, deren Größe (Anzahl Einträge) man über den Modulparameter hashsize (=ip_conntrack_htable_size) steuern kann (default=2816??).<<
Genau. Und der default-Wert 2816 resultiert aus einer falschen Berechnung und wäre unter "normalen Umständen" auf der Fritzbox nur 256.

>>* Ein Eintrag in der Hashtable belegt 8 Byte.
* Offenbar wird micht 8-facher "Überbelegung" der Hashtable gerechnet, daher können 8*hashsize Conntrack-Einträge gespeichert werden (=ip_conntrack_max)<<
Richtig. Wobei ich bei dem Hash-Zeug im Studium wohl nicht richtig aufgepasst habe, sonst sollte ich das besser verstehen ;-)

>>* Wo wird die Hashtable gespeichert?<<

Dafür wird eine gewisse Anzahl an 4kB-Pages direkt vom Kernel geordert, quasi am Slab-System vorbei.

>> Aus dem ganzen kann ich weder ablesen, dass der Speicherverbrauch ein Problem sein könnte, noch dass die Conntrack-Tabelle überlaufen würde; außer, wenn man sie - wie olistudent - sehr klein wählt, was aber gut abgefangen wird und nicht direkt zum Absturz führt.<<

Richtig. Ich vermute, dass die Box nicht "abstürzt" sondern, dass sie sich nur "verklemmt". Je mehr aktive Verbindungen in den Slabs Speicher belegen, weil sie durch die Timeouts nicht rausfallen, desto weniger Speicher bleibt für die anderen Kernelmodule oder für Anwendungen übrig. Und gerade bei dem falschen Defaultwert 2816 können das einige Megabyte werden. Wenn jetzt eine Anwendung Speicher braucht, bei der Anforderung angibt "ich warte notfalls" und gerade nicht genug frei ist, dann klemmt die halt auch solange bis was frei wird. Das sieht dann von außen wie ein Absturz aus, weil quasi alle Anwendungen davon betroffen sind.

Das mit den Debug-Ausgaben hab ich auch schonmal beim cpmac-NIC-Treiber versucht und hatte das gleiche Result wie von dir beschrieben. Ich vermute, dass die Ausgaben auf die serielle Console gehen... *schnief*

 

[kriegaex]

Oliver hat eine serielle Konsole (petz...)

 

[olistudent]

Ich hab jetzt auch mal die printks in ip_conntrack_core aktiviert. Im Syslog hab ich jetzt jede Menge Meldungen. Die printks in resolve_normal_ct hab ich mal rausgenommen, weil die meinen Ringpuffer innerhalb von 1 Sekunde voll hatten.

Apr 28 00:27:37 fritz user.warn kernel: Confirming conntrack 959b0c90
Apr 28 00:27:41 fritz user.warn kernel: clean_from_lists(94af9200)
Apr 28 00:27:41 fritz user.warn kernel: destroy_conntrack(94af9200)
Apr 28 00:27:41 fritz user.warn kernel: destroy_conntrack: returning ct=94af9200 to slab
Apr 28 00:27:42 fritz user.warn kernel: Confirming conntrack 94af9200
Apr 28 00:27:42 fritz user.warn kernel: Confirming conntrack 959b0bc0
Apr 28 00:27:42 fritz user.warn kernel: Confirming conntrack 959b0af0
Apr 28 00:27:42 fritz user.warn kernel: Confirming conntrack 959b0a20
Apr 28 00:27:42 fritz user.warn kernel: Confirming conntrack 959b0950
Apr 28 00:27:42 fritz user.warn kernel: Confirming conntrack 959b0880
Apr 28 00:27:42 fritz user.warn kernel: Confirming conntrack 959b07b0
Apr 28 00:27:52 fritz user.warn kernel: clean_from_lists(959e1c70)
Apr 28 00:27:52 fritz user.warn kernel: destroy_conntrack(959e1c70)
Apr 28 00:27:52 fritz user.warn kernel: destroy_conntrack: returning ct=959e1c70 to slab
Apr 28 00:27:52 fritz user.warn kernel: clean_from_lists(959e1110)
Apr 28 00:27:52 fritz user.warn kernel: destroy_conntrack(959e1110)
Apr 28 00:27:52 fritz user.warn kernel: destroy_conntrack: returning ct=959e1110 to slab
Apr 28 00:27:54 fritz user.warn kernel: clean_from_lists(959e1a00)
Apr 28 00:27:54 fritz user.warn kernel: destroy_conntrack(959e1a00)
Apr 28 00:27:54 fritz user.warn kernel: destroy_conntrack: returning ct=959e1a00 to slab
Apr 28 00:27:54 fritz user.warn kernel: clean_from_lists(959e1930)
Apr 28 00:27:54 fritz user.warn kernel: destroy_conntrack(959e1930)
Apr 28 00:27:54 fritz user.warn kernel: destroy_conntrack: returning ct=959e1930 to slab
Apr 28 00:27:54 fritz user.warn kernel: clean_from_lists(959e1860)
Apr 28 00:27:54 fritz user.warn kernel: destroy_conntrack(959e1860)
Apr 28 00:27:54 fritz user.warn kernel: destroy_conntrack: returning ct=959e1860 to slab
Apr 28 00:27:54 fritz user.warn kernel: clean_from_lists(959b0f00)
Apr 28 00:27:54 fritz user.warn kernel: destroy_conntrack(959b0f00)
Apr 28 00:27:54 fritz user.warn kernel: destroy_conntrack: returning ct=959b0f00 to slab
Apr 28 00:27:54 fritz user.warn kernel: clean_from_lists(959b0e30)
Apr 28 00:27:54 fritz user.warn kernel: destroy_conntrack(959b0e30)
Apr 28 00:27:54 fritz user.warn kernel: destroy_conntrack: returning ct=959b0e30 to slab
Apr 28 00:27:54 fritz user.warn kernel: clean_from_lists(959b0d60)
Apr 28 00:27:54 fritz user.warn kernel: destroy_conntrack(959b0d60)
Apr 28 00:27:54 fritz user.warn kernel: destroy_conntrack: returning ct=959b0d60 to slab
Apr 28 00:27:54 fritz user.warn kernel: clean_from_lists(959b0c90)
Apr 28 00:27:54 fritz user.warn kernel: destroy_conntrack(959b0c90)
Apr 28 00:27:54 fritz user.warn kernel: destroy_conntrack: returning ct=959b0c90 to slab
Apr 28 00:28:07 fritz user.warn kernel: clean_from_lists(959e15f0)
Apr 28 00:28:07 fritz user.warn kernel: destroy_conntrack(959e15f0)
Apr 28 00:28:07 fritz user.warn kernel: destroy_conntrack: returning ct=959e15f0 to slab
Apr 28 00:28:11 fritz user.warn kernel: Confirming conntrack 959e1930
Apr 28 00:28:41 fritz user.warn kernel: clean_from_lists(95dbb930)
Apr 28 00:28:41 fritz user.warn kernel: destroy_conntrack(95dbb930)
Apr 28 00:28:41 fritz user.warn kernel: destroy_conntrack: returning ct=95dbb930 to slab
Apr 28 00:28:41 fritz user.warn kernel: Confirming conntrack 95dbb930
Apr 28 00:28:53 fritz user.warn kernel: clean_from_lists(94af96e0)
Apr 28 00:28:53 fritz user.warn kernel: destroy_conntrack(94af96e0)
Apr 28 00:28:53 fritz user.warn kernel: destroy_conntrack: returning ct=94af96e0 to slab
Apr 28 00:28:53 fritz user.warn kernel: clean_from_lists(94af9610)
Apr 28 00:28:53 fritz user.warn kernel: destroy_conntrack(94af9610)
Apr 28 00:28:53 fritz user.warn kernel: destroy_conntrack: returning ct=94af9610 to slab
Apr 28 00:28:53 fritz user.warn kernel: clean_from_lists(959e1ee0)
Apr 28 00:28:53 fritz user.warn kernel: destroy_conntrack(959e1ee0)
Apr 28 00:28:53 fritz user.warn kernel: destroy_conntrack: returning ct=959e1ee0 to slab
Apr 28 00:28:53 fritz user.warn kernel: clean_from_lists(959e1e10)
Apr 28 00:28:53 fritz user.warn kernel: destroy_conntrack(959e1e10)
Apr 28 00:28:53 fritz user.warn kernel: destroy_conntrack: returning ct=959e1e10 to slab
Apr 28 00:29:23 fritz user.warn kernel: clean_from_lists(95dbb930)
Apr 28 00:29:23 fritz user.warn kernel: destroy_conntrack(95dbb930)
Apr 28 00:29:23 fritz user.warn kernel: destroy_conntrack: returning ct=95dbb930 to slab
Apr 28 00:29:23 fritz user.warn kernel: Confirming conntrack 95dbb930
Apr 28 00:29:48 fritz user.warn kernel: Confirming conntrack 959e1e10

Ich hab mich auch schon ein bißchen im Kernel-Git umgeschaut. Iptables scheint zu der Zeit eine große Baustelle gewesen zu sein...

MfG Oliver

 

[derheimi]

@olistudent:
Sind das die Einträge kurz von einem Crash der Box, oder nur ganz allgemein?

Ich hatte heute vormittag das ip_conntrack-Modul und die Logging-Schleife mal auf meiner 7141 laufen.
Und tatsächlich, nach ziemlich genau 3 Stunden +-5min hat die Box rebootet. Leider hab ich auch [noch] keine serielle Console, aber an ein Speicherproblem glaube ich langsam nicht mehr: auf meiner
Box sind immer so ca. 1.8 MB frei und mit ca. 200 Verbindungseinträge im conntrack
war ich auch quasi im "Leerlauf".

Keine Ahnung, woran das noch liegen kann. Vielleicht ein Locking-Problem? In den
Kernel-Changelogs hatte ich auch schon mal ein bisschen rumgewühlt, und mir waren
da auch ein paar Locking-Subjects aufgefallen (ich finds grad gar nicht wieder),
aber inwieweit das hier relevant ist, kann ich schlecht einschätzen.

@AVM: Es wäre ganz nett von Euch, wenn ihr nicht (nur) die komplett gepatchten
Kernelsourcen bereitstellt, sondern auch sagt, welche Patches ihr sonst noch so
verwendet habt. Und Eure eigenen Patches würde ich mir sauber nach einzelnen
"Aspekten" getrennt wünschen.
Dann könnte man viel besser auf aktuellere Kernelversion portieren...

 

[olistudent]

Nein, das einfach mal so. Absturz kommt jetzt. Das ist aus dem Syslog. Aber ich denke nicht, dass man auf der Konsole mehr sieht.

User.Warning 192.168.1.2 Apr 28 13:54:55 kernel: destroy_conntrack(94e093a0)<000>
User.Warning 192.168.1.2 Apr 28 13:54:55 kernel: destroy_conntrack: returning ct=94e093a0 to slab<000>
User.Warning 192.168.1.2 Apr 28 13:54:55 kernel: clean_from_lists(94e09e30)<000>
User.Warning 192.168.1.2 Apr 28 13:54:55 kernel: destroy_conntrack(94e09e30)<000>
User.Warning 192.168.1.2 Apr 28 13:54:55 kernel: destroy_conntrack: returning ct=94e09e30 to slab<000>
User.Warning 192.168.1.2 Apr 28 13:54:55 kernel: clean_from_lists(94e09470)<000>
User.Warning 192.168.1.2 Apr 28 13:54:55 kernel: destroy_conntrack(94e09470)<000>
User.Warning 192.168.1.2 Apr 28 13:54:55 kernel: destroy_conntrack: returning ct=94e09470 to slab<000>
User.Warning 192.168.1.2 Apr 28 13:54:55 kernel: clean_from_lists(94e09200)<000>
User.Warning 192.168.1.2 Apr 28 13:54:55 kernel: destroy_conntrack(94e09200)<000>
User.Warning 192.168.1.2 Apr 28 13:54:55 kernel: destroy_conntrack: returning ct=94e09200 to slab<000>
User.Warning 192.168.1.2 Apr 28 13:54:55 kernel: clean_from_lists(94e096e0)<000>
User.Warning 192.168.1.2 Apr 28 13:54:55 kernel: destroy_conntrack(94e096e0)<000>
User.Warning 192.168.1.2 Apr 28 13:54:55 kernel: destroy_conntrack: returning ct=94e096e0 to slab<000>
User.Warning 192.168.1.2 Apr 28 13:54:55 kernel: clean_from_lists(94e09540)<000>
User.Warning 192.168.1.2 Apr 28 13:54:55 kernel: destroy_conntrack(94e09540)<000>
User.Warning 192.168.1.2 Apr 28 13:54:55 kernel: destroy_conntrack: returning ct=94e09540 to slab<000>
User.Warning 192.168.1.2 Apr 28 13:54:56 kernel: clean_from_lists(94e09a20)<000>
User.Warning 192.168.1.2 Apr 28 13:54:56 kernel: destroy_conntrack(94e09a20)<000>
User.Warning 192.168.1.2 Apr 28 13:54:56 kernel: destroy_conntrack: returning ct=94e09a20 to slab<000>
User.Warning 192.168.1.2 Apr 28 13:54:56 kernel: clean_from_lists(94e09950)<000>
User.Warning 192.168.1.2 Apr 28 13:54:56 kernel: destroy_conntrack(94e09950)<000>
User.Warning 192.168.1.2 Apr 28 13:54:56 kernel: destroy_conntrack: returning ct=94e09950 to slab<000>
User.Warning 192.168.1.2 Apr 28 13:55:00 kernel: Confirming conntrack 94e09950<000>
User.Warning 192.168.1.2 Apr 28 13:55:01 kernel: Confirming conntrack 94e093a0<000>
User.Warning 192.168.1.2 Apr 28 13:55:01 kernel: Confirming conntrack 94e09e30<000>
User.Warning 192.168.1.2 Apr 28 13:55:01 kernel: Confirming conntrack 94e09470<000>
User.Warning 192.168.1.2 Apr 28 13:55:01 kernel: Confirming conntrack 94e09200<000>
User.Warning 192.168.1.2 Apr 28 13:55:01 kernel: Confirming conntrack 94e096e0<000>
User.Warning 192.168.1.2 Apr 28 13:55:01 kernel: Confirming conntrack 94e09540<000>
User.Warning 192.168.1.2 Apr 28 13:55:01 kernel: Confirming conntrack 94e09a20<000>
User.Warning 192.168.1.2 Apr 28 13:55:01 kernel: Confirming conntrack 94f512b0<000>
User.Warning 192.168.1.2 Apr 28 13:55:01 kernel: Confirming conntrack 94f51520<000>
User.Warning 192.168.1.2 Apr 28 13:55:01 kernel: Confirming conntrack 94f51930<000>
User.Warning 192.168.1.2 Apr 28 13:55:02 kernel: Confirming conntrack 94f51ad0<000>
User.Warning 192.168.1.2 Apr 28 13:55:05 kernel: clean_from_lists(944ae1e0)<000>
User.Warning 192.168.1.2 Apr 28 13:55:05 kernel: destroy_conntrack(944ae1e0)<000>
User.Warning 192.168.1.2 Apr 28 13:55:05 kernel: destroy_conntrack: returning ct=944ae1e0 to slab<000>
User.Warning 192.168.1.2 Apr 28 13:55:13 kernel: clean_from_lists(94e096e0)<000>
User.Warning 192.168.1.2 Apr 28 13:55:13 kernel: destroy_conntrack(94e096e0)<000>
User.Warning 192.168.1.2 Apr 28 13:55:13 kernel: destroy_conntrack: returning ct=94e096e0 to slab<000>
User.Warning 192.168.1.2 Apr 28 13:55:15 kernel: Confirming conntrack 958daaf0<000>
User.Notice 192.168.1.2 Jan  1 01:00:41 kernel: klogd started: BusyBox v1.4.1 (2007-04-27 15:38:04 CEST)<000>
User.Notice 192.168.1.2 Jan  1 01:00:41 kernel: Linux version 2.6.13.1-ohio (723) (gcc version 3.4.6) #1 Thu Apr 19 12:39:55 CEST 2007<000>
User.Warning 192.168.1.2 Jan  1 01:00:41 kernel: memsize=32 MByte<000>
User.Warning 192.168.1.2 Jan  1 01:00:41 kernel: flashsize=8 MByte<000>

MfG Oliver

 

[dsteinkopf]

Also _ich_ kann da keine Hinweise für die Ursache des Absturzes herauslesen... :-( :-(

Wiese rebootet die Box bei Dir eigentlich? Bei mir stirbt sie einfach - dann muss ich immer den Stecker ziehen - was blöd ist, wenn ich nicht zu Hause bin...


Dirk

 

[derheimi]

Ich auch nicht. Wenn es wenigstens ein "normaler" Oops/BUG/Panic wäre, damit man einen weiteren Ansatz hätte. Aber so fällt mir leider nicht mehr viel ein. Folgende Optionen sehe ich zu Zeit noch:
1) Man könnte natürlich noch mit Hilfe einer seriellen Console und remote-gdb einiges versuchen, aber sowas hab ich auch noch nie gemacht, daher keine Ahnung ob sinnvoll und wie aufwendig.
2) Die netfilter-Mailingliste kontakten. Allerdings ist Kernel 2.6.13.1 schon fast antik, wir haben nur wenige harte Informationen und zusätzliche zu beschaffen wird auch nicht besonders leicht sein (z.B. wegen des tollen Watchdogs, wegen nur wenigen seriellen Consolen, SysRq via seriell geht bestimmt auch nicht so einfach...)
3) Die von AVM am 2.6.13.1er Kernel durchgeführten Änderungen selbst auf ne neue Version portieren bzw. mit dem openWRT-Kernel durchstarten und den "kompatibel" zur AVM-Firmware machen.
4) Abwarten bis AVM seine Firmware auf neuere Kernelversionen aufbaut und dann neu versuchen. Bis dahin mit dem beschriebenen Workaround leben und das Modul alle 2h neu laden.

Hab ich irgendwas übersehen?

 

[dsteinkopf]

1) Man könnte natürlich noch mit Hilfe einer seriellen Console und remote-gdb einiges versuchen, aber sowas hab ich auch noch nie gemacht, daher keine Ahnung ob sinnvoll und wie aufwendig.

Kann man der kernel mit gdb überhaupt debuggen? Also das ist mir echt zu viel Act.

2) Die netfilter-Mailingliste kontakten. ...

Das wäre einen Versuch wert. Bist du da schon drauf?
Aber wahrscheinlich sagen sie nur: Updaten...

3) Die von AVM am 2.6.13.1er Kernel durchgeführten Änderungen selbst auf ne neue Version portieren ...

Man könnte ja mal einen diff zum Vanilla-Kernel 2.6.13.1 machen.

4) Abwarten bis AVM seine Firmware auf neuere Kernelversionen aufbaut ...

Hab ich irgendwas übersehen?

Man könnte noch versuchen, neuere iptables-Kernel-Quellen (also nur den iptables-Part) auf 2.6.13.1 zurück zu portieren. Aber sowas habe ich auch noch nie gemacht. Hört man nur immer wieder, das solche Sachen passieren.


Dirk

 

[derheimi]

Kann man der kernel mit gdb überhaupt debuggen? Also das ist mir echt zu viel Act.

Theoretisch sollte das gehen, hab ich gelesen. Mir ist das aber auch zu aufwendig, da kann man sich auch die Sourcen komplett reinziehen und verstehen, da hat man mehr von...

Das wäre einen Versuch wert. Bist du da schon drauf?
Aber wahrscheinlich sagen sie nur: Updaten...

Genau das befürchte ich auch; abonniert hab ich die LIste inzwischen trotzdem mal...

Man könnte ja mal einen diff zum Vanilla-Kernel 2.6.13.1 machen.

Hab ich schon gemacht. Raus kommt ein 4 MB großes Diff, das sich natürlich nicht problemlos auf einen 2.6.21 anwenden lässt: jede Menge Rejects und dann fehlen auch noch paar komplette Files, die wohl im Laufe der Zeit von 2.6.13->2.6.21 entfallen sind. Das betrifft z.B. ganz essentielle Dinge wie IRQ-Management. Letztendlich muss man also den großen Patch in > 600 einzelne kleine Diffs zerlegen, und dann für jeden einzeln analysieren, inwieweit der noch sinnvoll oder überhaupt nötig ist.
Kurzum: jede Menge Arbeit. Freiwillige? ;-)

Man könnte noch versuchen, neuere iptables-Kernel-Quellen (also nur den iptables-Part) auf 2.6.13.1 zurück zu portieren. Aber sowas habe ich auch noch nie gemacht. Hört man nur immer wieder, das solche Sachen passieren.

Versuchen könnte man es, vermute aber, dass man da auf Querabhängigkeiten stößt, die man nicht gelöst bekommt. Dann lieber gleich auf ne komplett neue Kernelversion...

Die Frage bei einer neuen Kernelversion ist auch noch, inwiewiet die tollen proprietären Module dann noch laufen bzw. überhaupt ladbar sind...

Update: Mail an netfilter-Liste ist raus. Mal sehen...

 

[elohmann]

Spannendes Thema, habe auch mit iptables auf meiner 7170 diese Probleme, da ich auf meinem OpenVPN Interface auf der Box NAT'en will.
Verstehe so in Ansätzen Eure Probleme und denke da keine große Hilfe sein zu können, drücke Euch aber die Daumen und hoffe das Ihr das Problem findet.

Gruß, Eike

 

[dsteinkopf]

Update: Mail an netfilter-Liste ist raus. Mal sehen...

Darauf ruhen meine Hoffnungen. Alle anderen Optionen klingen nicht so, als wären sie gangbar für uns....


Dirk

 

[Liebei]

Hi,

sehr interessant diesen Thread zu lesen, leider kann ich euch nicht helfen, da ich mit Linux bis jetzt noch nix am Hut hatte, gibts schon was neues?

Ich bräuchte die iptables auch auf der FB und hoffe, dass ihr das Problem lösen könnt. Wäre super, wenn mir jemand sagen könnte, ob ich damit das hier lösen kann.

 

[dsteinkopf]

@derheimi: Hast Du schon was über die netfilter-Liste erreicht? (vermutlich nicht, sonst hättest du es sicher schon hier kundegetan...)


Dirk

 

[derheimi]

Nein, von der netfilter-Liste gibt es leider noch keine Rückmeldung :-(

 

[delphisailor]

Hallo,

ich habe den ds-mod 26 erfolgreich auf meine Fritzbox gebracht (Danke für die komfortable Build-Umgebung!). Wie zu erwarten macht iptables Probleme:

Alle paar Stunden rebootet die Box - immerhin bleibt sie nicht hängen.

Auch bei mir führt offenbar Speichermangel zum Absturz. In /proc/net/ip_conntrack ist auffällig, daß fast alle Verbindungen (bis auf 3-4) den Status ESTABLISHED haben und der Timeout-Counter im Bereich >400000s steht - das sind ca. 4,6 Tage.

Auf meinem Linux-PC gibt es nur wenig ESTABLISHED-Einträge mit entsprechend hohen Timeout-Countern. Die meisten Verbindungen führt ip_conntrack als TIME_WAIT mit Werten im Bereich <1000s.

Daher ist es kein Wunder, wenn die conntrack-Tabelle überläuft. Könnte es sein, dass irgend etwas den Übergang von ESTABLISHED nach TIME_WAIT verhindert und damit die Tabelleneinträge viel zu langsam ablaufen? Es könnte sich lohnen, an dieser Stelle noch einmal genauer hinzuschauen.

delphisailor

 

[dsteinkopf]

Danke für den Hinweis. Ich hatte das Problem aufgegeben und durch einen Cron-gesteuerten Reboot alle 2 Stunden "gelöst".

Inzwischen habe ich eine 7270, wo iptables gar nicht geht :-( Sieht hier: http://www.ip-phone-forum.de/showthread.php?t=160009


Dirk