iptables in ds26-14.3 stützt ab

[dsteinkopf]

Hallo zusammen,

wie ich schon in anderen Threads geschrieben habe, stürzt bei mir die Box komplett ab, sobald ich die iptables-Module geladen habe. D.h. nach ziemlich genau 3 Stunden uptime bleibt sie einfach stehen und tut gar nichts mehr.

Jetzt wollte ich hier zum Einen mal nachfragen, ob es noch andere gibt, die das Problem haben und an einer Lösung interessiert wären.

Zum Anderen, ob es jemanden gibt, der sich etwas damit besser damit auskennt, wie iptables in den Fritzbox-Kernel integriert ist, um mir/uns einen Tipp zu geben, wie man anfangen könnte, das Problem zu lösen. Naheliegend wäre ja vielleicht, aktuelle iptables-Kernel-Quellen in der Kernel einzubauen. Aber auf netfilter.org bin ich nicht wirklich schlau geworden, wie das gehen könnte.

Ich würde also nur weitermachen, mich damit zu beschäftigen, wenn es einerseits noch andere gibt, die davon profitieren und andererseit welche, die mir helfen können - zumindest einen Startpunkt bräuchte ich, weil ich momentan nicht recht weiß, wie ich weiter machen könnte.



Dirk

 

[magenbrot]

Habe das gleiche Problem und hätte es auch gerne gelöst. Ansatz hab ich leider auch keinen. Vielleicht kann sich das mal jemand ankucken, der Ahnung von der Materie hat. Falls ich beim Debuggen oder so helfen kann, jederzeit

 

[kriegaex]

Wir haben ja schon in verschiedenen Threads darüber geredet, und die Release Notes ("Iptables ist eine Baustelle") bzw. das Menuconfig ("Unstable") sind ja hier auch eindeutig. Bisher fühlt sich niemand bemüßigt oder in der Lage, das nochmal neu in Angriff zu nehmen. Wann sich das ändert oder ob schon jemand dabei ist, kann ich Dir nicht sagen.

Nur eine Idee fällt mir noch ein zu Deiner kleinen Box mit Platzproblemen und Nachladen in den RAM-Speicher: Geht Dir der Speicher aus? Bei einigen Benutzern mit regelmäßigen Abstürzen hilft da zuverlässig eine Swap-Partition. Das ist momentan mein heißester Tip, denn eine Anwendung wird nicht einfach so "müde" nach drei Stunden, sondern sie hat entweder ein Speicherleck oder schreibt Logs bzw. tut sonst irgendetwas, das die Umgebungsbedingungen so ändert, daß sie irgendwann abstürzt. Ich weiß, du meinst, der Speicher sei nicht das Problem, aber versuch es trotzdem mal mit Swap Space. Da NFS bei Dir nicht klappt, müßtest Du es mal über CIFS/SMB probieren.

 

[dsteinkopf]

Swap über cifs habe ich schon probiert. Hat nicht geholfen. Aber ich werde es unter aktuellen Bedingungen nochmal versuchen.

Ich gebe Dir natürlich Recht, dass nichts "einfach so" abstürzt. Aber offenbar ist es nicht der Hauptspeicher, der voll läuft. Da es sich um das ip_conntrack-Modul handelt (soweit habe ich es inzwischen relativ sicher eingekreist), tippe ich eher auf die connection-Tabellen oder sonstwas Modul-internes, das voll läuft. Aber ich kenn mich da auch nicht wirklich aus.


Dirk

 

[dsteinkopf]

Meine Lösung besteht jetzt darin, cron-gesteuert alle 2 Stunden, alle iptables-Regeln zu löschen, zu Kernel-Module zu löschen und alles wieder neu laden.

Geht! Ist aber eine dumme Lösung.

Gibt es hier außer mit überhaupt jemanden, der iptables mit Fritz-Kernel 2.6 einsetzt bzw. einsetzen möchte?



Dirk

 

[kriegaex]

Wieder ein Indikator für einen hohen Speicherverbrauch oder sogar ein Speicherleck.

