[Problem] telefon-Daemon über 90% Last wegen ip_conntrack

jebu81 · 31 Mrz 2006

Hallo,

grundlegend ging es um das Problem hier http://www.ip-phone-forum.de/showthread.php?p=558041#post558041. Der LCR Auto Updater funktioniert ja mittlerweile problemlos mit dem ds-mod, aber so bald ich die Firewall starte kommt der telefon-Daemon arg in Bedrängnis. Spätestens dann, wenn man einfach nur den Hörer abnimmt und der AVM-Callmonitor aktiv wird.

Mittlerweile bin ich der Meinung, dass es an den ip_conntrack Modulen liegt. Im Syslog sieht das dann z.B. so aus:

Code:

2006-03-30 23:05:39	User.Warning	192.168.171.1	kernel: SRC=127.0.0.1 DST=127.0.0.1 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=4 PROTO=TCP SPT=1011 DPT=1367 SEQ=323337102 ACK=332719769 WINDOW=16384 RES=0x00 ACK PSH FIN URGP=0 OPT (0101080A00AC58AF00AC0388) ip_conntrack_tcp: INVALID: invalid

Die Meldungen wiederholen sich, der telefon verursacht danach besagte 90+% Last, dauerhaft bis ~~zum nächsten reboot~~ man ihn von Hand beendet und neu startet.

Gibt es da vielleicht erstmal einen workaround um die ip_conntrack Module abzuschalten?
modprobe -r ip_conntrack hat nichts gebracht. Hab ich mir auch nur zusammengesucht, hab von Linux leider keinen richtigen Plan.

danisahne · 31 Mrz 2006

Da hilft wohl nur firewall-cgi wegzulassen und dir ne eigene iptables Firewall ohne conntrack zu bauen. Ein Fehler ist glaub ich noch in firewall-cgi, weil ich da glaube ich den Verkehr an das Loopback Interface nicht explizit erlaube. Das überprüfe ich noch, aber ob das mit diesem Problem zusammenhängt bezweifle ich mal (ein Versuch ist es wert).

Mfg,
danisahne

jebu81 · 2 Apr 2006

Ich habe jetzt ein bisschen in den Firewall-Skripten gestöbert, einen Eintrag für ip_conntrack konnte ich aber nirgends finden. Wovon hängt den ab, dass ip_conntrack geladen bzw. benutzt wird?

Btw. Bin ich der Einzige der das Problem hat? Müsste doch eigentlich jeden betreffen der iptables auf der Box nutzt. Oder etwa nicht!?
Den AVM-Callmonitor per #96*4* ausschalten ändert nichts, der pustet trotzdem noch was auf Sourceport 1011/TCP raus.

danisahne · 4 Apr 2006

jebu81 schrieb:
Ich habe jetzt ein bisschen in den Firewall-Skripten gestöbert, einen Eintrag für ip_conntrack konnte ich aber nirgends finden. Wovon hängt den ab, dass ip_conntrack geladen bzw. benutzt wird?

Eine Regel

Code:

iptables ... -m state --state ...

setzt meines Wissens conntrack vorraus. Ist das Kernel Modul noch nicht geladen wird es automatisch nachgeholt.

Mfg,
danisahne

jebu81 · 4 Apr 2006

Jepp, hab' ich mittlerweile auch raus. Belese mich gerade ein wenig was iptables angeht.

14.04.01ds0.2.3 ist schon in Arbeit...

mastertester · 21 Apr 2006

Konnte dieses Problem eigentlich mittlerweile gelöst können?? Ich würde ja so gerne die Firewall wieder einsetzen….

Gruß
mastertester

jebu81 · 21 Apr 2006

Ich habe mich hier http://www.ip-phone-forum.de/showthread.php?t=100250 zwischenzeitlich mit danisahne drüber unterhalten. An der Situation hat sich aber trotzdem nichts geändert.

