Problem mit iptables auf der SL WLAN

Meine FritzBox hat noch die Version ds26-15.2 auf der 29.04.37 Firmware. Dementsprechend ist der Patch noch nicht auf meiner Box und ich muss den hashsize Befehl manuell aufrufen. Außerdem limitiert hashsize=256 nicht die maximale Anzahl an Verbindungen auf 256 sondern indirekt auf 2048, wenn ich das richtig verstanden hab (http://www.wallfire.org/misc/netfilter_conntrack_perf.txt).

Um meine Frage selbst zu beantworten, mit "cat /proc/net/ipconntrack" sieht man, dass conntrack alle Verbindungen beobachtet.

Interessanter Link!
dh bei meiner 3020 mit 14 MB Speicher sollten maximal 896 Verbindungen möglich sein. Allerdings stehen nicht die vollen 14 Mb zu Verfügung. Hab ich richtig gerechnet?

Nach Iptable ip_conntrack table set-up and tunning for high load UDP traffic und Firewalls hat ein ip_conntrack entry eine Größe von ca. 300 Bytes, also müssten jede Menge Verbindungen gleichzeitig überwacht werden können. derheimi wiederum berechnet in seinem Post die RAM Nutzung ganz anders aus.

Aber mal unabhängig davon, welcher der genannten Rechnungen richtig ist: Meine FritzBox 7170 hat bei einem Test mit etwas über 700 conntrack Einträgen trotzdem noch ca. 1 Mbyte Speicher frei. Die Anzahl der conntrack Einträge kann man übrigens mit oder anzeigen.

Hm, da ist die gleiche Rechnung in der PDF von dir:
(16384/256)*14= 896 (wie bei meiner letzten Rechnung)
2% von 14Mb sind 286,72kb dh 327,68byts pro Eintrag
Das soll dann wohl bedeuten dass so die maximale Anzahl beobachteter Verbindungen anhand des RAMs berechnet wird

auch aus der PDF, um deine andere Frage zu beantworten:

@olistudent: Die FritzBox läuft jetzt seit 12h mit


Ingesamt beträgt die uptime nun 4 Tage und 14:26 h (Stand 12.04.2008 09:13 Uhr).

@cuma: Wenn ca. 896 conntrack entries gerade mal eine ca. 286,72kb große conntrack table erzeugen, sollte meine FritzBox 7170 mindestens mal 3200 Einträge (1 Mbyte) überwachen können. Da ich die Benutzung von Tauschbörsen mit iptables unterbunden habe, sollten selbst bei 5 Clients die 3200 Einträge nur selten erreicht werden oder? Immerhin musste ich mehrere hundert Tabs im Firefox öffnen um auf 750 Einträge zu kommen

Hatte eben einen Neustart der FritzBox ca. 3h und 10min nachdem ich "/proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_be_liberal" auf 0 gesetzt hab.

WEARENOTALONE schrieb:

Immerhin musste ich mehrere hundert Tabs im Firefox öffnen um auf 750 Einträge zu kommen

Zum Vergrößern anklicken....

Da liegt ein grundsätzlicher Irrtum zugrunde: Ein Webbrowser öffnet beim Laden einer Webseite eine Verbindung zum Webserver, um die HTML-Seite zu laden, und evtl. auch parallel noch einige weitere, um Frameinhalte, Grafiken oder sonstiges nachzuladen (idR nicht mehr als 10 gleichzeitige Verbindungen). Wenn die Webseite fertig geladen ist, werden alle diese Verbindungen wieder geschlossen, unabhängig davon, wie lange die Seite im Fenster offen ist. Es gibt Seiten, die hin und wieder neue Verbindungen öffnen, aber das ist nicht die Regel.
Um mit dem Webbrowser also auf 200 gleichzeitige Verbindungen zu kommen, müsstest Du schon den Browser so starten, daß eine Session mit einer grossen Anzahl von Tabs geladen wird, so daß alle Tabs gleichzeitig geladen werden.

Öffne mal viele Tabs in Firefox (oder deinem Webbrowser der Wahl) hintereinander und schau dir an was mit "/proc/sys/net/ipv4/netfilter/ip_conntrack_count" passiert! Natürlich hatte ich nicht 750 Verbindungen gleichzeitig offen, aber das hab ich auch nicht geschrieben. Wie du in meinem Zitat nachlesen kannst, rede ich von 750 Einträgen in der conntrack table. Um die conntrack table zu füllen hab ich mehrere Instanzen von Firefox mit jeweils ein paar dutzend Tabs gleichzeitig geöffnet und mir ip_conntrack_count angeschaut. Wenn ich das richtig sehe, werden die Einträge nicht sofort aus der table entfernt, sondern erst nach nem Timeout. Vielleicht weil die Verbindungen nicht richtig beendet werden? Hinweis: half-closed connections

Ursache könnte natürlich auch das Connection: Keep-Alive sein. Ist aber eigentlich irrelevant wie man mehrere hundert Verbindungen in die conntrack bekommt. Das ganze ging ja von der falschen Annahmen der 256 möglichen Verbindungen aus (bitte eine Seite zurückblättern... ).

Bisher bin ich mit einer hashsize von 512 bzw. max 4096 conntrack Einträgen gut gefahren. Viel spannender ist die Frage, ob nun die Änderung von rp_filter oder ip_conntrack_tcp_be_liberal auf "1" bei mir dazu führt, dass die Box NICHT rebootet...

Also ich benutze eine relativ neue Freetz Version die diese Patches beinhaltet:

-Don't calculate hashsize, use 256 buckets
-ip_conntrack_tcp_be_liberal=1

Zum Vergrößern anklicken....

Meine Box hatte damit rebootet, was sie sonst nicht macht. "rp_filter" muss ich mal bei Gelegenheit testen, habe aber conntrack momentan nicht auf der Box... Wenn ich mir die Beschreibung dazu anschaue, kann es da eigentlich keinen Zusammenhang geben...

"The rp_filter variable sets up a reverse patch (rp) filter on the specific interface. What this means, is quite simple. All it does, is to validate that the actual source address used by packets correlates properly with our routing table, and that packets with this specific source IP address are supposed to get their replies back through that interface again."

Zum Vergrößern anklicken....

Anbei mal ein Patch für Freetz der die Änderungen von 2.6.13.1-5 enthält. axlweb hat auf Seite 2 geschrieben, dass er damit keine Reboots mehr hatte...

MfG Oliver

Hi, ich häng mich hier mal mit dran, um meine Erfahrungen mit dem leidigen Thema ip_conntrack zu berichten:

Auf meiner 7170 läuft 29.04.67freetz-devel-3062 mit dem Kernel-Patch aus Beitrag #52. Der Patch läuft bis auf "ftdi_sio.c" durch, was aber für iptables keine Rolle spielt. Der gepatchte Kernel meldet sich weiterhin als "2.6.13.1-ohio #1", was ja auch schon andere User hier berichtet haben. Ansonsten habe ich bisher keine Auffälligkeiten oder Probleme mit dem gepatchten Kernel bemerkt.

Zu iptables: Ich habe iptables_cgi in einer erweiterten Fassung installiert (siehe Ticket #378). iptables_cgi lädt ip_conntrack automatisch mit, wenn iptables über das WebInterface gestartet wird. Das ist sowohl in der derzeitigen Trunk-Version als auch in meiner Version aus dem Ticket 378 der Fall. Mein Patch betrifft im Wesentlichen nur die bisher nicht mögliche Konfiguration des output-interfaces. An den Modulen und der Reihenfolge, in der sie geladen werden, habe ich nichts geändert.

Ohne weitere Veränderungen kam es bei mir bei einem Stress-Test (u.a. iptables, Samba-Server und Tor-Server, jeweils auf der Box) zu diversen Reboots, die offenbar auf Speichermangel zurückzuführen waren. Ich konnte jedenfalls dabei zusehen, wie der Speicher immer voller wurde...

ip_conntrack_tcp_be_liberal ist ja seit Rev. 2016 standardmäßig auf 1 gesetzt. Ich habe zusätzlich in rc.custom folgende Einträge:

Seitdem hat es keine Reboots mehr gegeben. Ich vermute, dass das Timeout für Reboots wegen Speicherplatz-Mangels entscheidend ist und die conntrack-Tabelle auf diese Weise klein genug bleibt. Letztlich dürfte das Problem von dem jeweiligen Anwendungsszenario abhängen, sprich welche Anwendungen auf und hinter der Box wieviele Connections gleichzeitig öffnen und offen halten.

Just my 2 cents,
alpha1974

Moin,

ich bin in letzer Zeit auch mal wieder dazu gekommen mit ip_tables zu spielen. Die beiden Einstellungen oben beseitigen bei mir die Reboots auf einer fb7050. Ich habe den Timeout allerdings auf 3600 gestellt.

--
Schwigi