Könntest Du evtl. mal über die Zeit von zwei, drei Stunden bei dem oder den Iptables-Prozessen Folgendes beobachten und schauen, wie es sich im zeitlichen Verlauf entwickelt?

• cat /proc/meminfo | grep MemFree
• cat /proc/<pid>/status | grep '^Vm'

Ersteres ist die globale Betrachtung, Letzteres die lokale, auf den Einzelprozeß bezogene. Vielleicht erkennt man ja etwas. Tendenziell sollte #1 sinken und der Speicherverbrauch bei #2 an irgendeiner Stelle kontinuierlich ansteigen. Ein "Schnelltest" wäre z.B., beides mal kurz vor dem Beenden von Iptables nach 2- bis 3-stündiger Laufzeit und dann anschließend gleich wieder nach dem bereinigten Neustart der Anwendung durchzuführen (die PID ist dann eine andere, aber die kann man ja bestimmen).

 

[derheimi]

Damit hier nicht aneinander vorbei diskutiert wird und weil ich mir nicht sicher bin, wie tief jeder mit der Materie vertraut ist, mal noch der dezente Hinweis, dass die Linux-Firewall-Geschichte zweigeteilt ist: zum einen gibt es da die verschiedenen Kernel-Module (hauptsächlich ipt*.ko) von netfilter, die man laden oder auch nicht laden kann. Selbst wenn geladen, machen die erstmal gar nichts. Zum anderen gibt es das iptables-Binary und ein paar Userspace-Module (libipt*.so).

Iptables und die Userspace-Libs sind ausschließlich dafür da, die Module im Kernelspace mit den übergebenen Parametern zu konfigurieren - mehr machen die eigentlich nicht. Etwaige Speicherlecks im Userspace haben daher keinen Einfluss auf die "Langzeit"Stabilität, weil die iptables-Prozesse immer nur kurz laufen, nämlich genau beim Erstellen/Ändern/Löschen von Regeln.

Damit die Parameterübergabe in den Kernel richtig klappt, müssen natürlich die Userspace-Libs und die Kernel-Mods einigermaßen zusammenpassen. Sollte das nicht der Fall sein, müsste sich das aber schon beim Erstellen der Regeln outen und iptables würde in dem Moment ne Fehlermeldung bringen.

Speicherleck im Kernel würde ich auch nicht prinzipiell ausschließen, aber es spricht folgendes dagegen: Ein Schnellvergleich der AVM und der Vanillaquellen zeigt, dass AVM am netfilter nicht wirklich rumgespielt hat. Ergo würde der Fehler nicht AVM-/Fritzbox-spezifisch sein. Da die Vanilla-Releases aber ziemlich gut getestet werden (und gerade die sicherheitskritischen Teile), würde ich das einfach mal ausschließen, weil extrem unwahrscheinlich.
Low-Memory-Conditions im netfilter sollte die Box nicht komplett anhalten lassen, sondern nur im Verwerfen von Paketen resultieren. Das lässt sich natürlich ohne direkte Console schwer unterscheiden, wenn man nur via Netzwerk auf die Box kommt, daher wäre es einfacher zu debuggen, wenn sich jmd die Mühe macht und ne serielle Console ranhängt.

Mich stören auch noch die 3 Stunden. Kann man diese Zeit irgendwie beeinflußen? z.B. mehr Traffic -> Box bleibt eher stehen? Gibt es irgendwelche periodischen Dinge, die mit den 3 Stunden in Zusammenhang gebracht werden können? Allein am netfilter kann es schlecht liegen, da gibt es nur ein paar Timeouts, die allerdings wohl eher Speicher/Ressourcen freigeben anstatt neue(n) zu besorgen...

