xt_owner-xt_socket plans

xt_owner-xt_socket plans

[Jan Engelhardt]

Hi,


I just remembered that xt_socket (from tproxy) does an (explicit) socket 
lookup. xt_owner on the other hand, takes the socket pointer from the 
skb -- which of course only works in the output path.

xt_owner is still in the 2.6.25 development queue, and because the two 
modules are similar, I thought that maybe xt_owner could be merged with 
xt_socket (doing a rename to xt_socket in the current net-2.6.25),
because they are quite close in their task.

That would also allow xt_owner to be used in the input path.

Opinions?

thanks,
Jan

Re: xt_owner-xt_socket plans

[Laszlo Attila Toth]

Jan Engelhardt írta:
> Hi,
> 
> 
> I just remembered that xt_socket (from tproxy) does an (explicit) socket 
> lookup. xt_owner on the other hand, takes the socket pointer from the 
> skb -- which of course only works in the output path.
> 
> xt_owner is still in the 2.6.25 development queue, and because the two 
> modules are similar, I thought that maybe xt_owner could be merged with 
> xt_socket (doing a rename to xt_socket in the current net-2.6.25),
> because they are quite close in their task.
> 
> That would also allow xt_owner to be used in the input path.
> 
> Opinions?
> 

Hello,

That sounds great.

Note that the socket match depends on tproxy core, also the tproxy would 
be partially merged into the net-2.25 tree. This is the 9th patch in
 
http://people.netfilter.org/hidden/tproxy/tproxy4-2.6.24-200710190050.tar.bz2

and it is marked as experimental although the owner match is not 
experimental.

-- 
Attila
-
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: xt_owner-xt_socket plans

[Jan Engelhardt]

On Jan 21 2008 10:11, Laszlo Attila Toth wrote:
>
> http://people.netfilter.org/hidden/tproxy/tproxy4-2.6.24-200710190050.tar.bz2
>
In the xt_socket code, I just noticed:

	struct udphdr *hp;
	hp = skb_header_pointer(skb, ip_hdrlen(skb), sizeof(_hdr), &_hdr);

Does that mean xt_socket only receives UDP? Also, the header should always be
available so that skb_header_pointer is not necessary.
Where am I being misled?

Re: xt_owner-xt_socket plans

[Laszlo Attila Toth]

Jan Engelhardt írta:
> On Jan 21 2008 10:11, Laszlo Attila Toth wrote:
>> http://people.netfilter.org/hidden/tproxy/tproxy4-2.6.24-200710190050.tar.bz2
>>
> In the xt_socket code, I just noticed:
> 
> 	struct udphdr *hp;
> 	hp = skb_header_pointer(skb, ip_hdrlen(skb), sizeof(_hdr), &_hdr);
> 
> Does that mean xt_socket only receives UDP? Also, the header should always be
> available so that skb_header_pointer is not necessary.
> Where am I being misled?
> 

No, both tcp and udp packets are receiving.

Usage of udphdr is beacuse the first two members of the struct 
{udp,tcp}hdr types are the same, they are the source and destionation 
ports, and they are used as parameters of nf_tproxy_get_sock_v4 function:
          __be16  source;
          __be16  dest;

Either tcphdr or udphdr can be used, and the latter one is the simplier 
type.


-- 
Attila
-
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: xt_owner-xt_socket plans

[KOVACS Krisztian]

Hi,

On h, jan 21, 2008 at 11:58:34 +0100, Jan Engelhardt wrote:
> 
> On Jan 21 2008 10:11, Laszlo Attila Toth wrote:
> >
> > http://people.netfilter.org/hidden/tproxy/tproxy4-2.6.24-200710190050.tar.bz2
> >
> In the xt_socket code, I just noticed:
> 
> 	struct udphdr *hp;
> 	hp = skb_header_pointer(skb, ip_hdrlen(skb), sizeof(_hdr), &_hdr);
> 
> Does that mean xt_socket only receives UDP? Also, the header should always be
> available so that skb_header_pointer is not necessary.
> Where am I being misled?

