From: "Jorge Bastos" <mysql.jorge@decimal.pt>
To: "Patrick McHardy" <kaber@trash.net>,
<netfilter-devel@lists.netfilter.org>
Subject: Re: PPTP Problem with 2.6.20-rc1 >=
Date: Wed, 24 Jan 2007 21:24:33 -0000 [thread overview]
Message-ID: <006c01c73ffe$0af96cb0$0a01a8c0@pcjorge> (raw)
In-Reply-To: 45B7BE4E.30405@trash.net
Patrick,
Perfect!
Tell me, these patch's will be present in kernel in wich version?
Jorge
----- Original Message -----
From: "Patrick McHardy" <kaber@trash.net>
To: "Jorge Bastos" <mysql.jorge@decimal.pt>
Cc: <netfilter-devel@lists.netfilter.org>
Sent: Wednesday, January 24, 2007 8:15 PM
Subject: Re: PPTP Problem with 2.6.20-rc1 >=
> Patrick McHardy wrote:
>> OK thanks. I'll try to reproduce it myself.
>
> Please try these patches, they should fix it.
>
--------------------------------------------------------------------------------
> [NETFILTER]: nf_nat: fix ICMP translation with statically linked conntrack
>
> When nf_nat/nf_conntrack_ipv4 are linked statically, nf_nat is initialized
> before nf_conntrack_ipv4, which makes the nf_ct_l3proto_find_get(AF_INET)
> call during nf_nat initialization return the generic l3proto instead of
> the AF_INET specific one. This breaks ICMP error translation since the
> generic protocol always initializes the IPs in the tuple to 0.
>
> Change the linking order and put nf_conntrack_ipv4 first.
>
> Signed-off-by: Patrick McHardy <kaber@trash.net>
>
> ---
> commit 15cbfcc41a1fb66f4950a6e30569a13610fa9cf6
> tree 9b5e3a371eeaa4e91671818098e28d2058f27ef9
> parent eef40519c526f6446a0bf8ecc666af30f2eb5bfa
> author Patrick McHardy <kaber@trash.net> Wed, 24 Jan 2007 21:02:56 +0100
> committer Patrick McHardy <kaber@trash.net> Wed, 24 Jan 2007 21:02:56
> +0100
>
> net/ipv4/netfilter/Makefile | 19 +++++++++----------
> 1 files changed, 9 insertions(+), 10 deletions(-)
>
> diff --git a/net/ipv4/netfilter/Makefile b/net/ipv4/netfilter/Makefile
> index 15e741a..ddd2a6e 100644
> --- a/net/ipv4/netfilter/Makefile
> +++ b/net/ipv4/netfilter/Makefile
> @@ -6,6 +6,13 @@ # objects for the standalone - connectio
> ip_conntrack-objs := ip_conntrack_standalone.o ip_conntrack_core.o
> ip_conntrack_proto_generic.o ip_conntrack_proto_tcp.o
> ip_conntrack_proto_udp.o ip_conntrack_proto_icmp.o
> ip_nat-objs := ip_nat_core.o ip_nat_helper.o ip_nat_proto_unknown.o
> ip_nat_proto_tcp.o ip_nat_proto_udp.o ip_nat_proto_icmp.o
> nf_nat-objs := nf_nat_core.o nf_nat_helper.o nf_nat_proto_unknown.o
> nf_nat_proto_tcp.o nf_nat_proto_udp.o nf_nat_proto_icmp.o
> +# objects for l3 independent conntrack
> +nf_conntrack_ipv4-objs := nf_conntrack_l3proto_ipv4.o
> nf_conntrack_proto_icmp.o
> +ifeq ($(CONFIG_NF_CONNTRACK_PROC_COMPAT),y)
> +ifeq ($(CONFIG_PROC_FS),y)
> +nf_conntrack_ipv4-objs += nf_conntrack_l3proto_ipv4_compat.o
> +endif
> +endif
> ifneq ($(CONFIG_NF_NAT),)
> iptable_nat-objs := nf_nat_rule.o nf_nat_standalone.o
> else
> @@ -20,6 +27,8 @@ ip_nat_h323-objs := ip_nat_helper_h323.o
>
> # connection tracking
> obj-$(CONFIG_IP_NF_CONNTRACK) += ip_conntrack.o
> +obj-$(CONFIG_NF_CONNTRACK_IPV4) += nf_conntrack_ipv4.o
> +
> obj-$(CONFIG_IP_NF_NAT) += ip_nat.o
> obj-$(CONFIG_NF_NAT) += nf_nat.o
>
> @@ -106,13 +115,3 @@ obj-$(CONFIG_IP_NF_ARPFILTER) += arptabl
>
> obj-$(CONFIG_IP_NF_QUEUE) += ip_queue.o
>
> -# objects for l3 independent conntrack
> -nf_conntrack_ipv4-objs := nf_conntrack_l3proto_ipv4.o
> nf_conntrack_proto_icmp.o
> -ifeq ($(CONFIG_NF_CONNTRACK_PROC_COMPAT),y)
> -ifeq ($(CONFIG_PROC_FS),y)
> -nf_conntrack_ipv4-objs += nf_conntrack_l3proto_ipv4_compat.o
> -endif
> -endif
> -
> -# l3 independent conntrack
> -obj-$(CONFIG_NF_CONNTRACK_IPV4) += nf_conntrack_ipv4.o
>
--------------------------------------------------------------------------------
> [NETFILTER]: nf_nat_pptp: fix expectation removal
>
> When removing the expectation for the opposite direction, the PPTP NAT
> helper initializes the tuple for lookup with the addresses of the
> opposite direction, which makes the lookup fail.
>
> Signed-off-by: Patrick McHardy <kaber@trash.net>
>
> ---
> commit a589a7963cc217fa3536e35ca457a942b6eb4505
> tree bdf230482bf0cacdce7cd1cad6d268a54c29de76
> parent 15cbfcc41a1fb66f4950a6e30569a13610fa9cf6
> author Patrick McHardy <kaber@trash.net> Wed, 24 Jan 2007 21:05:28 +0100
> committer Patrick McHardy <kaber@trash.net> Wed, 24 Jan 2007 21:05:28
> +0100
>
> net/ipv4/netfilter/nf_nat_pptp.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/net/ipv4/netfilter/nf_nat_pptp.c
> b/net/ipv4/netfilter/nf_nat_pptp.c
> index 0ae45b7..5df4fca 100644
> --- a/net/ipv4/netfilter/nf_nat_pptp.c
> +++ b/net/ipv4/netfilter/nf_nat_pptp.c
> @@ -72,9 +72,9 @@ static void pptp_nat_expected(struct nf_
> DEBUGP("we are PAC->PNS\n");
> /* build tuple for PNS->PAC */
> t.src.l3num = AF_INET;
> - t.src.u3.ip = master->tuplehash[exp->dir].tuple.src.u3.ip;
> + t.src.u3.ip = master->tuplehash[!exp->dir].tuple.src.u3.ip;
> t.src.u.gre.key = nat_pptp_info->pns_call_id;
> - t.dst.u3.ip = master->tuplehash[exp->dir].tuple.dst.u3.ip;
> + t.dst.u3.ip = master->tuplehash[!exp->dir].tuple.dst.u3.ip;
> t.dst.u.gre.key = nat_pptp_info->pac_call_id;
> t.dst.protonum = IPPROTO_GRE;
> }
>
--------------------------------------------------------------------------------
> [NETFILTER]: nf_conntrack_pptp: fix NAT setup of expected GRE connections
>
> When an expected connection arrives, the NAT helper should be called to
> set up NAT similar to the master connection. The PPTP conntrack helper
> incorrectly checks whether the _expected_ connection has NAT setup before
> calling the NAT helper (which is never the case), instead of checkeing
> whether the _master_ connection is NATed.
>
> Signed-off-by: Patrick McHardy <kaber@trash.net>
>
> ---
> commit cff06a5c4c8ff341f49f86100abec1c2d05e800f
> tree 800ed269cc0e811d54e144cb640887a232d73a3c
> parent a589a7963cc217fa3536e35ca457a942b6eb4505
> author Patrick McHardy <kaber@trash.net> Wed, 24 Jan 2007 21:08:09 +0100
> committer Patrick McHardy <kaber@trash.net> Wed, 24 Jan 2007 21:08:09
> +0100
>
> net/netfilter/nf_conntrack_pptp.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/net/netfilter/nf_conntrack_pptp.c
> b/net/netfilter/nf_conntrack_pptp.c
> index f0ff00e..c59df3b 100644
> --- a/net/netfilter/nf_conntrack_pptp.c
> +++ b/net/netfilter/nf_conntrack_pptp.c
> @@ -113,7 +113,7 @@ static void pptp_expectfn(struct nf_conn
>
> rcu_read_lock();
> nf_nat_pptp_expectfn = rcu_dereference(nf_nat_pptp_hook_expectfn);
> - if (nf_nat_pptp_expectfn && ct->status & IPS_NAT_MASK)
> + if (nf_nat_pptp_expectfn && ct->master->status & IPS_NAT_MASK)
> nf_nat_pptp_expectfn(ct, exp);
> else {
> struct nf_conntrack_tuple inv_t;
>
next prev parent reply other threads:[~2007-01-24 21:24 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-01-20 11:54 PPTP Problem with 2.6.20-rc1 >= Jorge Bastos
2007-01-20 12:18 ` Patrick McHardy
2007-01-20 14:19 ` Jorge Bastos
2007-01-20 14:55 ` Jorge Bastos
2007-01-20 15:45 ` Patrick McHardy
2007-01-20 15:48 ` Jorge Bastos
2007-01-20 15:52 ` Patrick McHardy
2007-01-20 16:13 ` Jorge Bastos
2007-01-24 20:15 ` Patrick McHardy
2007-01-24 21:24 ` Jorge Bastos [this message]
2007-01-25 0:14 ` Patrick McHardy
2007-01-25 0:45 ` Jorge Bastos
2007-01-25 16:48 ` Jorge Bastos
2007-01-26 9:24 ` Jorge Bastos
-- strict thread matches above, loose matches on Subject: below --
2007-01-20 19:30 Jorge Bastos
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='006c01c73ffe$0af96cb0$0a01a8c0@pcjorge' \
--to=mysql.jorge@decimal.pt \
--cc=kaber@trash.net \
--cc=netfilter-devel@lists.netfilter.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).