@dsteinkopf:
Wie nutzt Du iptables ganz konkret? 1x beim Booten die Regeln laden und fertig, oder versuchst Du dann noch irgendwas "dynamisches" zur Laufzeit? Welche iptables-Module (Kernel) benutzt Du konkret? Schon mal versucht, bestimmte Modul wegzulassen (insofern das geht und sinnvoll ist) und z.B. nur "die halbe" Firewall zu fahren?
Vielleicht kannst Du einfach mal das Script/iptables-Aufrufe hier posten (oder hab ichs übersehen?).
Irgendwie müssen wir die Sache systematisch anpacken...

 

[dsteinkopf]

Hallo,

danke für Deine Mitarbeit

...
Speicherleck im Kernel würde ich auch nicht prinzipiell ausschließen, aber es spricht folgendes dagegen: Ein Schnellvergleich der AVM und der Vanillaquellen zeigt, dass AVM am netfilter nicht wirklich rumgespielt hat. Ergo würde der Fehler nicht AVM-/Fritzbox-spezifisch sein. Da die Vanilla-Releases aber ziemlich gut getestet werden (und gerade die sicherheitskritischen Teile), würde ich das einfach mal ausschließen, weil extrem unwahrscheinlich.

Ja, das habe ich mir auch schon überlegt.

Low-Memory-Conditions im netfilter sollte die Box nicht komplett anhalten lassen, sondern nur im Verwerfen von Paketen resultieren. Das lässt sich natürlich ohne direkte Console schwer unterscheiden, wenn man nur via Netzwerk auf die Box kommt, daher wäre es einfacher zu debuggen, wenn sich jmd die Mühe macht und ne serielle Console ranhängt.

Diese Möglichkeit habe ich leider nicht.

Mich stören auch noch die 3 Stunden. Kann man diese Zeit irgendwie beeinflußen? z.B. mehr Traffic -> Box bleibt eher stehen?

Das habe ich so explizit noch nicht probiert. Aber es waren eigentlich immer so 2:59h

Gibt es irgendwelche periodischen Dinge, die mit den 3 Stunden in Zusammenhang gebracht werden können? Allein am netfilter kann es schlecht liegen, da gibt es nur ein paar Timeouts, die allerdings wohl eher Speicher/Ressourcen freigeben anstatt neue(n) zu besorgen...

Ich wüsste nicht, was da noch sein könnte, was das beeinflusst.

@dsteinkopf:
Wie nutzt Du iptables ganz konkret? 1x beim Booten die Regeln laden und fertig, oder versuchst Du dann noch irgendwas "dynamisches" zur Laufzeit? Welche iptables-Module (Kernel) benutzt Du konkret? Schon mal versucht, bestimmte Modul wegzulassen (insofern das geht und sinnvoll ist) und z.B. nur "die halbe" Firewall zu fahren?

Ja, habe ich alles getan. Und zwar auch schon systematisch: Mal mit, mal ohne Regeln; Module einzeln weggelassen und wieder dazu etc. Und dann immer statisch gelassen.
Und, wie gesagt, nach Entladen und Neuladen der Module scheint die "Zeitbombe" von vorne anzufangen zu ticken.

Ergebnis: Box stürzt ab, sobald ip_conntrack _geladen_ ist. Kein einziger iptables-Aufruf ist dazu nötig.

Kann das eigentlich jemand nachvollziehen und bestätigen?

Vielleicht kannst Du einfach mal das Script/iptables-Aufrufe hier posten (oder hab ichs übersehen?).
Irgendwie müssen wir die Sache systematisch anpacken...

Kann ich gerne tun, aber ich glaub oben Gesagtes macht das überflüssig.


Dirk

 

[McNetic]

Hm. In meinen Augen klingt das logisch, dass derheimi oben nur eingeschränkt Recht hat, dass das Laden der Module noch zu gar nichts führt: Gerade das conntrack-Modul verfolgt doch jede aufgebaute Verbindung. Ich könnte mir vorstellen, dass dies NICHT erst aktiviert wird, wenn irgendwo eine Rule mit -state RELATED oder ESTABLISHED oder was auch immer eingefügt wird, sondern sobald das Modul geladen wird.

 

[magenbrot]

Hi,