No, not just UDP but it uses only the port part of the header which has
the same layout as the TCP header. It's ugly, though. (But I'm afraid this
is not the only place where this appears.)

The skb_header_pointer() might be unnecessary, bit I'm not quite sure
about this. Where exactly do we make sure that we have at least the UDP
header available?

And as already mentioned, the this match depends heavily on the other
parts of the tproxy patchset. In fact we'd need to create a new table to
make it work for NAT-ted connections (the current tproxy patchset has a
problem with SNAT), so it wouldn't be possible to use it on
mangle/PREROUTING... (Do you happen to have any ideas for this new table
name? I wouldn't call it tproxy but something else which tells you its
place in the flowchart, like 'postnat' or something like that.)

-- 
KOVACS Krisztian

Re: xt_owner-xt_socket plans

[Jan Engelhardt]

On Jan 21 2008 13:20, KOVACS Krisztian wrote:
>
>No, not just UDP but it uses only the port part of the header which has
>the same layout as the TCP header. It's ugly, though. (But I'm afraid this
>is not the only place where this appears.)

Hm yeah I had that suspicion and it seems to be the case.
I added this in my floating patches..
        /*
         * All the protocols that are currently supported (see above if
         * statement) have source and destination port at the same position,
         * so we can use this udph shortcut. Why UDP? The struct is the
         * smallest.
         */
	... skb_header_pointer ...

>The skb_header_pointer() might be unnecessary,

You are inspecting the layer4 data, so header_poitner is alright.
hp->source did not tell me anything at first, but seeing that you
chose UDP, it must have been the source port (->source is a bad
wording for it, I would have expected ->sport like TCP does).

>And as already mentioned, the this match depends heavily on the other
>parts of the tproxy patchset. In fact we'd need to create a new table to
>make it work for NAT-ted connections (the current tproxy patchset has a
>problem with SNAT),

What problem? Maybe it's a bit shortsighted, but I guess if you just
use the conntrack origsrc/dst instead of iph->saddr, it should be a
no-brainer, no?

>so it wouldn't be possible to use it on
>mangle/PREROUTING... (Do you happen to have any ideas for this new table
>name? I wouldn't call it tproxy but something else which tells you its
>place in the flowchart, like 'postnat' or something like that.)

Re: xt_owner-xt_socket plans

[Jan Engelhardt]

On January 21 2008 10:11, Laszlo Attila Toth wrote:
>Jan Engelhardt wrote:
>> I just remembered that xt_socket (from tproxy) does an (explicit) socket
>> lookup. xt_owner on the other hand, takes the socket pointer from the skb --
>> which of course only works in the output path.
>> 
>> xt_owner is still in the 2.6.25 development queue, and because the two
>> modules are similar, I thought that maybe xt_owner could be merged with
>> xt_socket (doing a rename to xt_socket in the current net-2.6.25),
>> because they are quite close in their task.
>> 
>> That would also allow xt_owner to be used in the input path.
>> 
>> Opinions?
>
> Hello,
>
> That sounds great.
>
> Note that the socket match depends on tproxy core, also the tproxy would be
> partially merged into the net-2.25 tree. [...]

Here is what I had in mind, please have a look.
http://dev.computergmbh.de/gitweb.cgi?p=linux;h=dev-xtsocket;a=shortlog

Re: xt_owner-xt_socket plans

[Laszlo Attila Toth]

