[buug-l] netfilter-Probleme mit 2.6.9
Christoph Biedl
cbiedl at gmx.de
Son Okt 31 01:09:08 CEST 2004
Es wurde schon geunkt, Linux Kernel 2.6.9 wäre mal wieder ein brown
paper bag release, und zumindest im Bereich netlink fliegt bei mir
ein Rechner ohne patch reproduzierbar auf die Nase, und beim Laden von
maestro oopste es, allerdings ohne weitere Folgen.
Nun aber macht netfilter einigen Ärger und zuerst die Frage, ob jemand
ähnliches berichten kann oder gehört hat.
Beobachtung: Ziemlich viel "invalid" Zeugs.
Wer sinngemäß "-m state --state INVALID -j LOG --log-prefix 'invalid: '"
in den chains hat, der sieht dann gelegentlich was im Logfile. Soweit
erkennbar, passiert das dann, wenn jemand meine IP spooft und damit ein
Paket in die Welt schickt, das zurückkommt und mein Kernel von nichts
weiß - so weit, so gut.
Nun allerdings passiert mir das erheblich häufiger, aber ohne
erkennbares Muster: In einer stehenden (tcp-)Verbindung nennt der Kernel
ein Paket plötzlich "invalid", und darüber bricht danach die Verbindung
zusammen. Als nächstes werde ich wohl solchen Paketen ein '-j ACCEPT'
spendieren, aber das ist keine Lösung.
Beispiel:
kernel: invalid: IN=eth0 OUT= MAC= SRC=$(src) DST=$(dst) \
LEN=52 TOS=0x10 PREC=0x00 TTL=63 ID=18300 DF PROTO=TCP SPT=42804 DPT=22 \
WINDOW=16022 RES=0x00 ACK URGP=0
Es liegt, mit tcpdump nachgeprüft, _nicht_ am window scaling problem.
Das hatte ich neulich schon anderswo, ich weiß, wie sich sowas anfühlt.
Details: http://lwn.net/Articles/92727/
Sowieso sind alle beteiligten Rechner ($src, router, $dst) Linux.
Irgendjemand, bei dem es jetzt klingelt?
So nebenbei, gibt es irgendwo eine Dokumentation, was der "INVALID"
state eigentlich genau ist? Ich für mich übersetze es mit "Der Kernel
müßte zu diesem Paket eine Vorgeschichte (via conntrack) haben und dann
wäre es RELATED und/oder ESTABLISHED. Weil nichts davon zutrifft, ist
mit diesem Paket was faul." Ist das sinngemäß richtig?
Der Blick in die Kernelsourcen ist ohne Wissen um das Drumherum wenig
hilfreich.
Achja, Downgrade auf 2.6.8.1 ist leider keine Option - es sei denn, ich
mache mal für die Unterstützung bestimmter Hardware einen Backport.
Dafür ist der Leidensdruck (noch) nicht hoch genug.
Christoph