meine 7170 hat auch das Problem mit dem Absturz bei geladenen iptables-Modulen. Nur hält sie etwas länger durch:

 05:37:02 up  3:43, load average: 0.01, 0.09, 0.08
MemTotal:        30360 kB
MemFree:          1136 kB
Buffers:          3180 kB
Cached:          11776 kB
SwapCached:          0 kB
Active:          11832 kB
Inactive:         9904 kB
HighTotal:           0 kB
HighFree:            0 kB
LowTotal:        30360 kB
LowFree:          1136 kB
SwapTotal:           0 kB
SwapFree:            0 kB
Dirty:               0 kB
Writeback:           0 kB
Mapped:          11780 kB
Slab:             4424 kB
CommitLimit:     15180 kB
Committed_AS:    19996 kB
PageTables:        444 kB
VmallocTotal:  1048560 kB
VmallocUsed:      2360 kB
VmallocChunk:  1046092 kB

dann folgt der reboot und wieder das gleich Spiel immer mit +-5 Minuten. Zu tun hat sie in dem Moment nichts und der Speicher geht ihr auch nicht aus.
Auf http://netfilter.org gibts ein Tool namens conntrack, mit dem man die conntrack-Tabelle anzeigen und manipulieren kann, vielleicht bringt uns das ja irgendwie weiter. Werd mal versuchen, ob ich das gebaut bekomme.

gruß
Oli

 

[dsteinkopf]

Prima, dass Du es auch mal ausprobiert hast. Jetzt weiß ich wenigstens, dass es nicht nur bei mir auftrtitt.

dann folgt der reboot und wieder das gleich Spiel immer mit +-5 Minuten.

Heißt das, dass die Box bei Dir von selber rebootet? Bei mir bleibt sie einfach stehen und ich muss den Stecker ziehen.

Auf http://netfilter.org gibts ein Tool namens conntrack, mit dem man die conntrack-Tabelle anzeigen und manipulieren kann, vielleicht bringt uns das ja irgendwie weiter. Werd mal versuchen, ob ich das gebaut bekomme.

Das halte ich für eine sehr gute Idee! Mich interessiert vor allem, ob die Tablle auch ohne Regeln schon wächst und ob sie überläuft. Lass mir/uns dann das Exe auch mal zukommen, wenn du es geschafft hast.


Ich habe heute das ganze nochmal Probiert nur mit den beiden Module ip_tables und ip_conntrack, sonst (außer dem mod) gar nichts - kein cron, kein openvpn etc. Aber wieder der Absturz.


Dirk

 

[kriegaex]

Ihr habt beide wenig MemFree, ich finde ca. 1 MB nicht so viel. Bei mir sind es bspw. 1,8 MB. Eine kleine suboptimale Datenreorganisation in regelmäßigen Abständen oder das Überlaufen irgendwelcher Tabellen kann sehr wohl damit zu tun haben. Ob das da bei iptables hilft, ...

• http://openvpn.net/faq.html
• http://kerneltrap.org/node/4312

... (auf beiden Seiten jeweils mal nach "/proc/sys/vm/min_free_kbytes" suchen), weiß ich nicht, damit kenne ich mich einfach zu schlecht aus. Da wir ja insgesamt etwas ratlos sind, schadet ein Versuch, den Wert - bei mir liegt er bei 724 - zu ändern, wohl nicht.

 

[derheimi]

@McNetic: Du hast natürlich Recht, ip_conntrack ist ziemlich aktiv, sobald es geladen wurde, sorry!

Ich hab gerade mal in den Sourcen versucht nachzuvollziehen, was die Init-Funktion von ip_conntrack alles so macht. Aber im Prinzip ist es wirklich nur ein bisschen Speicher holen und eine Socket-Option registrieren. Mir sind die Auswirkungen davon allerdings noch bisschen unklar.

Die conntrack-Tabellen kann man übrigens auch via /proc auslesen, halt nur nicht manipulieren:

