Two questions regardin this strange effect:
a) Is there a performance penalty for this huge number of connections in
contracker?
Yes. This has been discussed, with possible remedies (hashsize parameter
to ip_conntrack) mentioned, about a week ago. See the thread at
On Fri, Mar 29, 2002 at 09:07:54AM +0100, Martin Sperl wrote:
Hi!
Two questions regardin this strange effect:
a) Is there a performance penalty for this huge number of connections in
contracker?
not if you widen the hash table (see list archive on discussions about
that).
b) Why does it
On Fri, Mar 29, 2002 at 09:59:58AM +0100, Harald Welte wrote:
b) Why does it occure primarily with the Cisco Content Switch. The
numbers were much lower
before utilising the content switch! So the CSS is ACK flooding! Is
there a strange
interaction between the CSS and
On 28 Mar 2002, Frank wrote:
and this BUG appeared again today but with Kernel 2.4.19-pre4-ac2 and
Iptables CVS from 27.03.02. Applied all pending-patches cleanly but
newnat would so i forced it and compiled fine.
Still, there is no proof that this is a bug.
Mar 28 01:26:32 Frankux kernel:
On Thu, Mar 28, 2002 at 05:55:25PM +0100, Henrik Nordstrom wrote:
an entry is removed from this table when
1) the socket associated with the entry is destroyed (iff a socket is
associated with an entry)
Ok. So there is integration between the tproxy table and the host IP stack
Hi,
I have some spare time and I want to contribute to the netfilter
project. I saw on the TODO list that the 'log-level save/restore' needs
some investigation. That seems like a good opportunity to get familiar
with the netfilter code. Can someone give me a bit more info about what
is going
