June 2007 - tproxy - lists.balabit.hu

Re: [tproxy] Compile error with cttproxy-2.6.20-2.0.6, 2.6.20 kernel
by Pranav Desai 30 Jun '07

30 Jun '07

On 6/30/07, Jan Engelhardt <jengelh(a)computergmbh.de> wrote: > > On Jun 29 2007 12:17, Pranav Desai wrote: > > > > =========== ERROR ============ > > CC [M] net/ipv4/netfilter/ip_nat_core.o > > net/ipv4/netfilter/ip_nat_core.c:49: warning: 'kmem_cache_t' is deprecated > > net/ipv4/netfilter/ip_nat_core.c: In function '__ip_nat_reserved_new_hash': > > net/ipv4/netfilter/ip_nat_core.c:322: error: 'hash' undeclared (first > > use in this function) > > net/ipv4/netfilter/ip_nat_core.c:322: error: (Each undeclared > > identifier is reported only once > > net/ipv4/netfilter/ip_nat_core.c:322: error: for each function it appears in.) > > make[3]: *** [net/ipv4/netfilter/ip_nat_core.o] Error 1 > > make[2]: *** [net/ipv4/netfilter] Error 2 > > make[1]: *** [net/ipv4] Error 2 > > make: *** [net] Error 2 > > Replace kmem_cache_t by "struct kmem_cache". > Thats just the warning. The error is with hash being not declared, its 'h' in the code, but the 3rd patch changes that back to 'hash' and does a bunch of other changes, of which I am not sure about. Thanks -- Pranav > > Jan > -- > -- ------------------------------ http://pd.dnsalias.org

1 0

Compile error with cttproxy-2.6.20-2.0.6, 2.6.20 kernel
by Pranav Desai 29 Jun '07

29 Jun '07

Hello, I am trying to compile the cttproxy-2.6.20-2.0.6 with the 2.6.20 kernel, and I get the compile error given below. This is the case only when I apply the following patches. 01-nat_reservations.patch 02-tproxy.patch If I apply the third patch it compiles fine. 03-nat_delete.patch But the README suggests that I probably dont need the third patch. Is the README outdated or am I doing something wrong. Is is ok to add the 03 patch ? I have enabled tproxy as a module and nat reservation is compiled in the kernel. Thank you for your time. -- Pranav =========== ERROR ============ CC [M] net/ipv4/netfilter/ip_nat_core.o net/ipv4/netfilter/ip_nat_core.c:49: warning: 'kmem_cache_t' is deprecated net/ipv4/netfilter/ip_nat_core.c: In function '__ip_nat_reserved_new_hash': net/ipv4/netfilter/ip_nat_core.c:322: error: 'hash' undeclared (first use in this function) net/ipv4/netfilter/ip_nat_core.c:322: error: (Each undeclared identifier is reported only once net/ipv4/netfilter/ip_nat_core.c:322: error: for each function it appears in.) make[3]: *** [net/ipv4/netfilter/ip_nat_core.o] Error 1 make[2]: *** [net/ipv4/netfilter] Error 2 make[1]: *** [net/ipv4] Error 2 make: *** [net] Error 2 -- ------------------------------ http://pd.dnsalias.org

1 0

sockref leak problem
by Daniel 29 Jun '07

29 Jun '07

hi, Recently I tested tproxy with Avanlanche (about 800M/s stress) and some result below: 1. deadlock when ip_conntrack_ftp loaded. Plz see my last post and explaination from Balazs Scheidler. 2. I tested again without nat_reservation(deadlock disappeared). After 10 hours' stress test, kernel kept giving out exactly the same messages repeatedly: IP_TPROXY: socket already assigned, reuse=1, 0a0ba8c0:4c86, sr->faddr=e80ba8c0:0000, flags=10000, sr->tv_hashed=1181425010:475244912 My questions: Is this sockref leaked? and, what is the situation when a sockref is leaked? Thanks! Daniel 2007-06-10

3 8

tproxy patching error
by Dharam Paul 21 Jun '07

21 Jun '07

