PPTP Problem with 2.6.20-rc1 >=

PPTP Problem with 2.6.20-rc1 >=

[Jorge Bastos]

As Patrick asked me to do, i'm reporting this to this list, below is the 
complete report i did to the users list, and the info patrick told me to 
add.

nf_contrack, and below theres nf_conntrack_expect, i did a grep to show only 
the lines that we need.
As soon you have a feedback tell me something to the list :P

Jorge


cisne:/proc/net# cat nf_conntrack|grep -i 192.168.1.3
ipv4     2 tcp      6 431984 ESTABLISHED src=192.168.1.3 dst=84.91.32.190 
sport=2521 dport=1723 packets=6 bytes=608 src=84.91.32.190 dst=195.23.114.78 
sport=1723 dport=2521 packets=8 bytes=580 [ASSURED] mark=0 secmark=0 use=3
ipv4     2 gre      47 598 timeout=600, stream_timeout=18000 src=192.168.1.3 
dst=84.91.32.190 srckey=0x4000 dstkey=0x280 packets=5 bytes=285 [UNREPLIED] 
src=84.91.32.190 dst=195.23.114.78 srckey=0x280 dstkey=0x4000 packets=0 
bytes=0 mark=0 secmark=0 use=1


nf_conntrack_expect:

cisne:/proc/net# cat nf_conntrack_expect|grep -i 192.168.1.3
288 l3proto = 2 proto=47 src=192.168.1.3 dst=84.91.32.190 srckey=0x8000 
dstkey=0x300
253 l3proto = 2 proto=47 src=192.168.1.3 dst=84.91.32.190 srckey=0x4000 
dstkey=0x280


Pablo Neira Ayuso wrote:
> JFYI: Someone is reporting a problem with the pptp thing in
> netfilter-users, unfortunately I'm not familiar with those bits.

Thanks Pablo. Jorge, can you please resend your report to
netfilter-devel and include output of /proc/net/nf_conntrack (the
GRE and PPtP-sessions) and /proc/net/nf_conntrack_expect?
Thanks.

>
>
>
> ------------------------------------------------------------------------
>
> Subject:
> PPTP Problem with 2.6.20-rc1 >=
> From:
> "Jorge Bastos" <mysql.jorge@decimal.pt>
> Date:
> Tue, 16 Jan 2007 18:37:32 -0000
> To:
> <netfilter@lists.netfilter.org>
>
> To:
> <netfilter@lists.netfilter.org>
>
> Hi,
> I just updated kernel to 2.6.20-rc5, and i can't make pptp connections
> anymore, is just stoped in the AUTH step, hanging up witout sucess.
>
> My cenario is:
>
> My private network => linux router (this machine) => ISP
>
> I can see that diferent modules are used now, before i used:
> ---
> ip_nat_pptp
> ip_conntrack_pptp
> ---
>
> Now there's new modules with new names, like:
> nf_nat_pptp
> nf_conntrack_pptp
>
> Are they the same with diferent names?
> Thanks,
> Jorge
>
> Below there the modules i have loaded:
>
> ---
> ipt_REJECT              3584  2
> xt_tcpudp               3200  38
> nf_nat_pptp             3712  0
> nf_conntrack_pptp       6656  1 nf_nat_pptp
> nf_conntrack_proto_gre     4992  1 nf_conntrack_pptp
> nf_nat_proto_gre        2820  1 nf_nat_pptp
> nf_nat_ftp              3328  0
> nf_conntrack_ftp        8320  1 nf_nat_ftp
> nf_nat_irc              2688  0
> nf_conntrack_irc        6168  1 nf_nat_irc
> ipt_MASQUERADE          3456  1
> iptable_nat             7300  1
> nf_nat                 15404  6
> nf_nat_pptp,nf_nat_proto_gre,nf_nat_ftp,nf_nat_irc,ipt_MASQUERADE,iptable_nat
>
> nf_conntrack_ipv4      15372  2 iptable_nat
> nf_conntrack           54488  11
> nf_nat_pptp,nf_conntrack_pptp,nf_conntrack_proto_gre,nf_nat_ftp,nf_conntrack_ftp,nf_nat_irc,nf_conntrack_irc,ipt_MASQUERADE,iptable_nat,nf_nat,nf_conntrack_ipv4
>
> nfnetlink               5656  2 nf_conntrack_ipv4,nf_conntrack
> iptable_filter          2688  1
> ip_tables              10952  2 iptable_nat,iptable_filter
> x_tables               12548  5
> ipt_REJECT,xt_tcpudp,ipt_MASQUERADE,iptable_nat,ip_tables
>
>
> And dmesg show's me:
>
> ip_tables: (C) 2000-2006 Netfilter Core Team
> Netfilter messages via NETLINK v0.30.
> nf_conntrack version 0.5.0 (1024 buckets, 8192 max)
>
>
> ---
>