tonne:~# cat /proc/net/ip_conntrack
tcp      6 431999 ESTABLISHED src=192.168.8.253 dst=192.168.8.1 sport=22 dport=1277 src=192.168.8.1 dst=192.168.8.253 sport=1277 dport=22 use=1
...

Speicher wird über den SLAB-Allokator abgewickelt (oder SLOB - bin grad zu faul, genau nachzusehen, was AVM da nimmt - aber das macht idR keinen Unterschied). Die Infos bekommt man z.B. via "cat /proc/slabinfo" wobei es eine Zeile beginned mit "ip_conntrack" geben müsste, sobald das Kernel-Modul geladen ist:

tonne:~# cat /proc/slabinfo | head -n 5
slabinfo - version: 2.0
# name            <active_objs> <num_objs> <objsize> <objperslab> <pagesperslab> : tunables <batchcount> <limit> <sharedfactor> : slabdata <active_slabs> <num_slabs> <sharedavail>
ip_conntrack          13     24    320   12    1 : tunables   54   27    0 : slabdata      2      2      0

Aus der Spalte <num_slabs> und <pagesperslab> kann man z.B. ablesen, wieviel Speicher gerade reserviert ist: hier 2 * 1 * 4096 (Byte/Page) => 8 kB.

Wenn ich die Sourcen richtig verstanden habe, dürften auf der Fritzbox mit 32 MB RAM max. 684kB dafür verwendet werden, weil max. 256 Objekte (buckets) verwendet werden. Vielleicht kann jmd nochmal die letzten Zeilen von "dmesg" posten, kurz nachdem das Modul via modprobe geladen wurde?! Da müsste irgendwie ne Zeile

ip_conntrack version 2.1 (1919 buckets, 15352 max) - 296 bytes per conntrack

auftauchen, wobei mich die Zahlen zur Vollständigkeit mal interessieren würden.

Um den Speicherbedarf auf das Minimalste zu drücken, könnte man auch mal noch "modprobe ip_conntrack hashsize=16" probieren, dann dürften maximal 44kB für den SLAB-Cache draufgehen.

Bin mir aber noch nicht sicher, wie die Anzahl der buckets mit der Anzahl der Verbindungen in Zusammenhang steht...

 

[dsteinkopf]

Das ist ja sehr interessant!

Hier meine Zeile beim Laden des Moduls:

Apr 26 11:51:15 fritz kernel: ip_conntrack version 2.1 (2816 buckets, 22528 max) - 248 bytes per conntrack

Ich habe nun mal ein Logging gestartet, das alle 5 Minuten alle wichtigen Infos loggt:

( while true; do 
free | logger -t free; 
cat /proc/meminfo | grep -E '^MemFree|^Cached|^SwapFree' | logger -t meminfo ; 
cat /proc/tffs | grep fill | logger -t tffs; 
cat /proc/net/ip_conntrack | wc -l | logger -t conntrack-wc-l ; 
cat /proc/slabinfo | grep -E '^#|conntr' | logger -t slabinfo ; 
sleep 300; 
done ) &

Vielleicht erfahren wir dadurch mehr.


Dirk

 

[derheimi]

Das Logging ist prima! Da bin ich jetzt echt gespannt...

Die 2816 buckets find ich übrigens sehr interessant, weil die Anzahl in Abhängigkeit von der RAM-Größe berechnet werden sollte. Und die 1919, die ich oben gepostet hatte, kommen von einem "normalen" Debian mit 256 MB RAM.
Wieviel RAM mit 2816 genau belegt werden könnte, kann ich grad nicht 100%ig berechnen, weil die "bytes per conntrack" kleiner ist (damit wird objperslab tendenziell größer). Schätzungsweise erstreckt sich der Bereich von 900kB bis ca. 7 MB (!). Da wird es unter "Volllast" natürlich schon ziemlich eng...

 

[magenbrot]

bei der 7170 kommt die gleich Meldung beim Laden des conntrack-moduls wie bei Dirk:

kernel: ip_conntrack version 2.1 (2816 buckets, 22528 max) - 248 bytes per conntrack

