hello,
- is there any update regardingTPROXY since
13/Feb/2002?
-is TPROXY intended to replace 'slessdir'
and 'IP_INTERCEPT'?
- will it be included in the kernel someday
(which version?)?
- does it provide the definitive patch
fornonlocal binding?
- are there examples on how to use it?
- Original Message -
From: Balazs Scheidler [EMAIL PROTECTED]
To: Jean-Michel Hemstedt [EMAIL PROTECTED]
Sent: Tuesday, 19 March, 2002 08:50
Subject: Re: TPROXY
On Wed, Mar 13, 2002 at 01:19:30PM +0100, Jean-Michel Hemstedt wrote:
hello,
I'm quite new to netfilter, and I would
- Original Message -
From: Patrick Schaaf [EMAIL PROTECTED]
To: Harald Welte [EMAIL PROTECTED]; Patrick Schaaf [EMAIL PROTECTED];
Martin Josefsson [EMAIL PROTECTED]; Aviv Bergman
[EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Tuesday, 19 March, 2002 12:16
Subject: Re: [Q] connection tracking
- Original Message -
From: Patrick Schaaf [EMAIL PROTECTED]
To: Jean-Michel Hemstedt [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Tuesday, 19 March, 2002 17:42
Subject: Re: [Q] connection tracking scaling
Hello Jean-Michel,
thanks for your input. I appreciate it.
On Tue, Mar 19
Nordstrom [EMAIL PROTECTED]
To: Jean-Michel Hemstedt [EMAIL PROTECTED]; Balazs
Scheidler [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Wednesday, 20 March, 2002 00:12
Subject: Re: TPROXY
[cannot claim I have been following the thread closely, mostly
guessing on what you are actually trying to acheive
On Wed, Mar 27, 2002 at 10:15:56AM +0100, Henrik Nordstrom wrote:
On Tuesdayen den 26 March 2002 16.33, Balazs Scheidler wrote:
Providing a client certificate to the server is not very common, if it is
required a tunnel can be opened to that _specific_ server, and nothing
else.
dear netdevels,
I'm doing some tcp benches on a netfilter enabled box and noticed
huge and surprising perf decrease when loading iptable_nat module.
- ip_conntrack is of course also loading the system, but with huge memory
and a large bucket size, the problem can be solved. The big issue with
I know this debate is not new... I just didn't expect such a (90% see
below) perf drop, and unavailablity risk. That's why I'm only reporting
it, hoping secretly that experienced hackers will consider it seriously.
;o)
Note: I don't want to play with words, but if you prefer, consider
I'm doing some tcp benches on a netfilter enabled box and noticed
huge and surprising perf decrease when loading iptable_nat module.
Rather similar to the results I posted about a week ago.
oops, sorry, it seems we performed our tests at the same time ;o)
- Another (old) question:
-0700, Don Cohen wrote:
From: Jean-Michel Hemstedt [EMAIL PROTECTED]
Since in my test, each connection is ephemeral (10ms) ...
One question here is whether the traffic generator is acting like
a real set of users or like an attacker. A real user would not keep
trying to make
loading a module, doesn't mean using it (lsmod reports it as 'unused'
in my tests). So, does it really 'sounds as expected', when you see
From where do you think that the module usage counter reports how many
packets/connections are handled (currently? totally?) by the module.
There is
hi,
just FYI, hash was already discussed in a previous thread:
'connection tracking scaling' [19 March 2002]
sorry if you were aware of it.
From: Jean-Michel Hemstedt [EMAIL PROTECTED]
98 static inline u_int32_t
99 hash_conntrack(const struct ip_conntrack_tuple *tuple)
100
(strange thing is that ethernet irq's reported by procinfo are
decreasing when the machine is overloaded. It suppose that it
means either that irq's are not even caught by the kernel/driver,
which is quite worrying, or either that irq's counters refer to
'processessed'
FYI,
I upgraded to iptables-1.2.6a (user kernel-2.4.18 patches)
and got the following (maybe known) problems:
- QUEUE target is NOK with kernel compiled with CONFIG_IP_NF_QUEUE=m
= the packets are queued, but ipq_create_handle() returns
can't create netlink socket
ERROR: Unable to
14 matches
Mail list logo