Re: PPTP Problem with 2.6.20-rc1 >=

[Patrick McHardy]

[-- Attachment #1: Type: text/plain, Size: 1437 bytes --]

Jorge Bastos wrote:
> As Patrick asked me to do, i'm reporting this to this list, below is the
> complete report i did to the users list, and the info patrick told me to
> add.
> 
> nf_contrack, and below theres nf_conntrack_expect, i did a grep to show
> only the lines that we need.
> As soon you have a feedback tell me something to the list :P
> 
> Jorge
> 
> 
> cisne:/proc/net# cat nf_conntrack|grep -i 192.168.1.3
> ipv4     2 tcp      6 431984 ESTABLISHED src=192.168.1.3
> dst=84.91.32.190 sport=2521 dport=1723 packets=6 bytes=608
> src=84.91.32.190 dst=195.23.114.78 sport=1723 dport=2521 packets=8
> bytes=580 [ASSURED] mark=0 secmark=0 use=3
> ipv4     2 gre      47 598 timeout=600, stream_timeout=18000
> src=192.168.1.3 dst=84.91.32.190 srckey=0x4000 dstkey=0x280 packets=5
> bytes=285 [UNREPLIED] src=84.91.32.190 dst=195.23.114.78 srckey=0x280
> dstkey=0x4000 packets=0 bytes=0 mark=0 secmark=0 use=1
> 
> 
> nf_conntrack_expect:
> 
> cisne:/proc/net# cat nf_conntrack_expect|grep -i 192.168.1.3
> 288 l3proto = 2 proto=47 src=192.168.1.3 dst=84.91.32.190 srckey=0x8000
> dstkey=0x300
> 253 l3proto = 2 proto=47 src=192.168.1.3 dst=84.91.32.190 srckey=0x4000
> dstkey=0x280

It seems like the connection was not properly recognized as expected,
I guess because parts of the tuple are uninitialized, but compared to
find the correct gre key.

This is not the proper fix, but does this patch make the problem go
away?




[-- Attachment #2: x --]
[-- Type: text/plain, Size: 703 bytes --]

diff --git a/net/netfilter/nf_conntrack_proto_gre.c b/net/netfilter/nf_conntrack_proto_gre.c
index ac193ce..9b0c32d 100644
--- a/net/netfilter/nf_conntrack_proto_gre.c
+++ b/net/netfilter/nf_conntrack_proto_gre.c
@@ -66,8 +66,8 @@ static inline int gre_key_cmpfn(const st
 				const struct nf_conntrack_tuple *t)
 {
 	return km->tuple.src.l3num == t->src.l3num &&
-	       !memcmp(&km->tuple.src.u3, &t->src.u3, sizeof(t->src.u3)) &&
-	       !memcmp(&km->tuple.dst.u3, &t->dst.u3, sizeof(t->dst.u3)) &&
+	       km->tuple.src.u3.ip == t->src.u3.ip &&
+	       km->tuple.dst.u3.ip == t->dst.u3.ip &&
 	       km->tuple.dst.protonum == t->dst.protonum &&
 	       km->tuple.dst.u.all == t->dst.u.all;
 }

Re: PPTP Problem with 2.6.20-rc1 >=

[Jorge Bastos]

Let me try... i'll give you feedback in a moment


----- Original Message ----- 
From: "Patrick McHardy" <kaber@trash.net>
To: "Jorge Bastos" <mysql.jorge@decimal.pt>
Cc: <netfilter-devel@lists.netfilter.org>
Sent: Saturday, January 20, 2007 12:18 PM
Subject: Re: PPTP Problem with 2.6.20-rc1 >=


> Jorge Bastos wrote:
>> As Patrick asked me to do, i'm reporting this to this list, below is the
>> complete report i did to the users list, and the info patrick told me to
>> add.
>>
>> nf_contrack, and below theres nf_conntrack_expect, i did a grep to show
>> only the lines that we need.
>> As soon you have a feedback tell me something to the list :P
>>
>> Jorge
>>
>>
>> cisne:/proc/net# cat nf_conntrack|grep -i 192.168.1.3
>> ipv4     2 tcp      6 431984 ESTABLISHED src=192.168.1.3
>> dst=84.91.32.190 sport=2521 dport=1723 packets=6 bytes=608
>> src=84.91.32.190 dst=195.23.114.78 sport=1723 dport=2521 packets=8
>> bytes=580 [ASSURED] mark=0 secmark=0 use=3
>> ipv4     2 gre      47 598 timeout=600, stream_timeout=18000
>> src=192.168.1.3 dst=84.91.32.190 srckey=0x4000 dstkey=0x280 packets=5
>> bytes=285 [UNREPLIED] src=84.91.32.190 dst=195.23.114.78 srckey=0x280
>> dstkey=0x4000 packets=0 bytes=0 mark=0 secmark=0 use=1
>>
>>
>> nf_conntrack_expect:
>>
>> cisne:/proc/net# cat nf_conntrack_expect|grep -i 192.168.1.3
>> 288 l3proto = 2 proto=47 src=192.168.1.3 dst=84.91.32.190 srckey=0x8000
>> dstkey=0x300
>> 253 l3proto = 2 proto=47 src=192.168.1.3 dst=84.91.32.190 srckey=0x4000
>> dstkey=0x280
>
> It seems like the connection was not properly recognized as expected,
> I guess because parts of the tuple are uninitialized, but compared to
> find the correct gre key.
>
> This is not the proper fix, but does this patch make the problem go
> away?
>
>
>
>


--------------------------------------------------------------------------------


> diff --git a/net/netfilter/nf_conntrack_proto_gre.c 
> b/net/netfilter/nf_conntrack_proto_gre.c
> index ac193ce..9b0c32d 100644
> --- a/net/netfilter/nf_conntrack_proto_gre.c
> +++ b/net/netfilter/nf_conntrack_proto_gre.c
> @@ -66,8 +66,8 @@ static inline int gre_key_cmpfn(const st
>  const struct nf_conntrack_tuple *t)
> {
>  return km->tuple.src.l3num == t->src.l3num &&
> -        !memcmp(&km->tuple.src.u3, &t->src.u3, sizeof(t->src.u3)) &&
> -        !memcmp(&km->tuple.dst.u3, &t->dst.u3, sizeof(t->dst.u3)) &&
> +        km->tuple.src.u3.ip == t->src.u3.ip &&
> +        km->tuple.dst.u3.ip == t->dst.u3.ip &&
>         km->tuple.dst.protonum == t->dst.protonum &&
>         km->tuple.dst.u.all == t->dst.u.all;
> }
> 

Re: PPTP Problem with 2.6.20-rc1 >=

[Jorge Bastos]

Ok, i've applied the patch, and recompiled the kernel module but, still 
nothing:
The same info you asked me before below:


nf_conntrack_expect:

296 l3proto = 2 proto=47 src=84.91.32.190 dst=195.23.114.78 srckey=0x480 
dstkey=0xd49
296 l3proto = 2 proto=47 src=192.168.1.3 dst=84.91.32.190 srckey=0x4000 
dstkey=0x480
228 l3proto = 2 proto=47 src=84.91.32.190 dst=195.23.114.78 srckey=0x400 
dstkey=0xd39
228 l3proto = 2 proto=47 src=192.168.1.3 dst=84.91.32.190 srckey=0x0 
dstkey=0x400

nf_conntrack:

ipv4     2 gre      47 582 timeout=600, stream_timeout=18000 src=192.168.1.3 
dst=84.91.32.190 srckey=0x8000 dstkey=0x500 packets=9 bytes=513 [UNREPLIED] 
src=84.91.32.190 dst=195.23.114.78 srckey=0x500 dstkey=0x8000 packets=0 
bytes=0 mark=0 secmark=0 use=1
ipv4     2 tcp      6 103 TIME_WAIT src=192.168.1.3 dst=84.91.32.190 
sport=3404 dport=1723 packets=7 bytes=648 src=84.91.32.190 dst=195.23.114.78 
sport=1723 dport=3404 packets=10 bytes=660 [ASSURED] mark=0 secmark=0 use=3
ipv4     2 tcp      6 13 TIME_WAIT src=192.168.1.3 dst=84.91.32.190 
sport=3401 dport=1723 packets=7 bytes=648 src=84.91.32.190 dst=195.23.114.78 
sport=1723 dport=3401 packets=10 bytes=660 [ASSURED] mark=0 secmark=0 use=3
ipv4     2 gre      47 492 timeout=600, stream_timeout=18000 src=192.168.1.3 
dst=84.91.32.190 srckey=0x4000 dstkey=0x480 packets=9 bytes=513 [UNREPLIED] 
src=84.91.32.190 dst=195.23.114.78 srckey=0x480 dstkey=0x4000 packets=0 
bytes=0 mark=0 secmark=0 use=1
ipv4     2 gre      47 597 timeout=600, stream_timeout=18000 src=192.168.1.3 
dst=84.91.32.190 srckey=0xc000 dstkey=0x580 packets=3 bytes=171 [UNREPLIED] 
src=84.91.32.190 dst=195.23.114.78 srckey=0x580 dstkey=0xc000 packets=0 
bytes=0 mark=0 secmark=0 use=1
ipv4     2 tcp      6 431993 ESTABLISHED src=192.168.1.3 dst=84.91.32.190 
sport=3405 dport=1723 packets=6 bytes=608 src=84.91.32.190 dst=195.23.114.78 
sport=1723 dport=3405 packets=8 bytes=580 [ASSURED] mark=0 secmark=0 use=3
ipv4     2 gre      47 423 timeout=600, stream_timeout=18000 src=192.168.1.3 
dst=84.91.32.190 srckey=0x0 dstkey=0x400 packets=9 bytes=513 [UNREPLIED] 
src=84.91.32.190 dst=195.23.114.78 srckey=0x400 dstkey=0x0 packets=0 bytes=0 
mark=0 secmark=0 use=1




----- Original Message ----- 
From: "Jorge Bastos" <mysql.jorge@decimal.pt>
To: "Patrick McHardy" <kaber@trash.net>; 
<netfilter-devel@lists.netfilter.org>
Sent: Saturday, January 20, 2007 2:19 PM
Subject: Re: PPTP Problem with 2.6.20-rc1 >=


> Let me try... i'll give you feedback in a moment
>
>
> ----- Original Message ----- 
> From: "Patrick McHardy" <kaber@trash.net>
> To: "Jorge Bastos" <mysql.jorge@decimal.pt>
> Cc: <netfilter-devel@lists.netfilter.org>
> Sent: Saturday, January 20, 2007 12:18 PM
> Subject: Re: PPTP Problem with 2.6.20-rc1 >=
>
>
>> Jorge Bastos wrote:
>>> As Patrick asked me to do, i'm reporting this to this list, below is the
>>> complete report i did to the users list, and the info patrick told me to
>>> add.
>>>
>>> nf_contrack, and below theres nf_conntrack_expect, i did a grep to show
>>> only the lines that we need.
>>> As soon you have a feedback tell me something to the list :P
>>>
>>> Jorge
>>>
>>>
>>> cisne:/proc/net# cat nf_conntrack|grep -i 192.168.1.3
>>> ipv4     2 tcp      6 431984 ESTABLISHED src=192.168.1.3
>>> dst=84.91.32.190 sport=2521 dport=1723 packets=6 bytes=608
>>> src=84.91.32.190 dst=195.23.114.78 sport=1723 dport=2521 packets=8
>>> bytes=580 [ASSURED] mark=0 secmark=0 use=3
>>> ipv4     2 gre      47 598 timeout=600, stream_timeout=18000
>>> src=192.168.1.3 dst=84.91.32.190 srckey=0x4000 dstkey=0x280 packets=5
>>> bytes=285 [UNREPLIED] src=84.91.32.190 dst=195.23.114.78 srckey=0x280
>>> dstkey=0x4000 packets=0 bytes=0 mark=0 secmark=0 use=1
>>>
>>>
>>> nf_conntrack_expect:
>>>
>>> cisne:/proc/net# cat nf_conntrack_expect|grep -i 192.168.1.3
>>> 288 l3proto = 2 proto=47 src=192.168.1.3 dst=84.91.32.190 srckey=0x8000
>>> dstkey=0x300
>>> 253 l3proto = 2 proto=47 src=192.168.1.3 dst=84.91.32.190 srckey=0x4000
>>> dstkey=0x280
>>
>> It seems like the connection was not properly recognized as expected,
>> I guess because parts of the tuple are uninitialized, but compared to
>> find the correct gre key.
>>
>> This is not the proper fix, but does this patch make the problem go
>> away?
>>
>>
>>
>>
>
>
> --------------------------------------------------------------------------------
>
>
>> diff --git a/net/netfilter/nf_conntrack_proto_gre.c 
>> b/net/netfilter/nf_conntrack_proto_gre.c
>> index ac193ce..9b0c32d 100644
>> --- a/net/netfilter/nf_conntrack_proto_gre.c
>> +++ b/net/netfilter/nf_conntrack_proto_gre.c
>> @@ -66,8 +66,8 @@ static inline int gre_key_cmpfn(const st
>>  const struct nf_conntrack_tuple *t)
>> {
>>  return km->tuple.src.l3num == t->src.l3num &&
>> -        !memcmp(&km->tuple.src.u3, &t->src.u3, sizeof(t->src.u3)) &&
>> -        !memcmp(&km->tuple.dst.u3, &t->dst.u3, sizeof(t->dst.u3)) &&
>> +        km->tuple.src.u3.ip == t->src.u3.ip &&
>> +        km->tuple.dst.u3.ip == t->dst.u3.ip &&
>>         km->tuple.dst.protonum == t->dst.protonum &&
>>         km->tuple.dst.u.all == t->dst.u.all;
>> }
>>
>
>
> 

Re: PPTP Problem with 2.6.20-rc1 >=

[Patrick McHardy]

Jorge Bastos wrote:
> Ok, i've applied the patch, and recompiled the kernel module but, still
> nothing:

Thanks. I trust you properly installed the modules and reloaded the PPTP
helper and GRE conntrack modules?

Re: PPTP Problem with 2.6.20-rc1 >=

[Jorge Bastos]

yap, my steps:

recompiled the kernel module, made a backup of the old module, copied the 
module to the /lib/modules............ to it's place, and restarted the 
machine (just to make sure it get really reloaded!!)

below in the folow order, original, and module with the patch:

cisne:/usr/src# l /nf_conntrack_proto_gre.ko
-rw-r--r-- 1 root root 7470 Jan 20 14:41 /nf_conntrack_proto_gre.ko
cisne:/usr/src# l 
/lib/modules/2.6.20-rc5/kernel/net/netfilter/nf_conntrack_proto_gre.ko
-rw-r--r-- 1 root root 7799 Jan 20 14:50 
/lib/modules/2.6.20-rc5/kernel/net/netfilter/nf_conntrack_proto_gre.ko



----- Original Message ----- 
From: "Patrick McHardy" <kaber@trash.net>
To: "Jorge Bastos" <mysql.jorge@decimal.pt>
Cc: <netfilter-devel@lists.netfilter.org>
Sent: Saturday, January 20, 2007 3:45 PM
Subject: Re: PPTP Problem with 2.6.20-rc1 >=


> Jorge Bastos wrote:
>> Ok, i've applied the patch, and recompiled the kernel module but, still
>> nothing:
>
> Thanks. I trust you properly installed the modules and reloaded the PPTP
> helper and GRE conntrack modules?
> 

Re: PPTP Problem with 2.6.20-rc1 >=

[Patrick McHardy]

Jorge Bastos wrote:
> yap, my steps:
> 
> recompiled the kernel module, made a backup of the old module, copied
> the module to the /lib/modules............ to it's place, and restarted
> the machine (just to make sure it get really reloaded!!)
> 
> below in the folow order, original, and module with the patch:
> 
> cisne:/usr/src# l /nf_conntrack_proto_gre.ko
> -rw-r--r-- 1 root root 7470 Jan 20 14:41 /nf_conntrack_proto_gre.ko
> cisne:/usr/src# l
> /lib/modules/2.6.20-rc5/kernel/net/netfilter/nf_conntrack_proto_gre.ko
> -rw-r--r-- 1 root root 7799 Jan 20 14:50
> /lib/modules/2.6.20-rc5/kernel/net/netfilter/nf_conntrack_proto_gre.ko


OK thanks. I'll try to reproduce it myself.

Re: PPTP Problem with 2.6.20-rc1 >=

[Jorge Bastos]

Right, when you'll have news tell me.


----- Original Message ----- 
From: "Patrick McHardy" <kaber@trash.net>
To: "Jorge Bastos" <mysql.jorge@decimal.pt>
Cc: <netfilter-devel@lists.netfilter.org>
Sent: Saturday, January 20, 2007 3:52 PM
Subject: Re: PPTP Problem with 2.6.20-rc1 >=


> Jorge Bastos wrote:
>> yap, my steps:
>> 
>> recompiled the kernel module, made a backup of the old module, copied
>> the module to the /lib/modules............ to it's place, and restarted
>> the machine (just to make sure it get really reloaded!!)
>> 
>> below in the folow order, original, and module with the patch:
>> 
>> cisne:/usr/src# l /nf_conntrack_proto_gre.ko
>> -rw-r--r-- 1 root root 7470 Jan 20 14:41 /nf_conntrack_proto_gre.ko
>> cisne:/usr/src# l
>> /lib/modules/2.6.20-rc5/kernel/net/netfilter/nf_conntrack_proto_gre.ko
>> -rw-r--r-- 1 root root 7799 Jan 20 14:50
>> /lib/modules/2.6.20-rc5/kernel/net/netfilter/nf_conntrack_proto_gre.ko
> 
> 
> OK thanks. I'll try to reproduce it myself.
> 
>

Re: PPTP Problem with 2.6.20-rc1 >=

[Jorge Bastos]

News Patrick?
:PP

Jorge


----- Original Message ----- 
From: "Patrick McHardy" <kaber@trash.net>
To: "Jorge Bastos" <mysql.jorge@decimal.pt>
Cc: <netfilter-devel@lists.netfilter.org>
Sent: Saturday, January 20, 2007 3:52 PM
Subject: Re: PPTP Problem with 2.6.20-rc1 >=


> Jorge Bastos wrote:
>> yap, my steps:
>> 
>> recompiled the kernel module, made a backup of the old module, copied
>> the module to the /lib/modules............ to it's place, and restarted
>> the machine (just to make sure it get really reloaded!!)
>> 
>> below in the folow order, original, and module with the patch:
>> 
>> cisne:/usr/src# l /nf_conntrack_proto_gre.ko
>> -rw-r--r-- 1 root root 7470 Jan 20 14:41 /nf_conntrack_proto_gre.ko
>> cisne:/usr/src# l
>> /lib/modules/2.6.20-rc5/kernel/net/netfilter/nf_conntrack_proto_gre.ko
>> -rw-r--r-- 1 root root 7799 Jan 20 14:50
>> /lib/modules/2.6.20-rc5/kernel/net/netfilter/nf_conntrack_proto_gre.ko
> 
> 
> OK thanks. I'll try to reproduce it myself.
> 
>

Re: PPTP Problem with 2.6.20-rc1 >=

[Patrick McHardy]

[-- Attachment #1: Type: text/plain, Size: 116 bytes --]

Patrick McHardy wrote:
> OK thanks. I'll try to reproduce it myself.

Please try these patches, they should fix it.

[-- Attachment #2: 01.diff --]
[-- Type: text/x-diff, Size: 2688 bytes --]

[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

[-- Attachment #3: 02.diff --]
[-- Type: text/x-diff, Size: 1406 bytes --]

[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;
 	}

[-- Attachment #4: 03.diff --]
[-- Type: text/x-diff, Size: 1393 bytes --]

[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;

Re: PPTP Problem with 2.6.20-rc1 >=

[Jorge Bastos]

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;
> 

Re: PPTP Problem with 2.6.20-rc1 >=

[Patrick McHardy]

Jorge Bastos wrote:
> Patrick,
> 
> Perfect!

Thanks for testing.

> Tell me, these patch's will be present in kernel in wich version?

The next one most likely, whatever that will be.

Re: PPTP Problem with 2.6.20-rc1 >=

[Jorge Bastos]

Ok i've saw your email asking this to be added to the next final version 
2.6.20
I'm glad i helped :P

Thanks again Patrick

Jorge



----- Original Message ----- 
From: "Patrick McHardy" <kaber@trash.net>
To: "Jorge Bastos" <mysql.jorge@decimal.pt>
Cc: <netfilter-devel@lists.netfilter.org>
Sent: Thursday, January 25, 2007 12:14 AM
Subject: Re: PPTP Problem with 2.6.20-rc1 >=


> Jorge Bastos wrote:
>> Patrick,
>>
>> Perfect!
>
> Thanks for testing.
>
>> Tell me, these patch's will be present in kernel in wich version?
>
> The next one most likely, whatever that will be.
>
> 

Re: PPTP Problem with 2.6.20-rc1 >=

[Jorge Bastos]

Patrick,
How can i confirm/can you if this fix is included in the 2.6.20-rc6 ?

Thanks,
Jorge


----- Original Message ----- 
From: "Patrick McHardy" <kaber@trash.net>
To: "Jorge Bastos" <mysql.jorge@decimal.pt>
Cc: <netfilter-devel@lists.netfilter.org>
Sent: Thursday, January 25, 2007 12:14 AM
Subject: Re: PPTP Problem with 2.6.20-rc1 >=


> Jorge Bastos wrote:
>> Patrick,
>> 
>> Perfect!
> 
> Thanks for testing.
> 
>> Tell me, these patch's will be present in kernel in wich version?
> 
> The next one most likely, whatever that will be.
> 
>

Re: PPTP Problem with 2.6.20-rc1 >=

[Jorge Bastos]

Hi Patrick,

I noticed that in 2.6.20-rc6 the fix for this is not included yet, do you 
confirm?
At least i cannot make connections.

Jorge



----- Original Message ----- 
From: "Patrick McHardy" <kaber@trash.net>
To: "Jorge Bastos" <mysql.jorge@decimal.pt>
Cc: <netfilter-devel@lists.netfilter.org>
Sent: Thursday, January 25, 2007 12:14 AM
Subject: Re: PPTP Problem with 2.6.20-rc1 >=


> Jorge Bastos wrote:
>> Patrick,
>>
>> Perfect!
>
> Thanks for testing.
>
>> Tell me, these patch's will be present in kernel in wich version?
>
> The next one most likely, whatever that will be.
>
>