Ich habe momentan ein halbwegs selbstgestricktes Regelwerk im Einsatz. Mittels Firewall Builder (http://www.fwbuilder.org/) zusammengeklickt und dann einfach die puren iptables-Befehle aus dem generierten Script in ein neues sh-Script kopiert. Allerdings muss man zusätzlich noch alle state-Einträge entfernen, damit ip_conntrack eben nicht benutzt wird.

Aus

Code:

IPTABLES -A INPUT  -i eth1 -p icmp  -m icmp  --icmp-type any  -m state --state NEW  -j eth1_In_RULE_5

wird also z.B.

Code:

IPTABLES -A INPUT  -i eth1 -p icmp -j eth1_In_RULE_5

Das ist wohl nicht so sicher wie mit connection tracking mittels ip_conntrack, aber immer noch besser als gar nix. Trenne mit meinem Regelwerk einen WRT54GS (als fon.com-Hotspot) an LAN B von meinem restlichen Netz.

dsteinkopf · 25 Apr 2006

danisahne schrieb:
Ein Fehler ist glaub ich noch in firewall-cgi, weil ich da glaube ich den Verkehr an das Loopback Interface nicht explizit erlaube. Das überprüfe ich noch, aber ob das mit diesem Problem zusammenhängt bezweifle ich mal (ein Versuch ist es wert).

Nein, daran liegt es nicht: Ich habe meine eigenen iptables-Regeln, wo loopback-Verkehr explizit als erstes erlaubt wird.

Mir scheint eher (wie ich schon im User-Support-Thread geschrieben habe), dass das ip_conntack-Modul nach dem Laden unmittelbar anfängt, eigenständig Pakete zu verwerfen, die nicht zu einer ihm bekannten Verbindung gehören - und zwar unabhängig von allen iptables-chains und -policies. Das scheint zu passieren, bevor die Pakete an den iptables-chains vorbeikommen.

Scheinbar wird diese localhost-Verbindung zu Port 1011 hergestellt bevor das conntrack-Modul geladen wird und sie lernen könnte.

Lösungsideen:

1. Das conntrack-Modul (optional?) fest in den Kernel integriegen. So war es ja bei älteren ds-mods auch noch und da gab es keine Probleme.

2. Herausfinden, warum das so ist, dass das conntrack-Modul die Pakete verwirft, bevor man sie mit iptables-Regeln akzeptieren könnte.

@danisahne: Punkt 1 müsste doch relativ einfach machbar sein, oder? Kann ich das selber?

Danke,

Dirk

jebu81 · 25 Apr 2006

dsteinkopf schrieb:
Mir scheint eher (wie ich schon im User-Support-Thread geschrieben habe), dass das ip_conntack-Modul nach dem Laden unmittelbar anfängt, eigenständig Pakete zu verwerfen, die nicht zu einer ihm bekannten Verbindung gehören - und zwar unabhängig von allen iptables-chains und -policies. Das scheint zu passieren, bevor die Pakete an den iptables-chains vorbeikommen.

Sehe ich auch so. Ich habe mit meinen Regeln ja nur eth1 reglementiert, die restlichen Interfaces dürfen alles. Trotzdem, sobald z.B. eine Regel mittels -m state --state blabla auf Interface eth1 geladen wird, springt ip_conntrack an und stört "auch" den loopback-Verkehr des telefon-Dämon.

Lösungvorschlag 1 deckt sich mit meinen Erinnerungen, dass es das Problem bei früheren ds-mods nicht gab.

Becka · 26 Apr 2006

wie kann ich eigentlich die genaue last rausfinden (gesamt und pro process), ich mach bisher immer cat /proc/loadavg aber kann nur mit dem ersten wert ein bisschen was anfangen

danisahne · 26 Apr 2006

Versuch es mal mit

Code:

top

dsteinkopf · 28 Apr 2006

Ich schaffe es nicht, den kernel neu zu kompilieren, um ip_conntrack nicht als Modul zu laden, sondern fest einzubinden. Ich habe mich an die Anleitung in http://wiki.ip-phone-forum.de/software:ds-mod:howtos gehalten.

Die letzten Zeilen den make kernel-precompiled sind immer

Code:

unresolved symbol register_isdn in file /lib/modules/2.4.17_mvl21-malta-mips_fp_le/kernel/drivers/isdn/avmb1/capidrv.o
unresolved symbol ip_ct_refresh in file /lib/modules/2.4.17_mvl21-malta-mips_fp_le/kernel/net/ipv4/netfilter/ip_conntrack_proto_esp.o
unresolved symbol ip_ct_refresh in file /lib/modules/2.4.17_mvl21-malta-mips_fp_le/kernel/net/ipv4/netfilter/ip_conntrack_proto_gre.o
unresolved symbol ip_ct_refresh in file /lib/modules/2.4.17_mvl21-malta-mips_fp_le/kernel/net/ipv4/netfilter/ip_conntrack_pptp.o
unresolved symbol __ip_conntrack_confirm in file /lib/modules/2.4.17_mvl21-malta-mips_fp_le/kernel/net/ipv4/netfilter/ipt_ROUTE.o
unresolved symbol ip_conntrack_in in file /lib/modules/2.4.17_mvl21-malta-mips_fp_le/kernel/net/ipv4/netfilter/ipt_ROUTE.o

Und das kernel/kernel-4mb.bin ist nur 413 kB groß...

Ich denke, dass ich alles nach der Anleitung gemacht habe, ich habe auch extra nochmal mit frisch ausgepacktem Mod angefangen. Und dann

Code:

make make toolchain && make libs && make kernel-precompiled

.

Hat das schon jemand geschafft?

Danke,

Dirk

danisahne · 28 Apr 2006

Die unresolved symbols bekomme ich auch, ich ignoriere sie. Kann sein, dass die betreffenden Module nicht geladen werden können, kann aber auch sein, dass das depmod.pl Skript fehlerhaft ist. Wer weiß, hab ich noch nicht getestet.

Wie hast du denn den Kernel konfiguriert? Aus deiner Beschreibung geht das nicht hervor oder wolltest du erstmal den Kernel aus dem Mod reproduzieren?

Mfg,
danisahne

dsteinkopf · 28 Apr 2006

Im ersten Schritt wollte ich tatsächlich nur mal sehen, ob ich den Kernel aus dem Mod reproduzieren kann. Wenn Du die gleichen Meldungen hast, scheint das ja soweit "richtig" zu sein.

Als nächstes wollte ich das Modul ip_conntrack fest in den Kernel integrieren - in der Hoffnung, das Problem mit der 100%-CPU-Last des telefon-Dämons zu lösen.

Sehe ich es richtig, dass ich nach dem Compilieren des Kernels einfach wieder make menuconfig und make sagen kann - und dann habe ich ein Image mit "meinem" Kernel?

Dirk

danisahne · 29 Apr 2006

Genau so ist es. `make kernel-precompiled' baut den vorkompilierten Kernel neu und ein erneutes make baut das Image mit dem neuen Kernel.

EDIT: Noch ein Tipp:

Code:

make kernel-menuconfig

dsteinkopf · 29 Apr 2006

danisahne schrieb:
Noch ein Tipp:

Code:

make kernel-menuconfig

Klar. Stand ja auch schon im Wiki. Trotzdem danke!

Erfolg!
Ich habs jetzt geschafft:

Integration des ip_conntrack fest in den Kernel (in make kernel-menuconfig: unter Networking options ---> IP: Netfilter Configuration ---> Connection tracking: * statt M)
Kernel kompilieren wie im Wiki beschrieben
Image bauen mit "make" und installieren.
Hurra: Telefon-Dämon braucht nicht mehr 100% ! Die Kernel-Meldungen, dass Pakete von 127.0.0.1 nach 127.0.0.1 abgewiesen wurden, kommen auch nicht mehr - hing offenbar wirklich zusammen.
Das Problem, dass Pakete, die ip_conntrack für "invalid" hält, abgewiesen werden, bevor sie durch die iptables-chains gehen, besteht immer noch.

Dirk

jebu81 · 29 Apr 2006

Das hört sich gut an!

Weiter als diesen Fehler hier bin ich aber noch nicht gekommen:

Code:

/bin/sh: mipsel-unknown-linux-gnu-gcc: command not found
make[2]: *** [init/main.o] Error 127
make[2]: Leaving directory `/cygdrive/s/ds-0.2.5/source/ref-4mb/kernel/kernel_oh
io-8mb_build/kernel/linux-2.4.17_mvl21'
make[1]: *** [create_kernel] Error 2
make[1]: Leaving directory `/cygdrive/s/ds-0.2.5/source/ref-4mb/kernel/kernel_oh
io-8mb_build'
make: *** [source/ref-4mb/kernel/kernel_ohio-8mb_build/kernel/linux-2.4.17_mvl21
/ram_zimage.bin] Error 2

make menuconfig -> ok
make kernel-menuconfig -> ok
make kernel-precompiled -> Fehler s.o.
Ich mache das unter Cygwin. Wenn ich mich eben nicht zweimal verguckt habe, dann sollte ich alle benötigten Cygwin-Pakete installiert haben.

Oder muss ich vorher den Cross-Compiler und die Toolchain neu erstellen?

danisahne · 29 Apr 2006

jebu81 schrieb:
Oder muss ich vorher den Cross-Compiler und die Toolchain neu erstellen?

Auf jeden Fall. Ob das unter Cygwin klappt, habe ich noch nicht ausprobiert. Beachte noch, dass in der aktuellen Toolchain (ds-0.2.5) ein kleiner Fehler in den Makefiles ist. Du mußt 3 Zeilen aus der Datei uclibc.mk entfernen (siehe danisahne-mod Thread, erstes Posting ganz unten).

jebu81 · 29 Apr 2006

Seit Deiner Antwort rödelt der jetzt an make toolchain rum. Er hat am Anfang einmal flex und dann noch bison als fehlende Pakete bemängelt. Habe ich dann nachinstalliert, lief dann aber ohne Fehler und ohne Ende. Bin ich da irgendwie in eine Endlosschleife geraten? Mittlerweile kommen mir die Zeilen teilweise schon bekannt vor...

Die drei Zeilen in der uclibc.mk habe ich bei mir nicht gefunden. Hast du das irgenwann korrigiert oder hab ich Tomaten auf den Augen und meine Suche funktioniert auch nicht?

danisahne · 29 Apr 2006

Unter Cygwin dauert alles viel viel länger. Auf meinem Athlon64 dauert das Erstellen der Toolchain ja schon deutlich über ner halben Stunde. Die Zeilen in der uclibc.mk sind nur in der Version 0.2.5.

[Problem] telefon-Daemon über 90% Last wegen ip_conntrack

Neuer User

Aktives Mitglied

Neuer User

Aktives Mitglied

Neuer User

Mitglied

Neuer User

Mitglied

Neuer User

Neuer User

Aktives Mitglied

Mitglied

Aktives Mitglied

Mitglied

Aktives Mitglied

Mitglied

Neuer User

Aktives Mitglied

Neuer User

Aktives Mitglied

Statistik des Forums