Habe auch mal das Logging von Dirk übernommen, mal sehn was das Ding so ausspuckt.

Gruß
Oli

 

[dsteinkopf]

so. Noch kein Absturz aber hier schonmal ein paar Ergebnisse:
Ich glaube, wir sind da schon sehr nah dran:

root@martini:/data/ . # fgrep "slabinfo: ip_conntrack " /var/log/messages
Apr 26 11:58:45 fritz slabinfo: ip_conntrack          27     48    248   16    1 : tunables  120   60    0 : slabdata      3      3      0 
Apr 26 11:59:45 fritz slabinfo: ip_conntrack          38     48    248   16    1 : tunables  120   60    0 : slabdata      3      3      0 
Apr 26 12:04:45 fritz slabinfo: ip_conntrack          37     48    248   16    1 : tunables  120   60    0 : slabdata      3      3      0 
Apr 26 12:09:46 fritz slabinfo: ip_conntrack          48     48    248   16    1 : tunables  120   60    0 : slabdata      3      3      0 
Apr 26 12:14:46 fritz slabinfo: ip_conntrack          36     48    248   16    1 : tunables  120   60    0 : slabdata      3      3      0 
Apr 26 12:19:47 fritz slabinfo: ip_conntrack          48     64    248   16    1 : tunables  120   60    0 : slabdata      4      4      0 
Apr 26 12:24:47 fritz slabinfo: ip_conntrack          57     64    248   16    1 : tunables  120   60    0 : slabdata      4      4      0 
Apr 26 12:29:48 fritz slabinfo: ip_conntrack          54     64    248   16    1 : tunables  120   60    0 : slabdata      4      4      0 
Apr 26 12:34:48 fritz slabinfo: ip_conntrack          55     64    248   16    1 : tunables  120   60    0 : slabdata      4      4      0 
Apr 26 12:39:49 fritz slabinfo: ip_conntrack          56     64    248   16    1 : tunables  120   60    0 : slabdata      4      4      0 
Apr 26 12:44:49 fritz slabinfo: ip_conntrack          47     64    248   16    1 : tunables  120   60    0 : slabdata      4      4      0 
Apr 26 12:49:50 fritz slabinfo: ip_conntrack          61     80    248   16    1 : tunables  120   60    0 : slabdata      5      5      0 
Apr 26 12:54:50 fritz slabinfo: ip_conntrack          73     80    248   16    1 : tunables  120   60    0 : slabdata      5      5      0 
Apr 26 12:59:51 fritz slabinfo: ip_conntrack          80     80    248   16    1 : tunables  120   60    0 : slabdata      5      5      0 
Apr 26 13:04:51 fritz slabinfo: ip_conntrack          61     96    248   16    1 : tunables  120   60    0 : slabdata      6      6      0 
Apr 26 13:09:52 fritz slabinfo: ip_conntrack          66     96    248   16    1 : tunables  120   60    0 : slabdata      6      6      0 
Apr 26 13:14:52 fritz slabinfo: ip_conntrack          65     96    248   16    1 : tunables  120   60    0 : slabdata      6      6      0 
Apr 26 13:19:53 fritz slabinfo: ip_conntrack          73     96    248   16    1 : tunables  120   60    0 : slabdata      6      6      0 
Apr 26 13:24:53 fritz slabinfo: ip_conntrack          82    112    248   16    1 : tunables  120   60    0 : slabdata      7      7      0 
Apr 26 13:29:54 fritz slabinfo: ip_conntrack          87    112    248   16    1 : tunables  120   60    0 : slabdata      7      7      0 
Apr 26 13:34:54 fritz slabinfo: ip_conntrack          97    112    248   16    1 : tunables  120   60    0 : slabdata      7      7      0 
Apr 26 13:39:55 fritz slabinfo: ip_conntrack         100    112    248   16    1 : tunables  120   60    0 : slabdata      7      7      0 
Apr 26 13:44:56 fritz slabinfo: ip_conntrack         102    112    248   16    1 : tunables  120   60    0 : slabdata      7      7      0 
Apr 26 13:49:56 fritz slabinfo: ip_conntrack         112    112    248   16    1 : tunables  120   60    0 : slabdata      7      7      0 
Apr 26 13:54:57 fritz slabinfo: ip_conntrack         112    112    248   16    1 : tunables  120   60    0 : slabdata      7      7      0 
Apr 26 13:59:57 fritz slabinfo: ip_conntrack          97    112    248   16    1 : tunables  120   60    0 : slabdata      7      7      0 
Apr 26 14:04:58 fritz slabinfo: ip_conntrack         103    112    248   16    1 : tunables  120   60    0 : slabdata      7      7      0 
Apr 26 14:09:58 fritz slabinfo: ip_conntrack         110    112    248   16    1 : tunables  120   60    0 : slabdata      7      7      0 
Apr 26 14:14:59 fritz slabinfo: ip_conntrack          94    112    248   16    1 : tunables  120   60    0 : slabdata      7      7      0 
Apr 26 14:19:59 fritz slabinfo: ip_conntrack         112    112    248   16    1 : tunables  120   60    0 : slabdata      7      7      0 
Apr 26 14:25:00 fritz slabinfo: ip_conntrack         115    128    248   16    1 : tunables  120   60    0 : slabdata      8      8      0 
Apr 26 14:30:00 fritz slabinfo: ip_conntrack         102    128    248   16    1 : tunables  120   60    0 : slabdata      8      8      0 
Apr 26 14:35:01 fritz slabinfo: ip_conntrack         119    128    248   16    1 : tunables  120   60    0 : slabdata      8      8      0 
root@martini:/data/ . #

