Problem mit iptables auf der SL WLAN

Hallo,

ich habe längere Zeit den ds-mod24 verwendet. Dabei habe ich das Iptables mit FWbuilder konfiguriert.
Nun habe ich freetz entdeckt und erfahren, dass meine SL WLAN auch schon mit 2.6-er Kernel verwendet werden kann. (Profil 3020)
Hab mich riesig gefreut, dass ich jetzt umsteigen kann und nach anfänglichen Schwierigkeiten (lange nichts mehr gemacht) läuft die Box mit Freetz (SVN) stabil. Jedoch habe ich ein Problem. Wenn ich mein iptables-Skript einspiele, welches mit dem 2.4 ohne Probleme funktioniert hatte, habe ich praktisch kein Internet .
Kleine Seiten wie Google gehen, größere Seiten und Downloads jedoch nicht.
der Kernel meldet INVALID state.

Beispiel:
Feb 9 00:32:00 fritz user.debug kernel: INVALID state -- DENY IN=lan OUT=dsl SRC=192.168.238.25 DST=195.30.230.87 LEN=64 TOS=0x00 PREC=0x00 TTL=63 ID=8290 DF PROTO=TCP SPT=49550 DPT=80 WINDOW=179 RES=0x00 ACK URGP=0
Feb 9 00:32:00 fritz user.debug kernel: INVALID state -- DENY IN=lan OUT=dsl SRC=192.168.238.25 DST=195.30.230.87 LEN=52 TOS=0x00 PREC=0x00 TTL=63 ID=64047 DF PROTO=TCP SPT=49548 DPT=80 WINDOW=179 RES=0x00 ACK FIN URGP=0

An welcher Stelle kann ich noch schrauben, damit es funktioniert? Wenn ich die invaliden Pakete durchlasse, gibt es auch keine Besserung .

das ging ja schnell

Die Regeln wollte ich nicht posten, da der FWBuilder jede Regel etwas größer schreibt.
iptabels-cgi ist zwar drinne, wird aber nicht verwendet/ist nicht aktiv. Die Module lade ich im Skript selbst.

In der Zwischenzeit bin ich auf

echo 1 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_be_liberal

gestoßen. Damit funktioniert es
Jedoch weiss ich nicht, was dieser Befehl tut. Sind irgendwelche "Nebenwirkungen" bekannt?

Beobachtet habe ich es noch nicht. Ich lasse jetzt ein tail -f /var/log/message mitlaufen. Vielleicht sehe ich bei einem Neustart was. Heute morgen war die Box nicht mehr erreichbar so dass ich sie neu starten musste. Ob es hier dran lag kann ich nicht sagen.

Kennt jemand eine andere Lösung ohne Nebenwirkungen? Es soll wohl was mit Window Size Handling ab Kernel 2.6.9 zu tun haben. Bin auch bereit auf den Clients was anzupassen, wenn ich wüste was. Die Clients sind alle Linux.

Bei mir lief die Box gerade über 6 Stunden durch.
-Es sind alle conntrack Module geladen
-ip_conntrack_tcp_be_liberal ist aktiviert
-dropbear war aktiv mit einer Session (tail -f /var/log/messages)
-mldonkey hat für stetigen Datenverkehr gesorgt. (Nur Partner suchen, keine Up- oder Downloads)

Die Box habe ich selber neu durchgestartet, da irgendwie die DHCP Requests nicht mehr als related erkannt wurden und der PC daher keine neue IP Adresse beziehen konnte. Nach einer manuellen IP-Zuweisung konnte ich mich jedoch mit der Box verbinden.
Der Neustart hat nichts gebracht, also habe ich eine neue Regel erstellt, um die Pakete explizit durchzulassen. Evtl. hatte ich die Regel und die ist mir bei den ganzen Tests "abhanden gekommen".

Ich werde die Stabilität weiter testen. 6 Stunden ist schonmal Ok. Früher mit 2.4-Kernel und der selben Konfiguration lief die Box jedoch Monate lang ohne Probleme durch. Iptables ohne conntrack macht als Firewall für mich wenig sinn (wg. related, established).

