On Mon, Mar 18, 2002 at 01:32:52PM +0900, ÀÌÈ£Àç wrote:
>
> I'd like to develop the XDMCP extension module for NAT...
>
> So I'd read the /usr/src/linux/net/ipv4/netfilter/ip_nat_ftp(irc).c and
>ip_conntrack_ftp(irc).c sources...
>
> But I knew that I must edit the ip_conntrack.h file for supp
Hi Patrick!
I greatly appreciate all your questions, comments, explanations ..
please keep asking and giving me as much insight as you please.
I really want to do something good, accurate, useful to everyone
and as professional as possible.
>> - because it would jump to 'ip_packet_match( )',
>Ye
On Mon, Mar 18, 2002 at 04:18:34PM +0100, Jozsef Kadlecsik wrote:
> On Sun, 17 Mar 2002, Paul P Komkoff Jr wrote:
>
> > Replying to Harald Welte:
> > > netfilter CVS has broken newnat patch at the moment.
> > >
> > > Sorry, but I'm just sick of keeping all this stuff in sync all the time.
>
> I
On Mondayen den 18 March 2002 16.35, Harald Welte wrote:
> Just as a small note to all people maintaining conntrack/NAT helpers:
> Please port your helpers to the newnat code, I will have to temporarily
> remove them from CVS as soon as newnat apprears in the mainstream kernel.
> This applies to a
Hi all,
I'm working on a proxy type program, using REDIRECT to catch (tcp) traffic,
and I'm seeing severe network degradation above ~2000 connection.
(computer: 1Gb p3, 2Gb memory, kernel 2.4.18 + aa1 patch)
I've profiled the kernel and found that > 50% of the cpu time is in
__ip_conntrack_find
On Mon, Mar 18, 2002 at 05:18:28PM +0100, Henrik Nordstrom wrote:
> On Mondayen den 18 March 2002 16.35, Harald Welte wrote:
> > Just as a small note to all people maintaining conntrack/NAT helpers:
> > Please port your helpers to the newnat code, I will have to temporarily
> > remove them from CV
> I'm working on a proxy type program, using REDIRECT to catch (tcp) traffic,
> and I'm seeing severe network degradation above ~2000 connection.
>
> (computer: 1Gb p3, 2Gb memory, kernel 2.4.18 + aa1 patch)
Two questions first: how many packets/second is these 2000 connections?
And, do you have
One fix: the data was for 2000 sessions --> 4000 connections (sorry)
More info on the setup:
Client a (100Mbit) > switch ---> client b (100Mbit)
|
\/
proxy(1Gbit)
Anyway:
With 2000 connections I get ~90Mbits in + ~
On Mon, 18 Mar 2002, Aviv Bergman wrote:
> Hi all,
>
> I'm working on a proxy type program, using REDIRECT to catch (tcp) traffic,
> and I'm seeing severe network degradation above ~2000 connection.
>
> (computer: 1Gb p3, 2Gb memory, kernel 2.4.18 + aa1 patch)
>
> I've profiled the kernel and
I'll try to experiment with different values tommorow
Thanx
aviv
-Original Message-
From: Martin Josefsson [mailto:[EMAIL PROTECTED]]
Sent: Monday, March 18, 2002 8:21 PM
To: Aviv Bergman
Cc: '[EMAIL PROTECTED]'
Subject: Re: [Q] connection tracking scaling
On Mon, 18 Mar 2002, Aviv Be
On Sat, 16 Mar 2002, Takuya Satoh wrote:
> Hi,
> Does the old FTOS target zero the ECN bits?
Quick Answer = YES
Long Answer -> FTOS takes whatever HEX code you specify and overwrites
_all_ 8 bits of the TOS field. So if you only specify say 0xf0 then the
ECN are overwritten with 0's. make sense
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 lookups to a random hash bucket each, with guaranteed
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
> > > 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 lookups to a random hash bucket each, with guaranteed
> > "no match"? Assum
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
> grep conntrack /proc/slabinfo (about 4200 connections at the time)
> ip_conntrack4527 4532 352 412 412 1
>
> 8192 buckets, 65536 max
>
> I guess the hash function fails for my setup (note: this is a test setup,
> connection originating from a single ip to a single ip)
... and prob
On Tue, Mar 19, 2002 at 12:57:52AM +0100, Martin Josefsson wrote:
> 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.
>
thanks, applied.
> /Martin
--
Live long and prosper
- Harald Welte / [EMAIL PROTECTED]
On Mon, 18 Mar 2002, Marc Haber wrote:
[...]
> However, today, I was on the phone (having called out myself) and was
> able to finish the call normally. Immediately afterwards, somebody
> tried to call me. The phone rang, but I wasn't able to hear the
> called. Nor did he hear me. After consultin
18 matches
Mail list logo