Jan Engelhardt írta:
> On January 21 2008 10:11, Laszlo Attila Toth wrote:
>> Jan Engelhardt wrote:
>>> I just remembered that xt_socket (from tproxy) does an (explicit) socket
>>> lookup. xt_owner on the other hand, takes the socket pointer from the skb --
>>> which of course only works in the output path.
>>>
>>> xt_owner is still in the 2.6.25 development queue, and because the two
>>> modules are similar, I thought that maybe xt_owner could be merged with
>>> xt_socket (doing a rename to xt_socket in the current net-2.6.25),
>>> because they are quite close in their task.
>>>
>>> That would also allow xt_owner to be used in the input path.
>>>
>>> Opinions?
>> Hello,
>>
>> That sounds great.
>>
>> Note that the socket match depends on tproxy core, also the tproxy would be
>> partially merged into the net-2.25 tree. [...]
> 
> Here is what I had in mind, please have a look.
> http://dev.computergmbh.de/gitweb.cgi?p=linux;h=dev-xtsocket;a=shortlog
> 


The following snippet of socket_mt_get() should be in socket_mt():

        if (sk != NULL)
                  nf_tproxy_put_sock(sk);

The socket buffer is first referenced by nf_tproxy_get_v4() then 
immediately released (put back) also it is not garanteed that the socket 
is valid. Furthermore I don't know whether the sk->sk_socket is valid 
through the whole function in a multiprocessor environment (the program, 
that opened it, may close the socket).


The tproxy lookup only works with tcp and udp, and afaik the original 
owner match also limited to these protocols, also it can be tested in 
socket_mt4_check()

I noticed that you forgot rename the match to "socket" in socket_mt_reg[].

Except these the patch is ok.

-- 
Attila
-
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: xt_owner-xt_socket plans

[KOVACS Krisztian]

Hi,

On h, jan 21, 2008 at 02:23:25 +0100, Jan Engelhardt wrote:
> On January 21 2008 10:11, Laszlo Attila Toth wrote:
> >Jan Engelhardt wrote:
> >> I just remembered that xt_socket (from tproxy) does an (explicit) socket
> >> lookup. xt_owner on the other hand, takes the socket pointer from the skb --
> >> which of course only works in the output path.
> >> 
> >> xt_owner is still in the 2.6.25 development queue, and because the two
> >> modules are similar, I thought that maybe xt_owner could be merged with
> >> xt_socket (doing a rename to xt_socket in the current net-2.6.25),
> >> because they are quite close in their task.
> >> 
> >> That would also allow xt_owner to be used in the input path.
> >> 
> >> Opinions?
> >
> > Hello,
> >
> > That sounds great.
> >
> > Note that the socket match depends on tproxy core, also the tproxy would be
> > partially merged into the net-2.25 tree. [...]
> 
> Here is what I had in mind, please have a look.
> http://dev.computergmbh.de/gitweb.cgi?p=linux;h=dev-xtsocket;a=shortlog

This won't work:

+       sk = nf_tproxy_get_v4(iph->protocol, iph->saddr, iph->daddr,
+                             hp->source, hp->dest, in, false);
+       if (sk != NULL)
+               nf_tproxy_put_sock(sk);
+       return sk;

socket_mt_get() returns a struct sock * without holding a reference for
that pointer.

-- 
KOVACS Krisztian

Re: xt_owner-xt_socket plans

[KOVACS Krisztian]

Hi,

On h, jan 21, 2008 at 02:16:58 +0100, Jan Engelhardt wrote:
> >And as already mentioned, the this match depends heavily on the other
> >parts of the tproxy patchset. In fact we'd need to create a new table to
> >make it work for NAT-ted connections (the current tproxy patchset has a
> >problem with SNAT),
> 
> What problem? Maybe it's a bit shortsighted, but I guess if you just
> use the conntrack origsrc/dst instead of iph->saddr, it should be a
> no-brainer, no?

For SNAT, this would be possible. It still wouldn't work for DNAT,
however... (Imagine you have a DNAT rule on nat/PREROUTING and try to do a
socket match _before_ traversing that chain.)

> >so it wouldn't be possible to use it on
> >mangle/PREROUTING... (Do you happen to have any ideas for this new table
> >name? I wouldn't call it tproxy but something else which tells you its
> >place in the flowchart, like 'postnat' or something like that.)

-- 
KOVACS Krisztian