Den Thread habe ich gelesen und bin gerade auf eine Idee gekommen. Wir müssen nicht den Kernel auf 2.6.24 bringen, es reicht auch auf 2.6.13.5.
Ich habe gerade
ftp://ftp.kernel.org/pub/linux/kernel/v2.6/patch-2.6.13.5.gz

eingespielt. Das Einspielen lief ohne große Probleme durch. Einige Patches waren bereits enthalten. Diese sind wahrscheinlich aus 2.6.13.1. (Der o.g. Patch bezieht sich auf 2.6.13).
Folgende Dateien wurden aktualisiert:

patching file arch/s390/appldata/appldata_base.c
patching file arch/sparc64/kernel/entry.S
patching file arch/sparc64/kernel/irq.c
patching file arch/sparc64/kernel/rtrap.S
patching file arch/sparc64/lib/VISsave.S
patching file arch/um/kernel/skas/include/mmu-skas.h
patching file arch/um/kernel/skas/mmu.c
patching file arch/x86_64/ia32/ia32_ioctl.c
patching file drivers/char/drm/drm_stub.c
patching file drivers/ide/pci/cmd64x.c
patching file drivers/ide/pci/hpt34x.c
patching file drivers/ide/pci/hpt366.c
patching file drivers/ieee1394/sbp2.c
patching file drivers/net/forcedeth.c
patching file drivers/net/skge.c
patching file drivers/net/sungem.c
patching file drivers/net/sunhme.c
patching file drivers/net/wireless/orinoco.c
patching file drivers/pcmcia/yenta_socket.c
patching file drivers/usb/serial/ftdi_sio.c
patching file fs/compat_ioctl.c
patching file fs/exec.c
patching file fs/jfs/inode.c
patching file fs/namei.c
patching file include/asm-um/pgalloc.h
patching file include/asm-um/pgtable-3level.h
patching file include/linux/proc_fs.h
patching file include/linux/sysctl.h
patching file include/net/ip_vs.h
patching file kernel/sysctl.c
patching file mm/mempolicy.c
patching file net/ipv4/ipvs/ip_vs_conn.c
patching file net/ipv4/ipvs/ip_vs_core.c
patching file net/ipv4/ipvs/ip_vs_sync.c
patching file net/ipv4/netfilter/ipt_MASQUERADE.c
patching file net/ipv4/tcp_bic.c
patching file net/ipv4/tcp_input.c
patching file net/ipv4/tcp_minisocks.c
patching file net/ipv6/udp.c
patching file security/keys/request_key_auth.c

Die Box ist gebootet und läuft ganz normal.
Bin gespannt, ob es was gebracht hat.

Nachtrag: Hab mich im Dateisystem bei den Kernel Modules ungeschaut, die net/ipv4/netfilter/ wurden alle neu kompeliert.

I aplied the patch directly on source/avm-gpl-04.33/base/kernel_8mb_26_build/kernel/linux-2.6.13.1 with zcat patch-2.6.13.5.gz | patch -p1

On normal make run the modules are compiled.

The version number of kernel is not changed (2.6.13.1) because this change is rejected.

Um nicht off-topic zu werden, werde ich zum Thema "Iptables zum Laufen bringen" weiter in dem Thread schreiben, den cuma genannt hatte.
Vorweg, Meine SL-WLAN hat schon einen Uptime von 2 Tagen mit aktivierten IP-Tables (auch conntrack) ohne Module neu zu laden und dem kompletten Traffic durch IP-Tables ( Exposed Host und iptables-NATten) und hat diversen Lastests (Bittorrent, FTP Download) überstanden.

Also, zurück zum on-topic.
Der 3-Stündige Absturz von IP-Tables hat wohl nichts mit ip_conntrack_tcp_be_liberal oder mit meiner ursprünglichen Frage zu tun.

Also, zurück zu der anfänglichen Frage: Kann mir jemand sagen, was ip_conntrack_tcp_be_liberal genau tut?
Ich habe leider nicht viel zu dem Thema gefunden. Es wird nur als "Heilmittel" für mein Problem in diversen Foren angepriesen.