root@martini:/data . # fgrep "wc-l" /var/log/messages
Apr 26 11:59:09 fritz conntrack-wc-l: 31 
Apr 26 11:59:45 fritz conntrack-wc-l: 23 
Apr 26 12:04:45 fritz conntrack-wc-l: 30 
Apr 26 12:09:46 fritz conntrack-wc-l: 28 
Apr 26 12:14:46 fritz conntrack-wc-l: 29 
Apr 26 12:19:47 fritz conntrack-wc-l: 40 
Apr 26 12:24:47 fritz conntrack-wc-l: 42 
Apr 26 12:29:48 fritz conntrack-wc-l: 39 
Apr 26 12:34:48 fritz conntrack-wc-l: 53 
Apr 26 12:39:49 fritz conntrack-wc-l: 55 
Apr 26 12:44:49 fritz conntrack-wc-l: 47 
Apr 26 12:49:50 fritz conntrack-wc-l: 58 
Apr 26 12:54:50 fritz conntrack-wc-l: 58 
Apr 26 12:59:51 fritz conntrack-wc-l: 68 
Apr 26 13:04:51 fritz conntrack-wc-l: 61 
Apr 26 13:09:52 fritz conntrack-wc-l: 65 
Apr 26 13:14:52 fritz conntrack-wc-l: 65 
Apr 26 13:19:53 fritz conntrack-wc-l: 72 
Apr 26 13:24:53 fritz conntrack-wc-l: 81 
Apr 26 13:29:54 fritz conntrack-wc-l: 86 
Apr 26 13:34:54 fritz conntrack-wc-l: 82 
Apr 26 13:39:55 fritz conntrack-wc-l: 85 
Apr 26 13:44:55 fritz conntrack-wc-l: 95 
Apr 26 13:49:56 fritz conntrack-wc-l: 104 
Apr 26 13:54:57 fritz conntrack-wc-l: 96 
Apr 26 13:59:57 fritz conntrack-wc-l: 90 
Apr 26 14:04:58 fritz conntrack-wc-l: 95 
Apr 26 14:09:58 fritz conntrack-wc-l: 96 
Apr 26 14:14:59 fritz conntrack-wc-l: 94 
Apr 26 14:19:59 fritz conntrack-wc-l: 98 
Apr 26 14:25:00 fritz conntrack-wc-l: 101 
Apr 26 14:30:00 fritz conntrack-wc-l: 99 
Apr 26 14:35:01 fritz conntrack-wc-l: 117 
Apr 26 14:40:01 fritz conntrack-wc-l: 127 
root@martini:/data . #