Re: xt_owner-xt_socket plans

[Jan Engelhardt]

On Jan 21 2008 15:46, KOVACS Krisztian wrote:
>> 
>> What problem? Maybe it's a bit shortsighted, but I guess if you just
>> use the conntrack origsrc/dst instead of iph->saddr, it should be a
>> no-brainer, no?
>
>For SNAT, this would be possible. It still wouldn't work for DNAT,
>however... (Imagine you have a DNAT rule on nat/PREROUTING and try to do a
>socket match _before_ traversing that chain.)

While you are right, I do not see a use case for combining -m socket
with DNAT.

There are a few cases I can think of:

1. The user wants to do transparent proxying, i.e. rerouting the
   packet a localhost process. That is done with -m socket and -j
   MARK, and a reroute based on fwmark, without DNAT.

2. The user wants to forward the packet. In this case, using -m
   socket does not make much sense because the packet is not going to
   be delivered locally.

3. The packet is directly addressed to the host (e.g. 1.3.3.7) itself.
   The host has a secondary IPv4 address (1.3.3.8), and the user
   does, for whatever reason:

	-t nat -A PREROUTING -d 1.3.3.7 -p tcp --dport 80 \
	-j DNAT --to 1.3.3.8:81

   In this third case, I cannot see a reason why one would want to
   use -m socket in a table that comes before "nat".

You are free to englighten me with a (believable) scenario not listed
here that does depend on socket being in mangle, and uses DNAT :-)

Re: xt_owner-xt_socket plans

[Jan Engelhardt]

On Jan 21 2008 15:26, Laszlo Attila Toth wrote:
>> Here is what I had in mind, please have a look.
>> http://dev.computergmbh.de/gitweb.cgi?p=linux;h=dev-xtsocket;a=shortlog
>
> The following snippet of socket_mt_get() should be in socket_mt():
>
>       if (sk != NULL)
>                 nf_tproxy_put_sock(sk);
>
> The socket buffer is first referenced by nf_tproxy_get_v4() then
> immediately released (put back) also it is not garanteed that the
> socket is valid.

Ok.

> Furthermore I don't know whether the sk->sk_socket is valid through
> the whole function in a multiprocessor environment (the program,
> that opened it, may close the socket).

For the input path, nf_tproxy_get_v4 will up sk->sk_refcnt which 
should prevent sk->file from going away.
For the output path I suppose our caller holds sk->sk_refcnt.
Well if anyone knows better, let me know.

> The tproxy lookup only works with tcp and udp, and afaik the original owner
> match also limited to these protocols, also it can be tested in
> socket_mt4_check()
>
> I noticed that you forgot rename the match to "socket" in socket_mt_reg[].

That is intended - it is the old owner match revision 0
(ipt_owner/ip6t_owner).

This is how it would look then:
commit 807482809f619a167d3dd349553d621ee4cd3b48
Author: Jan Engelhardt <jengelh@computergmbh.de>
Date:   Mon Jan 21 14:08:27 2008 +0100

    [NETFILTER]: xt_socket: input path processing
    
    tproxy adds a function for socket lookup; xt_socket can use this to
    be usable in the PREROUTING and INPUT chains.
    (This code has not been compile tested, but serves as an example.)
    
    Signed-off-by: Jan Engelhardt <jengelh@computergmbh.de>

diff --git a/net/netfilter/xt_socket.c b/net/netfilter/xt_socket.c
index 07d681c..1deacb2 100644
--- a/net/netfilter/xt_socket.c
+++ b/net/netfilter/xt_socket.c
@@ -76,17 +76,46 @@ owner_mt6_v0(const struct sk_buff *skb, const struct net_device *in,
 	return true;
 }
 
