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

jebu81

Neuer User
Mitglied seit
5 Jan 2005
Beiträge
178
Punkte für Reaktionen
0
Punkte
0
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.
 
Zuletzt bearbeitet:
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
 
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.
 
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
 
Jepp, hab' ich mittlerweile auch raus. Belese mich gerade ein wenig was iptables angeht.

14.04.01ds0.2.3 ist schon in Arbeit... :D
 
Konnte dieses Problem eigentlich mittlerweile gelöst können?? Ich würde ja so gerne die Firewall wieder einsetzen….


Gruß
mastertester
 
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.
 
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
 
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.
 
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
 
Versuch es mal mit
Code:
top
 
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
 
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
 
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
 
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
 
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
 
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?
 
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).
 
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?
 
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.
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.