On Sun, 2002-07-07 at 15:17, Patrick Schaaf wrote:
There is now a cttest-0.3 at http://bei.bof.de/cttest-0.3.tar.gz.
Also see
http://bei.bof.de/ex2
http://bei.bof.de/ex2rt
http://bei.bof.de/ex2abcd
http://bei.bof.de/ex2crc
for four example runs contrasting
Hi,
I've also done some plotting.
about 400 student-machines behind router, it's summer now so there's not
as much traffic as the rest of the year, only ~28k entries.
hashsize is 16384 with default ip_conntrack_max of 131072.
http://gandalf.hjorten.nu/kna-gw/
I added 16384 as size in
On Wed, 2002-06-12 at 00:21, Henrik Nordstrom wrote:
On Tuesday 11 June 2002 09:59, Harald Welte wrote:
On Thu, Jun 06, 2002 at 02:24:04PM +0200, Martin Josefsson wrote:
This patch adds a check to ip_ct_refresh() so it doesn't update
the timer of a connection unless it's been HZ ticks
Forwarding your patch to netfilter-devel where it belongs.
-Forwarded Message-
From: zhongyu [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Bug fixed
Date: 10 Jun 2002 16:23:34 +0800
Fix iptable_nat's memory leak problem.
--- linux-orig/net/ipv4/netfilter/ip_nat_core.c Mon Jun 10
On Sat, 2002-06-08 at 09:37, Harald Welte wrote:
ah. now I understand what the exporting was all about :)
:)
sounds interesting and should give quite some speedup. Did you do any
benchmarking on that?
I need to get a slower test-router so I can benchmark properly :(
I need to get a
Hi,
Attached is a small optimization for __ip_conntrack_find().
The way I read the use of the LIST_FIND macro it seems that we are
calling hash_conntrack() for each iteration with the same inparameters.
My change calls it once before looping.
--
/Martin
Never argue with an idiot. They drag
Here's the patch that lead up to the first patch (the renaming of
death_by_timeout and exporting it).
This patch adds a check to ip_ct_refresh() so it doesn't update the
timer of a connection unless it's been HZ ticks since the last update.
both del_timer() and add_timer() disables interrupts
Hi,
I changed the timer-update code in ip_ct_refresh() and then I found out
that the pptp helper abuses it to kill a conntrack which won't work with
my changes, the solution: change the pptp helper to do it correctly.
This first patch renames death_by_timeout to ip_ct_death_by_timeout and
On Thu, 2002-06-06 at 19:21, Emmanuel Fleury wrote:
[snip]
I am just quoting their mail here:
[snip again]
For short:
- ACK packets are classified as NEW (without opening a connection),
- Therefore, allowing NEW packets allow all the ACK packets to go
through,
- And consequently, in
forgot to cc netfilter-devel :(
-Forwarded Message-
From: Martin Josefsson [EMAIL PROTECTED]
To: Felix Farkas [EMAIL PROTECTED]
Subject: Re: IPSec ALG
Date: 22 May 2002 15:55:10 +0200
On Wed, 2002-05-22 at 15:40, Felix Farkas wrote:
The problem is that the first data packet coming
/oldnat.orig/conntrack-tcp-nopickup.patch.help Tue Feb 19 23:13:13 2002
+++ netfilter/userspace/patch-o-matic/oldnat/conntrack-tcp-nopickup.patch.help Sun May 19 03:01:43 2002
@@ -1,17 +1,35 @@
Author: Harald Welte [EMAIL PROTECTED]
+Modified by: Martin Josefsson [EMAIL PROTECTED]
Status: Highly Experimental
On Thu, 2002-05-09 at 23:24, Martin Josefsson wrote:
Hi,
Here's a patch that implements UID logging for locally generated
packets.
sigh, one more try...
--
/Martin
Never argue with an idiot. They drag you down to their level, then beat
you with experience.
diff -urN netfilter/userspace
Hi,
Attached are two patches, the first one fixes the problem with ICMP
logging. And the second one adds PROTO=number for non tcp, udp or icmp
protocols, just like ipt_LOG does.
--
/Martin
Never argue with an idiot. They drag you down to their level, then beat
you with experience.
---
On Sat, 2002-04-27 at 21:43, Harald Welte wrote:
Thanks a lot, Martin.
I'll apply your patches to ulog CVS.
Good. thanks
However, ulogd is a seperate project, and I cannot give you credits on
the netfilter.org scoreboard for your patches.
Yes I know it's a separate project. The truth
Hi Harald,
This was mailed to the netfilter list and it really belongs in your
inbox :)
I think I've seen this too.
-Forwarded Message-
From: Subodh Srivastava [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Wrong ICMP types
Date: 21 Apr 2002 13:46:17 -0700
Hi All,
I am using
On Sun, 2002-04-21 at 00:21, Brad Chapman wrote:
Everyone,
In the current CVS repository, the 0-newnat13.patch appears to have
been very badly broken - it doesn't apply at all to a fresh, untouched 2.4.18
tarball. About three days ago, the patch was OK. Has something been corrupted
On Wed, 2002-04-17 at 21:16, Harald Welte wrote:
Have you tried without conntrack? I'm not so sure it really accounts
for most of the performance problems. Jamal Hadi Selmi and Robert Olsson
have made several performance analysis on linux routers. You can find
their test results in
On Sun, 2002-04-14 at 18:18, Andreas Jung wrote:
Nope,
I compiled iptables from the sources (with 2.4.18 kernel)
I still think it looks like the redhat packaged iptables.
You are sure your new iptables version isn't located in /usr/local/sbin
and the old redhat version is still located in
Forgot to reply to all :(
-Forwarded Message-
From: Martin Josefsson [EMAIL PROTECTED]
To: Jay Schulist [EMAIL PROTECTED]
Subject: Re: Connection track logging
Date: 11 Apr 2002 18:44:00 +0200
On Thu, 2002-04-11 at 16:40, Jay Schulist wrote:
On 10 Apr 2002, Martin Josefsson wrote
Forgot to reply to all once again :(
-Forwarded Message-
From: Martin Josefsson [EMAIL PROTECTED]
To: Jay Schulist [EMAIL PROTECTED]
Subject: Re: Connection track logging
Date: 11 Apr 2002 18:55:15 +0200
On Thu, 2002-04-11 at 16:49, Jay Schulist wrote:
On 10 Apr 2002, Martin Josefsson
On Thu, 2002-04-11 at 19:13, J. Schulist wrote:
On 11 Apr 2002, Martin Josefsson wrote:
http://gandalf.hjorten.nu/ctnetlink-20020411.diff
it includes some debugging stuff and really only contains two bugfixes
and one cleanup. But those two bugfixes makes a great deal of diffrence
On Sun, 24 Mar 2002, Moore Michael wrote:
Dear gianni:
IMO, there's a miss placed [int ,] in the ipt_string.c file of package
iptables_1.2.6a.
Compile error message as bellow:
ipt_string.c:80: macro `max' used with too many (3) args
ipt_string.c: In function `search_sublinear':
On Thu, 21 Mar 2002, Izauddin Mohd Isa wrote:
Hi guys,
I'm trying to patch 1.2.6a into a 2.4.16 kernel with the inclusion of
the String Matching filter, but I got this error when compiling the
kernel at the make modules stage. The error as follow :
ipt_string.c:80:72: macro max passed 3
On Tue, 19 Mar 2002, Patrick Schaaf wrote:
I agree that the hash function needs scrutiny. Do you (or somebody else
here) have a good collection of real world /proc/net/ip_conntrack excerpts,
maybe coming from the development of ctnetlink? I'll cook up a hash
occupation simulator for user
Hi Harald,
the SMP fixups for the string match changed the max() to a 2.4.9 style
max() with 3 args... here's a patch to fix it.
/Martin
Never argue with an idiot. They drag you down to their level, then beat you with
experience.
--- netfilter/userspace/patch-o-matic/extra/string.patch.orig
On Mon, 18 Mar 2002, Patrick Schaaf wrote:
Hello Martin,
thanks for your numbers.
with 16384 hashbuckets and a maximum of 131072 tracked connections it took
7.5 seconds to perform 1 million lookups in the hashtable (using
__ip_conntrack_find from userspace).
Was this 1 million
On Wed, 27 Feb 2002, Schramp, R. wrote:
Hello All,
First, thanks for the fast response, I am still a bit puzzled though.
I understand from this statement that the amount of data
needed is about
16Kbyte per connection, of which 350 bytes is non
swappeble. This seems like
an
27 matches
Mail list logo
