From mboxrd@z Thu Jan 1 00:00:00 1970 From: Patrick McHardy Subject: Re: PPTP Problem with 2.6.20-rc1 >= Date: Sat, 20 Jan 2007 13:18:56 +0100 Message-ID: <45B208B0.8050707@trash.net> References: <087801c73c89$cb5e00b0$0301a8c0@hercules.decimalint.pt> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="------------050705080001050801000403" Cc: netfilter-devel@lists.netfilter.org Return-path: To: Jorge Bastos In-Reply-To: <087801c73c89$cb5e00b0$0301a8c0@hercules.decimalint.pt> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: netfilter-devel-bounces@lists.netfilter.org Errors-To: netfilter-devel-bounces@lists.netfilter.org List-Id: netfilter-devel.vger.kernel.org This is a multi-part message in MIME format. --------------050705080001050801000403 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit 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? --------------050705080001050801000403 Content-Type: text/plain; name="x" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="x" 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; } --------------050705080001050801000403--