+static struct sock *
+socket_mt_getsock(const struct sk_buff *skb, const struct net_device *in)
+{
+#ifdef CONFIG_NETFILTER_TPROXY
+	const struct iphdr *iph = ip_hdr(skb);
+	const struct udphdr *udph;
+	struct udphdr udphdr;
+
+	if (iph->protocol != IPPROTO_TCP && iph->protocol != IPPROTO_UDP &&
+	    iph->protocol != IPPROTO_UDPLITE)
+		return false;
+
+	/*
+	 * All the protocols that are currently supported (see above if
+	 * statement) have source and destination port at the same position,
+	 * so we can use this udph shortcut. Why UDP? The struct is the
+	 * smallest.
+	 */
+	udph = skb_header_pointer(skb, ip_hdrlen(skb), udphdr, sizeof(udphdr));
+	if (udph == NULL)
+		return NULL;
+
+	return nf_tproxy_get_v4(iph->protocol, iph->saddr, iph->daddr,
+	                        hp->source, hp->dest, in, false);
+#endif
+	return NULL;
+}
+
+static void socket_mt_putsock(struct sock *sk)
+{
+#ifdef CONFIG_NETFILTER_TPROXY
+	nf_tproxy_put_sock(sk);
+#endif
+}
+
 static bool
-socket_mt(const struct sk_buff *skb, const struct net_device *in,
-          const struct net_device *out, const struct xt_match *match,
-          const void *matchinfo, int offset, unsigned int protoff,
-          bool *hotdrop)
+socket_mt_match(const struct sock *sk, const struct xt_socket_mtinfo *info)
 {
-	const struct xt_socket_mtinfo *info = matchinfo;
 	const struct file *filp;
-	const struct sock *sk;
 
-	sk = skb->sk;
 	if (sk == NULL || sk->sk_socket == NULL)
 		return (info->match ^ info->invert) == 0;
 	else if (info->match & info->invert & XT_SOCKET_EXISTS)
@@ -117,6 +146,25 @@ socket_mt(const struct sk_buff *skb, const struct net_device *in,
 }
 
 static bool
+socket_mt(const struct sk_buff *skb, const struct net_device *in,
+          const struct net_device *out, const struct xt_match *match,
+          const void *matchinfo, int offset, unsigned int protoff,
+          bool *hotdrop)
+{
+	struct sock *tpsk = NULL;
+	const struct sock *sk;
+	bool ret;
+
+	sk = skb->sk;
+	if (sk == NULL && in != NULL && match->family == AF_INET)
+		sk = tpsk = socket_mt_getsock(skb, in);
+	ret = socket_mt_match(sk, matchinfo);
+	if (tpsk != NULL)
+		socket_mt_putsock(tpsk);
+	return ret;
+}
+
+static bool
 owner_mt_check_v0(const char *tablename, const void *ip,
                   const struct xt_match *match, void *matchinfo,
                   unsigned int hook_mask)
@@ -149,6 +197,22 @@ owner_mt6_check_v0(const char *tablename, const void *ip,
 	return true;
 }
 
+static bool
+socket_mt4_check(const char *tablename, const void *ip,
+                 const struct xt_match *match, void *matchinfo,
+                 unsigned int hook_mask)
+{
+#ifndef CONFIG_NETFILTER_TPROXY
+	if (hook_mask & (NF_INET_PRE_ROUTING | NF_INET_LOCAL_IN)) {
+		printk(KERN_WARNING KBUILD_MODNAME
+			       ": Use in PREROUTING and INPUT chains only "
+			       "possible with tproxy\n");
+		return false;
+	}
+#endif
+	return true;
+}
+
 static struct xt_match socket_mt_reg[] __read_mostly = {
 	{
 		.name       = "owner",
@@ -178,7 +242,10 @@ static struct xt_match socket_mt_reg[] __read_mostly = {
 		.family     = AF_INET,
 		.match      = socket_mt,
 		.matchsize  = sizeof(struct xt_socket_mtinfo),
-		.hooks      = (1 << NF_INET_LOCAL_OUT) |
+		.checkentry = socket_mt4_check,
+		.hooks      = (1 << NF_INET_PRE_ROUTING) |
+		              (1 << NF_INET_LOCAL_IN) |
+		              (1 << NF_INET_LOCAL_OUT) |
 		              (1 << NF_INET_POST_ROUTING),
 		.me         = THIS_MODULE,
 	},
@@ -196,6 +263,13 @@ static struct xt_match socket_mt_reg[] __read_mostly = {
 
 static int __init socket_mt_init(void)
 {
+#ifdef CONFIG_NETFILTER_TPROXY
+	printk(KERN_INFO KBUILD_MODNAME
+	       ": Input path socket lookup for IPv4 via tproxy.\n");
+#else
+	printk(KERN_INFO KBUILD_MODNAME
+	       ": No socket lookup for PREROUTING/INPUT available.\n");
+#endif
 	return xt_register_matches(socket_mt_reg, ARRAY_SIZE(socket_mt_reg));
 }
 

Re: xt_owner-xt_socket plans

[KOVACS Krisztian]

Hi,

On k, jan 22, 2008 at 12:22:56 +0100, Jan Engelhardt wrote:
> This is how it would look then:
> commit 807482809f619a167d3dd349553d621ee4cd3b48
> Author: Jan Engelhardt <jengelh@computergmbh.de>
> Date:   Mon Jan 21 14:08:27 2008 +0100
> 
>     [NETFILTER]: xt_socket: input path processing
>     
>     tproxy adds a function for socket lookup; xt_socket can use this to
>     be usable in the PREROUTING and INPUT chains.
>     (This code has not been compile tested, but serves as an example.)
>     
>     Signed-off-by: Jan Engelhardt <jengelh@computergmbh.de>
> 
> diff --git a/net/netfilter/xt_socket.c b/net/netfilter/xt_socket.c
> index 07d681c..1deacb2 100644
> --- a/net/netfilter/xt_socket.c
> +++ b/net/netfilter/xt_socket.c

#ifdef CONFIG_NETFILTER_TPROXY
#include <net/netfilter/nf_tproxy_core.h>
#include <net/netfilter/ipv4/nf_defrag_ipv4.h>
#endif

> @@ -76,17 +76,46 @@ owner_mt6_v0(const struct sk_buff *skb, const struct net_device *in,
>  	return true;
>  }
>  
> +static struct sock *
> +socket_mt_getsock(const struct sk_buff *skb, const struct net_device *in)
> +{
> +#ifdef CONFIG_NETFILTER_TPROXY
> +	const struct iphdr *iph = ip_hdr(skb);
> +	const struct udphdr *udph;
> +	struct udphdr udphdr;
> +
> +	if (iph->protocol != IPPROTO_TCP && iph->protocol != IPPROTO_UDP &&
> +	    iph->protocol != IPPROTO_UDPLITE)
> +		return false;

Should return NULL here.

> +
> +	/*
> +	 * All the protocols that are currently supported (see above if
> +	 * statement) have source and destination port at the same position,
> +	 * so we can use this udph shortcut. Why UDP? The struct is the
> +	 * smallest.
> +	 */
> +	udph = skb_header_pointer(skb, ip_hdrlen(skb), udphdr, sizeof(udphdr));
> +	if (udph == NULL)
> +		return NULL;
> +
> +	return nf_tproxy_get_v4(iph->protocol, iph->saddr, iph->daddr,
> +	                        hp->source, hp->dest, in, false);
> +#endif
> +	return NULL;
> +}
> +
> +static void socket_mt_putsock(struct sock *sk)

Inline?

> +{
> +#ifdef CONFIG_NETFILTER_TPROXY
> +	nf_tproxy_put_sock(sk);
> +#endif
> +}
> +
>  static bool
> -socket_mt(const struct sk_buff *skb, const struct net_device *in,
> -          const struct net_device *out, const struct xt_match *match,
> -          const void *matchinfo, int offset, unsigned int protoff,
> -          bool *hotdrop)
> +socket_mt_match(const struct sock *sk, const struct xt_socket_mtinfo *info)
>  {
> -	const struct xt_socket_mtinfo *info = matchinfo;
>  	const struct file *filp;
> -	const struct sock *sk;
>  
> -	sk = skb->sk;
>  	if (sk == NULL || sk->sk_socket == NULL)
>  		return (info->match ^ info->invert) == 0;
>  	else if (info->match & info->invert & XT_SOCKET_EXISTS)
> @@ -117,6 +146,25 @@ socket_mt(const struct sk_buff *skb, const struct net_device *in,
>  }
>  
>  static bool
> +socket_mt(const struct sk_buff *skb, const struct net_device *in,
> +          const struct net_device *out, const struct xt_match *match,
> +          const void *matchinfo, int offset, unsigned int protoff,
> +          bool *hotdrop)
> +{
> +	struct sock *tpsk = NULL;
> +	const struct sock *sk;
> +	bool ret;
> +
> +	sk = skb->sk;
> +	if (sk == NULL && in != NULL && match->family == AF_INET)
> +		sk = tpsk = socket_mt_getsock(skb, in);
> +	ret = socket_mt_match(sk, matchinfo);
> +	if (tpsk != NULL)
> +		socket_mt_putsock(tpsk);
> +	return ret;
> +}
> +
> +static bool
>  owner_mt_check_v0(const char *tablename, const void *ip,
>                    const struct xt_match *match, void *matchinfo,
>                    unsigned int hook_mask)
> @@ -149,6 +197,22 @@ owner_mt6_check_v0(const char *tablename, const void *ip,
>  	return true;
>  }
>  
> +static bool
> +socket_mt4_check(const char *tablename, const void *ip,
> +                 const struct xt_match *match, void *matchinfo,
> +                 unsigned int hook_mask)
> +{
> +#ifndef CONFIG_NETFILTER_TPROXY
> +	if (hook_mask & (NF_INET_PRE_ROUTING | NF_INET_LOCAL_IN)) {
> +		printk(KERN_WARNING KBUILD_MODNAME
> +			       ": Use in PREROUTING and INPUT chains only "
> +			       "possible with tproxy\n");
> +		return false;
> +	}
> +#endif
> +	return true;
> +}
> +
>  static struct xt_match socket_mt_reg[] __read_mostly = {
>  	{
>  		.name       = "owner",
> @@ -178,7 +242,10 @@ static struct xt_match socket_mt_reg[] __read_mostly = {
>  		.family     = AF_INET,
>  		.match      = socket_mt,
>  		.matchsize  = sizeof(struct xt_socket_mtinfo),
> -		.hooks      = (1 << NF_INET_LOCAL_OUT) |
> +		.checkentry = socket_mt4_check,
> +		.hooks      = (1 << NF_INET_PRE_ROUTING) |
> +		              (1 << NF_INET_LOCAL_IN) |
> +		              (1 << NF_INET_LOCAL_OUT) |
>  		              (1 << NF_INET_POST_ROUTING),
>  		.me         = THIS_MODULE,
>  	},
> @@ -196,6 +263,13 @@ static struct xt_match socket_mt_reg[] __read_mostly = {
>  
>  static int __init socket_mt_init(void)
>  {
> +#ifdef CONFIG_NETFILTER_TPROXY

        nf_defrag_ipv4_enable();

As socket can be used without conntrack but you _need_ the first few
bytes of the IP datagram to be able to do the socket lookup you have to
defrag. This is just another ugly kludge...

> +	printk(KERN_INFO KBUILD_MODNAME
> +	       ": Input path socket lookup for IPv4 via tproxy.\n");
> +#else
> +	printk(KERN_INFO KBUILD_MODNAME
> +	       ": No socket lookup for PREROUTING/INPUT available.\n");
> +#endif
>  	return xt_register_matches(socket_mt_reg, ARRAY_SIZE(socket_mt_reg));
>  }
>  
> 

-- 
KOVACS Krisztian