Nur - was kann man jetzt daraus schließen?


Dirk

 

[derheimi]

Interpretation der Werte: über die Box laufen zur Zeit gerade ca. 120 offene Verbindungen,
dafür werden 8 x 4kB also 32 kB RAM verbraucht - also eigentlich gar nicht so viel.

Noch was anderes, ein bisschen [OT]: Das hier

...
MemTotal:        30360 kB
...
PageTables:        [b]444 kB[/b]
...

hat mich schon irgendwie stutzig gemacht. Man braucht für 32 MB RAM eigentlich keine 444 kB an PageTables, sondern eigentlich nur 8 Pagetables + 1 PageGlobalDirectory, macht 36 kB, um die 32 MB RAM in den Adressraum einzublenden. Dazu kommen dann noch ein paar kB für die Einblendung des Flashmemory und ev. PCI-Adressen, die für I/O-Kommunikation mit z.B. der NIC fällig werden. Knapp 400kB dafür sind eindeutig zu viel.

Die Ursache: in der Kernel-Config gibt es eine Zeile

CONFIG_MIPS_OHIO_PHY_MEMSTART=0x14000000

, die besagt, dass der RAM an eben jener Adresse (320 MB) im Adressraum beginnt. Ein

fb# cat /proc/iomem
14000000-14226fff : reserved
  14000000-14184717 : Kernel code
  14184718-141df0bf : Kernel data
14227000-15ffffff : System RAM
a8610000-a86107ff : cpmac0

bestätigt dies auch. Wenn ich die Sourcen richtig verstanden habe, liegt der Flash bei 256 MB im Adressraum.
Ich behaupte mal -ohne die Hardware jetzt 100%ig zu kennen-, dass das hier (sagen wir es diplomatisch) suboptimal ist, weil halt 320 - 8 MB unnütz mitverwaltet werden. Na gut, irgendwie muss es ja gemacht werden.[/OT]

Was hat das ganze mit ip_conntrack zu tun? Nicht viel, außer das die Kernelvariable, die für die Berechnung des von ip_conntrack verwendeten Speichers zu Rate gezogen wird, auf einmal nicht mehr 32 MB enthält, sondern plötzlich 320 + 32 MB. Damit wird hier natürlich der conntrack-Cache extrem überdimensioniert, so dass man hier wirklich mit dem oben bereits beschriebenen Parameter arbeiten sollte. Also

modprobe ip_conntrack hashsize=[b]n[/b]

, wobei n zwischen 16 (kleiner wird ignoriert) und 256 (Standard für die 32 MB RAM) liegen sollte.
Aber ob das letztendlich die Lösung für das Problem ist, kann ich noch nicht sagen...

 

[magenbrot]

das klingt doch schonmal sehr interessant.

Ich hab nun die Box rebootet und lade das conntrack-modul mit einer hashsize von 256. Mal sehen ob das erfolgreich ist.

 

[dsteinkopf]

ok...
Aber warum nimmt die Anzahl der Verbindungen zu? Ich selber bin gar nicht vor ort - da passiert bestimmt nichts, was 120 Verbindungen rechtfertigen würde. Evtl. liegt das ja nur an irgendwelche Timeouts, bis die Einträge dort gelöscht werden, sodass eine größere Tabelle tatsächlich helfen würde.

Leider ist meine Box grad tot und ich komm nicht mehr dran...

Was ich jetzt noch nicht verstanden, welchen der genannten Parameter der Hashsize-Parameter verändert und wie man aus den Logs die Belegung des Conntrack-Speichers der Hashtabelle ablesen kann. Wird da wirklich was nahezu voll? Können das die Logs belegen?


Dirk