I am running slackware11. (kernel : 2.4.33.3 I have downloaded the cttproxy-2.4.33-2.0.5.tar.gz I am trying to patch the above mentioned tproxy patch to the above mentioned kernel. I have followed the following steps: Extracted cttproxy patch to a folder. Then I passed the following commands: #cd /usr/src/linux #for i in <pathtocttproxy>/patch_tree/*.diff; do cat $i | patch -p1; done. The patching is done but it gave some errors with the message that rejects are saved to file net/ip4/netfilter/ip_conntrack_core.core. Being a Linux noob and enthuasist, I have the following questions, Have I passed the command correctly? Is tproxy patch installed, and can I proceed further? If not how to get rid of these errors? Secondly as suggested in the readme, I can not find the Directory /usr/src/iptables-1.3.5 Please help me solve the issue. Best Regards

1 0

Check if kernal has inbuildt Tproxy support
by Dharam Paul 20 Jun '07

20 Jun '07

OS: Fedora 7 Can I check if the linux kernel has tproxy patch built into it? If yes how? TIA. Regards

2 1

Re: tproxy Digest, Vol 24, Issue 4
by Lior Dotan 12 Jun '07

12 Jun '07

Hi, I'm having the same problem with sockref leak with tproxy 2.0.6 running on kernel 2.4.33, with nat reservation patch applied. > Date: Tue, 12 Jun 2007 11:21:17 +0800 > From: "Daniel" <tooldcas(a)163.com> > Subject: Re: Re: [tproxy] sockref leak problem > To: "tproxy" <tproxy(a)lists.balabit.hu> > Message-ID: <200706121121174100198(a)163.com> > Content-Type: text/plain; charset="gb2312" > > > >>On Sun, 2007-06-10 at 20:25 +0800, Daniel wrote: > >> hi, > >> > >> Recently I tested tproxy with Avanlanche (about 800M/s stress) and some result below: > >> > >> 1. deadlock when ip_conntrack_ftp loaded. Plz see my last post and explaination from Balazs Scheidler. > >> 2. I tested again without nat_reservation(deadlock disappeared). After 10 hours' stress test, kernel kept giving out exactly the same messages repeatedly: > >> > >> IP_TPROXY: socket already assigned, reuse=1, 0a0ba8c0:4c86, sr->faddr=e80ba8c0:0000, flags=10000, sr->tv_hashed=1181425010:475244912 > >> > >> My questions: > >> Is this sockref leaked? > >> and, what is the situation when a sockref is leaked? > > > >can you tell me your kernel/tproxy version? > > > >The error message above means that the application tries to an address > >that already is in the tproxy hash table (e.g. which was allocated > >before). This should never happen, as this would indicate that > >you have two sockets bound to the same local ip:port > > > >The details of the already registered entry is included in the log > >message. > > > >The conflicting local address is 192.168.11.10:34380 and you wanted to > >assign 192.168.11.232 with a random port (0 port). > > > >Your flags has ITP_ONCE set, and nothing else, and the entry in the > >table was registered at 1181425010.475 secs after the UNIX epoch. > > > >A minor note: > >* ITP_ONCE was removed from the latest versions of tproxy, you should > >not use that (I don't think removing that would help in your case > >however) > > > >Please give me the exact versions you are testing with. > > > > > > > >-- > >Bazsi > > > > > Sorry about my last encoded email. > > I use tproxy-2.0.1 and kernel 2.6.9 and a http proxy, and I cann't move forward to new > versions for some reason. > > > Today when I stop stress and check /proc/net/tproxy later, I found 3 entries always there: > cat /proc/net/tproxy > 00006 470ba8c0:0000 0a0ba8c0:0581 00000000:0000 00010000 00000 000001 1181498811:997708128 > 00006 700ba8c0:0000 0a0ba8c0:5a9e 00000000:0000 00010000 00000 000001 1181489066:124306088 > 00006 e80ba8c0:0000 0a0ba8c0:4c86 00000000:0000 00010000 00000 000001 1181425010:475244912 > > Maybe I missed some important fix? > > Thanks for your quick reply. > > ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡Daniel > ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡tooldcas(a)163.com > ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡2007-06-12

1 0

Deadlock in tproxy
by Daniel 07 Jun '07

07 Jun '07

I think there is deadlock in tproxy. Two CPUs will wait for each other, ip_conntrack_lock and ip_nat_lock will never be unlocked. To reproduce this deadlock, we need ftp traffic(or other traffic which yields expect) and iptable_tproxy loaded. Plz see call trace below: CPU0 call trace: run_timer_softirq <-- invoked by timer death_by_timeout <-- write_lock_bh(&ip_conntrack_lock) clean_from_lists remove_expectations unexpect_related __unexpect_related ip_conntrack_expect_put ip_conntrack_expect_destroyed <-- hooked by nat_reservation patch ####### #ifdef CONFIG_IP_NF_NAT_NRES ip_conntrack_expect_destroyed = &ip_nat_reserved_cleanup_expect; #endif ####### ip_nat_reserved_cleanup_expect ip_nat_reserved_unregister_all <-- write_lock_bh(&ip_nat_lock) ##failed## [waiting...] CPU1 call trace: ip_tproxy_fn ip_tproxy_setup_nat ip_tproxy_setup_nat_bidir <-- write_lock_bh(&ip_nat_lock) ip_nat_setup_info ip_conntrack_alter_reply <-- write_lock_bh(&ip_conntrack_lock) ##failed## [waiting...]

2 1