Problem with Tproxy more kernel 2.6.22.9
Hi all, Somebody it would know to say because of this error in the compilation of kernel 2.6.22.9, in system x86_64 net/netfilter/xt_tproxy.c:48: warning: initialization from incompatible pointer type net/netfilter/xt_tproxy.c:56: warning: initialization from incompatible pointer type I applied patch tproxy-4.0.3-2.6.22, in this kernel, iptables iptables-1-3.8.diff, and compiled squid-2.6STABLE17, and in going up of squid it returns. "Missing needed capability support. Will continue without tproxy support" Parameter of compiled squid Squid Cache: Version 2.6.STABLE17-20080108 configure options: '--sysconfdir=/etc/squid' '--enable-storeio=aufs,coss ,diskd,ufs' '--enable-poll' '--enable-delay-pools' '--enable-linux-tproxy' '--enable-htcp' '--enable-carp' '--with-pthreads' '--enable-underscores' '--enable-external--enable-arp-acl' '--enable-follow-x-forwarded-for' Regards Welisson
Welisson wrote:
Hi all,
Somebody it would know to say because of this error in the compilation of kernel 2.6.22.9 <http://2.6.22.9/>, in system x86_64
net/netfilter/xt_tproxy.c:48: warning: initialization from incompatible pointer type net/netfilter/xt_tproxy.c:56: warning: initialization from incompatible pointer type
I applied patch tproxy-4.0.3-2.6.22, in this kernel, iptables iptables-1-3.8.diff, and compiled squid-2.6STABLE17, and in going up of squid it returns.
"Missing needed capability support. Will continue without tproxy support"
Parameter of compiled squid
Squid Cache: Version 2.6.STABLE17-20080108 configure options: '--sysconfdir=/etc/squid' '--enable-storeio=aufs,coss ,diskd,ufs' '--enable-poll' '--enable-delay-pools' '--enable-linux-tproxy' '--enable-htcp' '--enable-carp' '--with-pthreads' '--enable-underscores' '--enable-external--enable-arp-acl' '--enable-follow-x-forwarded-for'
If you haven't apply the squid patch, you will obviously won't be able to use tproxy4 with squid. Note that the previous squid patch submitted here in this forum has got some problems :- 1. If does not patch the 'autoconfigure' at all, so if you apply the squid patch on a 2.6.22 system, Squid (being wired to look for tproxy2 headers ) will still unable to enable linux-tproxy even if you specify the correct configure options, so ~lib/autoconf.h will still not define TPROXY as 1. 2. Even if you manually enable the linux-tproxy option by changing ~include/autoconf.h to define TPROXY 1, squid will still not compile because of lack of tproxy2 headers, the source code ~src/forward.c should be modified to remove dependency on tproxy2 headers ( ie remove include <linux/netfiler_ipv4/ip_tproxy.h> ). So even if you apply the squid patch, you will still have problems, does not matter if it is 32 bit or 64 bit. Ming-Ching
Sorry, but, i don't understand very well. The version of squid don't is patched to be use with tproxy-4, because the wrong at hour when compiled the kernel version 2.6.22.9. ===========ERROR Start============= net/netfilter/xt_tproxy.c:48: warning: initialization from incompatible pointer type net/netfilter/xt_tproxy.c:56: warning: initialization from incompatible pointer type ===========ERROR END=============== Att.. Welisson 2008/1/11, Ming-Ching Tiew <mingching.tiew@redtone.com>:
Welisson wrote:
Hi all,
Somebody it would know to say because of this error in the compilation of kernel 2.6.22.9 <http://2.6.22.9/>, in system x86_64
net/netfilter/xt_tproxy.c:48: warning: initialization from incompatible pointer type net/netfilter/xt_tproxy.c:56: warning: initialization from incompatible pointer type
I applied patch tproxy-4.0.3-2.6.22, in this kernel, iptables iptables-1-3.8.diff, and compiled squid-2.6STABLE17, and in going up of squid it returns.
"Missing needed capability support. Will continue without tproxy support"
Parameter of compiled squid
Squid Cache: Version 2.6.STABLE17-20080108 configure options: '--sysconfdir=/etc/squid' '--enable-storeio=aufs,coss ,diskd,ufs' '--enable-poll' '--enable-delay-pools' '--enable-linux-tproxy' '--enable-htcp' '--enable-carp' '--with-pthreads' '--enable-underscores' '--enable-external--enable-arp-acl' '--enable-follow-x-forwarded-for'
If you haven't apply the squid patch, you will obviously won't be able to use tproxy4 with squid.
Note that the previous squid patch submitted here in this forum has got some problems :-
1. If does not patch the 'autoconfigure' at all, so if you apply the squid patch on a 2.6.22 system, Squid (being wired to look for tproxy2 headers ) will still unable to enable linux-tproxy even if you specify the correct configure options, so ~lib/autoconf.h will still not define TPROXY as 1.
2. Even if you manually enable the linux-tproxy option by changing ~include/autoconf.h to define TPROXY 1, squid will still not compile because of lack of tproxy2 headers, the source code ~src/forward.c should be modified to remove dependency on tproxy2 headers ( ie remove include <linux/netfiler_ipv4/ip_tproxy.h> ).
So even if you apply the squid patch, you will still have problems, does not matter if it is 32 bit or 64 bit.
Ming-Ching
_______________________________________________ tproxy mailing list tproxy@lists.balabit.hu https://lists.balabit.hu/mailman/listinfo/tproxy
From: "Welisson" <welissontome@ig.com.br>
===========ERROR Start============= net/netfilter/xt_tproxy.c:48: warning: initialization from incompatible pointer type net/netfilter/xt_tproxy.c:56: warning: initialization from incompatible pointer type ===========ERROR END===============
You are picking up some unimportant. That's just a warning and it is not the cause of squid not support tproxy4. Ignore the warning. Ming-Ching
Ming-Ching Tiew írta:
From: "Welisson" <welissontome@ig.com.br>
===========ERROR Start============= net/netfilter/xt_tproxy.c:48: warning: initialization from incompatible pointer type net/netfilter/xt_tproxy.c:56: warning: initialization from incompatible pointer type ===========ERROR END===============
You are picking up some unimportant. That's just a warning and it is not the cause of squid not support tproxy4.
Ignore the warning.
Ming-Ching
That's right. This is because there is a minor change in the declaration of checkentry member of struct xt_match. TProxy doesn't use the changed parameters also this warning can be safely ignored. I correct this in the next release, which will also contain patch for iptables 1.4. -- Panther
On Jan 11 2008 10:44, Laszlo Attila Toth wrote:
Ming-Ching Tiew írta:
From: "Welisson" <welissontome@ig.com.br>
===========ERROR Start============= net/netfilter/xt_tproxy.c:48: warning: initialization from incompatible pointer type net/netfilter/xt_tproxy.c:56: warning: initialization from incompatible pointer type ===========ERROR END===============
You are picking up some unimportant. That's just a warning and it is not the cause of squid not support tproxy4.
Ignore the warning.
That's right. This is because there is a minor change in the declaration of checkentry member of struct xt_match. TProxy doesn't use the changed parameters also this warning can be safely ignored.
No it cannot be ignored. If you compile tproxy-4.0.3-2.6.22.tar.gz (which contains 2.6.23 kernel code, though!) with a kernel _prior_ to 2.6.23, you may corrupt the stack.
On Jan 11 2008 12:02, Jan Engelhardt wrote:
On Jan 11 2008 10:44, Laszlo Attila Toth wrote:
Ming-Ching Tiew írta:
From: "Welisson" <welissontome@ig.com.br>
===========ERROR Start============= net/netfilter/xt_tproxy.c:48: warning: initialization from incompatible pointer type net/netfilter/xt_tproxy.c:56: warning: initialization from incompatible pointer type ===========ERROR END===============
You are picking up some unimportant. That's just a warning and it is not the cause of squid not support tproxy4.
Ignore the warning.
That's right. This is because there is a minor change in the declaration of checkentry member of struct xt_match. TProxy doesn't use the changed parameters also this warning can be safely ignored.
No it cannot be ignored. If you compile tproxy-4.0.3-2.6.22.tar.gz (which contains 2.6.23 kernel code, though!) with a kernel _prior_ to 2.6.23, you may corrupt the stack.
...or may get an unaligned access on hardware which does not transparently handle unaligned accesses like x86 does.
On Jan 11 2008 12:03, Jan Engelhardt wrote:
On Jan 11 2008 12:02, Jan Engelhardt wrote:
On Jan 11 2008 10:44, Laszlo Attila Toth wrote:
Ming-Ching Tiew írta:
From: "Welisson" <welissontome@ig.com.br>
===========ERROR Start============= net/netfilter/xt_tproxy.c:48: warning: initialization from incompatible pointer type net/netfilter/xt_tproxy.c:56: warning: initialization from incompatible pointer type ===========ERROR END===============
You are picking up some unimportant. That's just a warning and it is not the cause of squid not support tproxy4.
Ignore the warning.
That's right. This is because there is a minor change in the declaration of checkentry member of struct xt_match. TProxy doesn't use the changed parameters also this warning can be safely ignored.
No it cannot be ignored. If you compile tproxy-4.0.3-2.6.22.tar.gz (which contains 2.6.23 kernel code, though!) with a kernel _prior_ to 2.6.23, you may corrupt the stack.
Slight correction again... tproxy-4.0.3-2.6.22 uses _2.6.22_ code, i.e. int *hotdrop. In kernel 2.6.23 however, hotdrop is bool, and so, you may get stack corruption because you write 4 rather than 1 byte; or the unaligned access, because the bool pointer may be something like 0x03, which is not always int-aligned.
...or may get an unaligned access on hardware which does not transparently handle unaligned accesses like x86 does.
that's right. For that I understood this warning can be ignored, and don't confuses in nothing. Then it would know to say when it will leave patch for kernel 2.6.23 and iptables 1.4. Att.. Welisson
Jan Engelhardt írta:
On Jan 11 2008 12:03, Jan Engelhardt wrote:
On Jan 11 2008 12:02, Jan Engelhardt wrote:
On Jan 11 2008 10:44, Laszlo Attila Toth wrote:
Ming-Ching Tiew írta:
From: "Welisson" <welissontome@ig.com.br>
===========ERROR Start============= net/netfilter/xt_tproxy.c:48: warning: initialization from incompatible pointer type net/netfilter/xt_tproxy.c:56: warning: initialization from incompatible pointer type ===========ERROR END=============== You are picking up some unimportant. That's just a warning and it is not the cause of squid not support tproxy4.
Ignore the warning. That's right. This is because there is a minor change in the declaration of checkentry member of struct xt_match. TProxy doesn't use the changed parameters also this warning can be safely ignored. No it cannot be ignored. If you compile tproxy-4.0.3-2.6.22.tar.gz (which contains 2.6.23 kernel code, though!) with a kernel _prior_ to 2.6.23, you may corrupt the stack.
Ok. I tested it on x86 where the stack corruption didn't occur.
Slight correction again... tproxy-4.0.3-2.6.22 uses _2.6.22_ code, i.e. int *hotdrop. In kernel 2.6.23 however, hotdrop is bool, and so, you may get stack corruption because you write 4 rather than 1 byte; or the unaligned access, because the bool pointer may be something like 0x03, which is not always int-aligned.
I noticed it, thank you. -- Panther
I don't Belive. I compiled the kernel version 2.6.19 with cttproxy, iptables 1-3.7 and squid2.6STABLE14, very well, it functioned perfectly, redirecting it I only pass through way iptables for squid and I did not insert no rule in the table of tproxy. It follows below my configuration =====IPTABLES ONLY echo 1 /proc/sys/net/ipv4/ip_forward echo 1 /proc/sys/net/ipv4/ip_nonlocal_bind modprobe ipt_TPROXY squid -DNsY & iptables -t nat -A PREROUTING -s 200.200.200.0/28 -p TCP --dport 80 -j REDIRECT --to-ports 3128 ======SQUID http_port 200.200.200.1:3128 transparent tproxy tcp_outgoing_address 200.200.200.1 But nothing with kernel version 2.6.22.9 + iptables-1.3.8. If somebody can help me. Regards Welisson
On Jan 11 2008 17:51, Laszlo Attila Toth wrote:
No it cannot be ignored. If you compile tproxy-4.0.3-2.6.22.tar.gz (which contains 2.6.23 kernel code, though!) with a kernel _prior_ to 2.6.23, you may corrupt the stack.
Ok. I tested it on x86 where the stack corruption didn't occur.
How did you measure that?
Laszlo Attila Toth wrote:
I correct this in the next release, which will also contain patch for iptables 1.4.
Because of the bridge problem mentioned in the list, I had to setup bridge redirect target for packets to arrive at the real interfaces ( vs br0 ). However, when doing so, if the real interface has no IP address, it will cause kernel ooops due to accessing null pointers. I made a small change here to avoid the kernel ooops :- @@ -394,7 +394,7 @@ if (lport == 0) lport = hp->dest; - if (laddr == 0) + if (laddr == 0 && indev->ifa_list ) laddr = indev->ifa_list->ifa_local; DEBUGP(KERN_DEBUG "IPT_TPROXY: performing redirect to %08x:%04x\n", laddr, lport); Not sure it will be relevent to your next release. If not, kindly ignore. Ming-Ching.
Ming-Ching Tiew írta:
Laszlo Attila Toth wrote:
I correct this in the next release, which will also contain patch for iptables 1.4.
Because of the bridge problem mentioned in the list, I had to setup bridge redirect target for packets to arrive at the real interfaces ( vs br0 ). However, when doing so, if the real interface has no IP address, it will cause kernel ooops due to accessing null pointers.
I made a small change here to avoid the kernel ooops :-
@@ -394,7 +394,7 @@ if (lport == 0) lport = hp->dest;
- if (laddr == 0) + if (laddr == 0 && indev->ifa_list ) laddr = indev->ifa_list->ifa_local;
DEBUGP(KERN_DEBUG "IPT_TPROXY: performing redirect to %08x:%04x\n", laddr, lport);
Not sure it will be relevent to your next release. If not, kindly ignore.
Ming-Ching.
Applied, thanks. The kernel oops is avoided, but the laddr has an invalid address. Current version is in git: http://git.balabit.hu/?p=panther/tproxy4.git;a=summary -- Panther
Laszlo Attila Toth wrote:
Applied, thanks. The kernel oops is avoided, but the laddr has an invalid address.
Current version is in git: http://git.balabit.hu/?p=panther/tproxy4.git;a=summary
While at it, I have two other patches for your consideration :- 1 ) Sometimes in a multipath routing environment, after spoofing the original source IP, yet the packets have to do through a SNAT path, so this patch allows this to happen. This patch was provided by Kovacs. Index: linux-2.6.22/include/linux/netfilter_ipv4.h =================================================================== --- linux-2.6.22.orig/include/linux/netfilter_ipv4.h 2007-12-05 11:40:16.000000000 +0100 +++ linux-2.6.22/include/linux/netfilter_ipv4.h 2007-12-05 11:40:48.000000000 +0100 @@ -58,8 +58,8 @@ NF_IP_PRI_SELINUX_FIRST = -225, NF_IP_PRI_CONNTRACK = -200, NF_IP_PRI_MANGLE = -150, - NF_IP_PRI_TPROXY = -125, NF_IP_PRI_NAT_DST = -100, + NF_IP_PRI_TPROXY = -75, NF_IP_PRI_FILTER = 0, NF_IP_PRI_NAT_SRC = 100, NF_IP_PRI_SELINUX_LAST = 225, 2 ) IP FREEBIND packets spoofed with foreign source address will not leave the system when there is a FWMARK in the mangle table OUTPUT chain. This patch is created by me based on the information given by Kovacs, code quality is highly questionable as I barely understood what's it is all about, but it seems to work. --- linux-2.6.22-org/net/ipv4/netfilter.c 2007-12-13 20:55:45.000000000 +0800 +++ linux-2.6.22-new/net/ipv4/netfilter.c 2007-12-13 20:55:03.000000000 +0800 @@ -24,7 +24,7 @@ /* some non-standard hacks like ipt_REJECT.c:send_reset() can cause * packets with foreign saddr to appear on the NF_IP_LOCAL_OUT hook. */ - if (addr_type == RTN_LOCAL) { +// if (addr_type == RTN_LOCAL) { fl.nl_u.ip4_u.daddr = iph->daddr; if (type == RTN_LOCAL) fl.nl_u.ip4_u.saddr = iph->saddr; @@ -37,10 +37,10 @@ /* Drop old route. */ dst_release((*pskb)->dst); (*pskb)->dst = &rt->u.dst; - } else { +// } else { /* non-local src, find valid iif to satisfy * rp-filter when calling ip_route_input. */ - fl.nl_u.ip4_u.daddr = iph->saddr; +/* fl.nl_u.ip4_u.daddr = iph->saddr; if (ip_route_output_key(&rt, &fl) != 0) return -1; @@ -53,7 +53,7 @@ dst_release(&rt->u.dst); dst_release(odst); } - +*/ if ((*pskb)->dst->error) return -1; Ming-Ching
Hi, On szo, jan 12, 2008 at 11:47:44 +0800, Ming-Ching Tiew wrote:
2 ) IP FREEBIND packets spoofed with foreign source address will not leave the system when there is a FWMARK in the mangle table OUTPUT chain. This patch is created by me based on the information given by Kovacs, code quality is highly questionable as I barely understood what's it is all about, but it seems to work.
--- linux-2.6.22-org/net/ipv4/netfilter.c 2007-12-13 20:55:45.000000000 +0800 +++ linux-2.6.22-new/net/ipv4/netfilter.c 2007-12-13 20:55:03.000000000 +0800 @@ -24,7 +24,7 @@ /* some non-standard hacks like ipt_REJECT.c:send_reset() can cause * packets with foreign saddr to appear on the NF_IP_LOCAL_OUT hook. */ - if (addr_type == RTN_LOCAL) { +// if (addr_type == RTN_LOCAL) { fl.nl_u.ip4_u.daddr = iph->daddr; if (type == RTN_LOCAL) fl.nl_u.ip4_u.saddr = iph->saddr; @@ -37,10 +37,10 @@ /* Drop old route. */ dst_release((*pskb)->dst); (*pskb)->dst = &rt->u.dst; - } else { +// } else { /* non-local src, find valid iif to satisfy * rp-filter when calling ip_route_input. */ - fl.nl_u.ip4_u.daddr = iph->saddr; +/* fl.nl_u.ip4_u.daddr = iph->saddr; if (ip_route_output_key(&rt, &fl) != 0) return -1;
@@ -53,7 +53,7 @@ dst_release(&rt->u.dst); dst_release(odst); } - +*/ if ((*pskb)->dst->error) return -1;
We should probably first ask on netfilter-devel@ why this whole route lookup thing is necessary... -- KOVACS Krisztian
participants (5)
-
Jan Engelhardt
-
KOVACS Krisztian
-
Laszlo Attila Toth
-
Ming-Ching Tiew
-
Welisson