Fw: Problems with nf_nat_ftp.ko and nf_conntrack_ftp.ko in 2.6.22.6

Fw: Problems with nf_nat_ftp.ko and nf_conntrack_ftp.ko in 2.6.22.6

[Ron Lai]

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

The log I got is listed below and the corresponding pcap file is attached.

Nov  1 21:14:54 ron kernel: ftp: Conntrackinfo = 2
Nov  1 21:14:54 ron kernel: ftp: Conntrackinfo = 2
Nov  1 21:14:54 ron kernel: ftp: dataoff(60) >= skblen(60)
Nov  1 21:14:54 ron kernel: ftp: dataoff(60) >= skblen(60)
Nov  1 21:14:54 ron kernel: ftp: dataoff(52) >= skblen(52)
Nov  1 21:14:54 ron kernel: ftp: dataoff(52) >= skblen(52)
Nov  1 21:14:54 ron kernel: nf_conntrack_ftp_help: wrong seq pos (UNSET)(0) 
or (UNSET)(0)
Nov  1 21:14:54 ron kernel: nf_conntrack_ftp_help: wrong seq pos 
(3267319485) or (UNSET)(0)
Nov  1 21:14:54 ron kernel: ftp: dataoff(52) >= skblen(52)
Nov  1 21:14:54 ron kernel: ftp: dataoff(52) >= skblen(52)
Nov  1 21:14:59 ron kernel: nf_conntrack_ftp_help: wrong seq pos (UNSET)(0) 
or (UNSET)(0)
Nov  1 21:14:59 ron kernel: nf_conntrack_ftp_help: wrong seq pos 
(3733317025) or (UNSET)(0)
Nov  1 21:14:59 ron kernel: ftp: dataoff(52) >= skblen(52)
Nov  1 21:14:59 ron kernel: ftp: dataoff(52) >= skblen(52)
Nov  1 21:14:59 ron kernel: find_pattern `227 ': dlen = 45
Nov  1 21:14:59 ron kernel: find_pattern `229 ': dlen = 45
Nov  1 21:14:59 ron kernel: find_pattern `227 ': dlen = 45
Nov  1 21:14:59 ron kernel: find_pattern `229 ': dlen = 45
Nov  1 21:14:59 ron kernel: ftp: dataoff(52) >= skblen(52)
Nov  1 21:14:59 ron kernel: ftp: dataoff(52) >= skblen(52)
Nov  1 21:15:15 ron kernel: find_pattern `PORT': dlen = 7
Nov  1 21:15:15 ron kernel: find_pattern `EPRT': dlen = 7
Nov  1 21:15:15 ron kernel: find_pattern `PORT': dlen = 7
Nov  1 21:15:15 ron kernel: find_pattern `EPRT': dlen = 7
Nov  1 21:15:15 ron kernel: find_pattern `227 ': dlen = 48
Nov  1 21:15:15 ron kernel: find_pattern `229 ': dlen = 48
Nov  1 21:15:15 ron kernel: find_pattern `227 ': dlen = 48
Nov  1 21:15:15 ron kernel: find_pattern `229 ': dlen = 48
Nov  1 21:15:15 ron kernel: ftp: dataoff(52) >= skblen(52)
Nov  1 21:15:15 ron kernel: ftp: dataoff(52) >= skblen(52)
Nov  1 21:15:15 ron kernel: find_pattern `PORT': dlen = 6
Nov  1 21:15:15 ron kernel: find_pattern `EPRT': dlen = 6
Nov  1 21:15:15 ron kernel: find_pattern `PORT': dlen = 6
Nov  1 21:15:15 ron kernel: find_pattern `EPRT': dlen = 6
Nov  1 21:15:15 ron kernel: find_pattern `227 ': dlen = 19
Nov  1 21:15:15 ron kernel: find_pattern `229 ': dlen = 19
Nov  1 21:15:15 ron kernel: find_pattern `227 ': dlen = 19
Nov  1 21:15:15 ron kernel: find_pattern `229 ': dlen = 19
Nov  1 21:15:15 ron kernel: ftp: dataoff(52) >= skblen(52)
Nov  1 21:15:15 ron kernel: ftp: dataoff(52) >= skblen(52)
Nov  1 21:15:19 ron kernel: find_pattern `PORT': dlen = 27
Nov  1 21:15:19 ron kernel: Pattern matches!
Nov  1 21:15:19 ron kernel: Skipped up to ` '!
Nov  1 21:15:19 ron kernel: Match succeeded!
Nov  1 21:15:19 ron kernel: conntrack_ftp: match `172,16,119,91,128,61' (20 
bytes at 3733317043)
Nov  1 21:15:19 ron kernel: FTP_NAT: type 0, off 5 len 20
Nov  1 21:15:19 ron kernel: calling nf_nat_mangle_tcp_packet
Nov  1 21:15:19 ron kernel: nf_nat_mangle_packet: Extending packet by 1 from 
79 bytes
Nov  1 21:15:19 ron kernel: nf_nat_resize_packet: Seq_offset before: 
offset_before=0, offset_after=0, correction_pos=0
Nov  1 21:15:19 ron kernel: nf_nat_resize_packet: Seq_offset after: 
offset_before=0, offset_after=1, correction_pos=3733317038
Nov  1 21:15:19 ron kernel: Adjusting sequence number from 
3733317038->3733317038, ack from 3267319597->3267319597
Nov  1 21:15:19 ron kernel: find_pattern `PORT': dlen = 28
Nov  1 21:15:19 ron kernel: Pattern matches!
Nov  1 21:15:19 ron kernel: Skipped up to ` '!
Nov  1 21:15:19 ron kernel: Match succeeded!
Nov  1 21:15:19 ron kernel: conntrack_ftp: match `172,16,255,123,128,61' (21 
bytes at 3733317043)
Nov  1 21:15:19 ron kernel: conntrack_ftp: NOT RECORDING: 172.16.255.123 != 
172.16.119.91
Nov  1 21:15:19 ron kernel: Adjusting sequence number from 
3733317038->3733317038, ack from 3267319597->3267319597
Nov  1 21:15:19 ron kernel: find_pattern `227 ': dlen = 30
Nov  1 21:15:19 ron kernel: find_pattern `229 ': dlen = 30
Nov  1 21:15:19 ron kernel: Adjusting sequence number from 
3267319597->3267319597, ack from 3733317066->3733317065
Nov  1 21:15:19 ron kernel: find_pattern `227 ': dlen = 30
Nov  1 21:15:19 ron kernel: find_pattern `229 ': dlen = 30
Nov  1 21:15:19 ron kernel: Adjusting sequence number from 
3267319597->3267319597, ack from 3733317065->3733317064
Nov  1 21:15:19 ron kernel: ftp: dataoff(52) >= skblen(52)
Nov  1 21:15:19 ron kernel: Adjusting sequence number from 
3733317065->3733317066, ack from 3267319627->3267319627
Nov  1 21:15:19 ron kernel: ftp: dataoff(52) >= skblen(52)
Nov  1 21:15:19 ron kernel: Adjusting sequence number from 
3733317066->3733317067, ack from 3267319627->3267319627
Nov  1 21:15:19 ron kernel: nf_conntrack_ftp_help: wrong seq pos 
(3733317066) or (3733317065)
Nov  1 21:15:19 ron kernel: Adjusting sequence number from 
3733317064->3733317065, ack from 3267319627->3267319627
Nov  1 21:15:19 ron kernel: find_pattern `PORT': dlen = 1
Nov  1 21:15:19 ron kernel: find_pattern `EPRT': dlen = 1
Nov  1 21:15:19 ron kernel: Adjusting sequence number from 
3733317065->3733317066, ack from 3267319627->3267319627
Nov  1 21:15:19 ron kernel: find_pattern `227 ': dlen = 33
Nov  1 21:15:19 ron kernel: find_pattern `229 ': dlen = 33
Nov  1 21:15:19 ron kernel: Adjusting sequence number from 
3267319627->3267319627, ack from 3733317067->3733317066
Nov  1 21:15:19 ron kernel: find_pattern `227 ': dlen = 33
Nov  1 21:15:19 ron kernel: find_pattern `229 ': dlen = 33
Nov  1 21:15:19 ron kernel: Adjusting sequence number from 
3267319627->3267319627, ack from 3733317066->3733317065
Nov  1 21:15:19 ron kernel: find_pattern `PORT': dlen = 6
Nov  1 21:15:19 ron kernel: find_pattern `EPRT': dlen = 6
Nov  1 21:15:19 ron kernel: Adjusting sequence number from 
3733317065->3733317066, ack from 3267319660->3267319660
Nov  1 21:15:19 ron kernel: find_pattern `PORT': dlen = 6
Nov  1 21:15:19 ron kernel: find_pattern `EPRT': dlen = 6
Nov  1 21:15:19 ron kernel: Adjusting sequence number from 
3733317066->3733317067, ack from 3267319660->3267319660
Nov  1 21:15:19 ron kernel: find_pattern `227 ': dlen = 53
Nov  1 21:15:19 ron kernel: find_pattern `229 ': dlen = 53
Nov  1 21:15:19 ron kernel: Adjusting sequence number from 
3267319660->3267319660, ack from 3733317073->3733317072
Nov  1 21:15:19 ron kernel: find_pattern `227 ': dlen = 53
Nov  1 21:15:19 ron kernel: find_pattern `229 ': dlen = 53
Nov  1 21:15:19 ron kernel: Adjusting sequence number from 
3267319660->3267319660, ack from 3733317072->3733317071
Nov  1 21:15:19 ron kernel: ftp: dataoff(52) >= skblen(52)
Nov  1 21:15:19 ron kernel: Adjusting sequence number from 
3733317071->3733317072, ack from 3267319713->3267319713
Nov  1 21:15:19 ron kernel: ftp: dataoff(52) >= skblen(52)
Nov  1 21:15:19 ron kernel: Adjusting sequence number from 
3733317072->3733317073, ack from 3267319713->3267319713
Nov  1 21:15:19 ron kernel: find_pattern `227 ': dlen = 24
Nov  1 21:15:19 ron kernel: find_pattern `229 ': dlen = 24
Nov  1 21:15:19 ron kernel: Adjusting sequence number from 
3267319713->3267319713, ack from 3733317073->3733317072
Nov  1 21:15:19 ron kernel: find_pattern `227 ': dlen = 24
Nov  1 21:15:19 ron kernel: find_pattern `229 ': dlen = 24
Nov  1 21:15:19 ron kernel: Adjusting sequence number from 
3267319713->3267319713, ack from 3733317072->3733317071
Nov  1 21:15:19 ron kernel: ftp: dataoff(52) >= skblen(52)
Nov  1 21:15:19 ron kernel: Adjusting sequence number from 
3733317071->3733317072, ack from 3267319737->3267319737
Nov  1 21:15:19 ron kernel: ftp: dataoff(52) >= skblen(52)
Nov  1 21:15:19 ron kernel: Adjusting sequence number from 
3733317072->3733317073, ack from 3267319737->3267319737
Nov  1 21:15:23 ron kernel: find_pattern `PORT': dlen = 6
Nov  1 21:15:23 ron kernel: find_pattern `EPRT': dlen = 6
Nov  1 21:15:23 ron kernel: Adjusting sequence number from 
3733317071->3733317072, ack from 3267319737->3267319737
Nov  1 21:15:23 ron kernel: find_pattern `PORT': dlen = 6
Nov  1 21:15:23 ron kernel: find_pattern `EPRT': dlen = 6
Nov  1 21:15:23 ron kernel: Adjusting sequence number from 
3733317072->3733317073, ack from 3267319737->3267319737
Nov  1 21:15:23 ron kernel: ftp: dataoff(52) >= skblen(52)
Nov  1 21:15:23 ron kernel: Adjusting sequence number from 
3733317077->3733317078, ack from 3267319737->3267319737
Nov  1 21:15:23 ron kernel: ftp: dataoff(52) >= skblen(52)
Nov  1 21:15:23 ron kernel: Adjusting sequence number from 
3733317078->3733317079, ack from 3267319737->3267319737
Nov  1 21:15:23 ron kernel: find_pattern `227 ': dlen = 14
Nov  1 21:15:23 ron kernel: find_pattern `229 ': dlen = 14
Nov  1 21:15:23 ron kernel: Adjusting sequence number from 
3267319737->3267319737, ack from 3733317079->3733317078
Nov  1 21:15:23 ron kernel: find_pattern `227 ': dlen = 14
Nov  1 21:15:23 ron kernel: find_pattern `229 ': dlen = 14
Nov  1 21:15:23 ron kernel: Adjusting sequence number from 
3267319737->3267319737, ack from 3733317078->3733317077
Nov  1 21:15:23 ron kernel: ftp: dataoff(52) >= skblen(52)
Nov  1 21:15:23 ron kernel: Adjusting sequence number from 
3267319751->3267319751, ack from 3733317079->3733317078
Nov  1 21:15:23 ron kernel: ftp: dataoff(52) >= skblen(52)
Nov  1 21:15:23 ron kernel: Adjusting sequence number from 
3267319751->3267319751, ack from 3733317078->3733317077
Nov  1 21:15:23 ron kernel: ftp: dataoff(52) >= skblen(52)
Nov  1 21:15:23 ron kernel: Adjusting sequence number from 
3267319752->3267319752, ack from 3733317080->3733317079
Nov  1 21:15:23 ron kernel: ftp: dataoff(52) >= skblen(52)
Nov  1 21:15:23 ron kernel: Adjusting sequence number from 
3267319752->3267319752, ack from 3733317079->3733317078
Nov  1 21:15:23 ron kernel: ftp: dataoff(40) >= skblen(40)
Nov  1 21:15:23 ron kernel: Adjusting sequence number from 
3733317077->3733317078, ack from 0->0
Nov  1 21:15:23 ron kernel: ftp: dataoff(40) >= skblen(40)
Nov  1 21:15:23 ron kernel: Adjusting sequence number from 
3733317078->3733317079, ack from 0->0
Nov  1 21:15:23 ron kernel: ftp: dataoff(40) >= skblen(40)
Nov  1 21:15:23 ron kernel: Adjusting sequence number from 
3733317077->3733317078, ack from 0->0
Nov  1 21:15:23 ron kernel: ftp: dataoff(40) >= skblen(40)
Nov  1 21:15:23 ron kernel: Adjusting sequence number from 
3733317078->3733317079, ack from 0->0
Nov  1 21:15:23 ron kernel: ftp: dataoff(40) >= skblen(40)
Nov  1 21:15:23 ron kernel: Adjusting sequence number from 
3733317078->3733317079, ack from 0->0
Nov  1 21:15:23 ron kernel: ftp: dataoff(40) >= skblen(40)
Nov  1 21:15:23 ron kernel: Adjusting sequence number from 
3733317079->3733317080, ack from 0->0

ron
----- Original Message ----- 
From: "ron lai" <ronlai@cs.stanford.edu>
To: "ron lai" <ronlai@cs.stanford.edu>
Sent: Wednesday, October 31, 2007 10:07 PM
Subject: Fw: Problems with nf_nat_ftp.ko and nf_conntrack_ftp.ko in 2.6.22.6


>
> ----- Original Message ----- 
> From: "Patrick McHardy" <kaber@trash.net>
> To: "Ron Lai" <ronlai@cs.stanford.edu>
> Cc: <netfilter@vger.kernel.org>; "Netfilter Development Mailinglist"
> <netfilter-devel@vger.kernel.org>
> Sent: Monday, October 29, 2007 5:51 AM
> Subject: Re: Problems with nf_nat_ftp.ko and nf_conntrack_ftp.ko in
> 2.6.22.6
>
>
>> Ron Lai wrote:
>>> The packet dump from the 2.6.22.6 box in the middle is attached. In the
>>> trace 172.16.119.91 is the original IP address of the FTP client and
>>> 172.16.255.123 is the NATted address. The FTP server's address is
>>> 172.16.118.1.
>>>
>>> The problem happens between packet 31 and packet 34. Packet 31 indicates
>>> that the client expects ACK number 0x64b4dda9 for the PORT command it
>>> sends. However, the ACK number it actually gets is 0x64b4dda8.
>>
>>
>> Thats really odd. It properly adjusts the sequence number in the
>> original direction by +1, but incorrectly adjusts the acknowledgement
>> in the reply direction by -2. I don't see how this could happen with
>> the vanilla 2.6.22 kernel, are you using any additional patches?
>>
>> Otherwise please edit net/ipv4/netfilter/nf_nat_helper.c and add
>> a #define DEBUG at the first line, recompile and post the output
>> of the failed session (ideally two failed sessions). Thanks.
>>
>> -
>> To unsubscribe from this list: send the line "unsubscribe netfilter" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

[-- Attachment #2: ftp_test.pcap --]
[-- Type: application/octet-stream, Size: 7199 bytes --]

Re: Fw: Problems with nf_nat_ftp.ko and nf_conntrack_ftp.ko in 2.6.22.6

[Amin Azez]

Are you doing SNAT and DNAT on the same connection?

Sam

Re: Fw: Problems with nf_nat_ftp.ko and nf_conntrack_ftp.ko in 2.6.22.6

[ron lai]

The problem happens in both SNAT only and SNAT+DNAT cases.

Ron
----- Original Message ----- 
From: "Amin Azez" <azez@ufomechanic.net>
To: "Ron Lai" <ronlai@cs.stanford.edu>
Cc: "Patrick McHardy" <kaber@trash.net>; <netfilter@vger.kernel.org>; 
<netfilter-devel@vger.kernel.org>
Sent: Monday, November 05, 2007 3:03 AM
Subject: Re: Fw: Problems with nf_nat_ftp.ko and nf_conntrack_ftp.ko in 
2.6.22.6


> Are you doing SNAT and DNAT on the same connection?
>
> Sam
>
> -
> To unsubscribe from this list: send the line "unsubscribe netfilter" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html 

Re: Fw: Problems with nf_nat_ftp.ko and nf_conntrack_ftp.ko in 2.6.22.6

[Patrick McHardy]

Ron Lai wrote:
> The log I got is listed below and the corresponding pcap file is attached.
> 
> Nov  1 21:14:54 ron kernel: ftp: Conntrackinfo = 2
> Nov  1 21:14:54 ron kernel: ftp: Conntrackinfo = 2
> Nov  1 21:14:54 ron kernel: ftp: dataoff(60) >= skblen(60)
> Nov  1 21:14:54 ron kernel: ftp: dataoff(60) >= skblen(60)
> Nov  1 21:14:54 ron kernel: ftp: dataoff(52) >= skblen(52)
> Nov  1 21:14:54 ron kernel: ftp: dataoff(52) >= skblen(52)


This very much looks like your packets hit the helper twice, which would
also explain the double sequence number adjustment. You didn't answer
my question before, are you using any patches?

Re: Fw: Problems with nf_nat_ftp.ko and nf_conntrack_ftp.ko in 2.6.22.6

[ron lai]

No, I am not using any patch. Is there any debug info I can turn on to see 
why the helper gets invoked twice?

BTW, my build is a SMP build.

Ron
----- Original Message ----- 
From: "Patrick McHardy" <kaber@trash.net>
To: "Ron Lai" <ronlai@cs.stanford.edu>
Cc: <netfilter@vger.kernel.org>; <netfilter-devel@vger.kernel.org>
Sent: Tuesday, November 06, 2007 2:14 AM
Subject: Re: Fw: Problems with nf_nat_ftp.ko and nf_conntrack_ftp.ko in 
2.6.22.6


> Ron Lai wrote:
>> The log I got is listed below and the corresponding pcap file is 
>> attached.
>>
>> Nov  1 21:14:54 ron kernel: ftp: Conntrackinfo = 2
>> Nov  1 21:14:54 ron kernel: ftp: Conntrackinfo = 2
>> Nov  1 21:14:54 ron kernel: ftp: dataoff(60) >= skblen(60)
>> Nov  1 21:14:54 ron kernel: ftp: dataoff(60) >= skblen(60)
>> Nov  1 21:14:54 ron kernel: ftp: dataoff(52) >= skblen(52)
>> Nov  1 21:14:54 ron kernel: ftp: dataoff(52) >= skblen(52)
>
>
> This very much looks like your packets hit the helper twice, which would
> also explain the double sequence number adjustment. You didn't answer
> my question before, are you using any patches?
>
> -
> To unsubscribe from this list: send the line "unsubscribe netfilter" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html 

Re: Fw: Problems with nf_nat_ftp.ko and nf_conntrack_ftp.ko in 2.6.22.6

[Patrick McHardy]

ron lai wrote:
> No, I am not using any patch. Is there any debug info I can turn on to 
> see why the helper gets invoked twice?


Nothing really useful. Please post your ruleset and other setup.
Are you using a bridge?

Re: Fw: Problems with nf_nat_ftp.ko and nf_conntrack_ftp.ko in 2.6.22.6

[ron lai]

My ruleset is
iptables -t nat -A POSTROUTING -s 172.16.119.91 -j SNAT --to-source 
172.16.255.123

I am using a bridge containing only one physical interface and the FTP 
traffic goes through the bridge.

Ron
----- Original Message ----- 
From: "Patrick McHardy" <kaber@trash.net>
To: "ron lai" <ronlai@cs.stanford.edu>
Cc: <netfilter@vger.kernel.org>; <netfilter-devel@vger.kernel.org>
Sent: Tuesday, November 06, 2007 5:24 AM
Subject: Re: Fw: Problems with nf_nat_ftp.ko and nf_conntrack_ftp.ko in 
2.6.22.6


> ron lai wrote:
>> No, I am not using any patch. Is there any debug info I can turn on to 
>> see why the helper gets invoked twice?
>
>
> Nothing really useful. Please post your ruleset and other setup.
> Are you using a bridge?
>
> -
> To unsubscribe from this list: send the line "unsubscribe netfilter" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html 

Re: Fw: Problems with nf_nat_ftp.ko and nf_conntrack_ftp.ko in 2.6.22.6

[Patrick McHardy]

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

ron lai wrote:
> My ruleset is
> iptables -t nat -A POSTROUTING -s 172.16.119.91 -j SNAT --to-source 
> 172.16.255.123
> 
> I am using a bridge containing only one physical interface and the FTP 
> traffic goes through the bridge.


That explains it. The bridge netfilter code calls the IP POST_ROUTING
hook for outgoing packets, but the packet already went through it
during forwarding. Please try this patch, which makes the bridge
netfilter code only call the IP hook for packets that also came in
on the bridge.




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

diff --git a/net/bridge/br_netfilter.c b/net/bridge/br_netfilter.c
index 3ee2022..d8e5c94 100644
--- a/net/bridge/br_netfilter.c
+++ b/net/bridge/br_netfilter.c
@@ -773,7 +773,7 @@ static unsigned int br_nf_post_routing(unsigned int hook, struct sk_buff **pskb,
 	}
 #endif
 
-	if (!nf_bridge)
+	if (!nf_bridge || !nf_bridge->physindev)
 		return NF_ACCEPT;
 
 	if (!realoutdev)

Re: Fw: Problems with nf_nat_ftp.ko and nf_conntrack_ftp.ko in 2.6.22.6

[Pascal Hambourg]

Hello,

Patrick McHardy a écrit :
> 
> The bridge netfilter code calls the IP POST_ROUTING
> hook for outgoing packets, but the packet already went through it
> during forwarding.

Indeed I noticed once that a forwarded (i.e. not bridged) IP packet goes 
through the iptables POSTROUTING chain twice (after iptables FORWARD and 
after ebtables POSTROUTING) when the input and output interfaces are 
both bridges. But only once (after iptables FORWARD) when only the 
output interface is a bridge. Puzzles me why.

Re: Fw: Problems with nf_nat_ftp.ko and nf_conntrack_ftp.ko in 2.6.22.6

[ron lai]

I've verified that the module works fine if no bridge is used. Unfortunately 
the patch doesn't fix the 2-calls-of-the-helper-function problem if a bridge 
is applied to the system.

Ron
----- Original Message ----- 
From: "Patrick McHardy" <kaber@trash.net>
To: "ron lai" <ronlai@cs.stanford.edu>
Cc: <netfilter@vger.kernel.org>; <netfilter-devel@vger.kernel.org>; "Bart De 
Schuymer" <bdschuym@pandora.be>
Sent: Tuesday, November 06, 2007 6:05 AM
Subject: Re: Fw: Problems with nf_nat_ftp.ko and nf_conntrack_ftp.ko in 
2.6.22.6


> ron lai wrote:
>> My ruleset is
>> iptables -t nat -A POSTROUTING -s 172.16.119.91 -j SNAT --to-source
>> 172.16.255.123
>>
>> I am using a bridge containing only one physical interface and the FTP
>> traffic goes through the bridge.
>
>
> That explains it. The bridge netfilter code calls the IP POST_ROUTING
> hook for outgoing packets, but the packet already went through it
> during forwarding. Please try this patch, which makes the bridge
> netfilter code only call the IP hook for packets that also came in
> on the bridge.
>
>
>
>


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


> diff --git a/net/bridge/br_netfilter.c b/net/bridge/br_netfilter.c
> index 3ee2022..d8e5c94 100644
> --- a/net/bridge/br_netfilter.c
> +++ b/net/bridge/br_netfilter.c
> @@ -773,7 +773,7 @@ static unsigned int br_nf_post_routing(unsigned int 
> hook, struct sk_buff **pskb,
>  }
> #endif
>
> - if (!nf_bridge)
> + if (!nf_bridge || !nf_bridge->physindev)
>  return NF_ACCEPT;
>
>  if (!realoutdev)
> 

Re: Fw: Problems with nf_nat_ftp.ko and nf_conntrack_ftp.ko in 2.6.22.6

[Patrick McHardy]

ron lai wrote:
> I've verified that the module works fine if no bridge is used. 
> Unfortunately the patch doesn't fix the 2-calls-of-the-helper-function 
> problem if a bridge is applied to the system.


Strange, I can't reproduce this. To clarify - you're using only a
single bridge with one device, or two bridges with one device each?

Re: Fw: Problems with nf_nat_ftp.ko and nf_conntrack_ftp.ko in 2.6.22.6

[Patrick McHardy]

Patrick McHardy wrote:
> ron lai wrote:
>> I've verified that the module works fine if no bridge is used. 
>> Unfortunately the patch doesn't fix the 2-calls-of-the-helper-function 
>> problem if a bridge is applied to the system.
> 
> 
> Strange, I can't reproduce this. To clarify - you're using only a
> single bridge with one device, or two bridges with one device each?


I can reproduce this with forwarding between two bridges.
The reason is that skb->nf_bridge still contains the data
from the first bridge and so br_netfilter thinks this is
a bridged packet. I don't know how this is supposed to work,
but it seems to me that on packets going out a bridge device
this should be reset in case it originates from a different
bridge (actually I think it should be reset unconditionally
but that would probably break bridged DNAT).

Bart, what do you think about changing this:

static unsigned int br_nf_local_out(unsigned int hook, struct sk_buff 
*skb, ...
{
	...
         nf_bridge = skb->nf_bridge;
         if (!(nf_bridge->mask & BRNF_BRIDGED_DNAT))
                 return NF_ACCEPT;

to:

         if (!(nf_bridge->mask & BRNF_BRIDGED_DNAT)) {
		nf_bridge_put(skb->nf_bridge),
		skb->nf_bridge = NULL;
		return NF_ACCEPT;
	}

?

Re: Fw: Problems with nf_nat_ftp.ko and nf_conntrack_ftp.ko in 2.6.22.6

[Pascal Hambourg]

Patrick McHardy a écrit :
> 
> I can reproduce this with forwarding between two bridges.

This matches my own observations.

> The reason is that skb->nf_bridge still contains the data
> from the first bridge and so br_netfilter thinks this is
> a bridged packet.

Am I missing something if I think that this behaviour is badly broken ?

> I don't know how this is supposed to work,
> but it seems to me that on packets going out a bridge device
> this should be reset in case it originates from a different
> bridge (actually I think it should be reset unconditionally

So do I. Otherwise a packet received on a bridge can be forwarded back 
to the same bridge and would be wrongly considered bridged.

> but that would probably break bridged DNAT).

Why ?

Re: Fw: Problems with nf_nat_ftp.ko and nf_conntrack_ftp.ko in 2.6.22.6

[Patrick McHardy]

Please don't trim CC lists.

Pascal Hambourg wrote:
> Patrick McHardy a écrit :
>>
>> I can reproduce this with forwarding between two bridges.
> 
> This matches my own observations.
> 
>> The reason is that skb->nf_bridge still contains the data
>> from the first bridge and so br_netfilter thinks this is
>> a bridged packet.
> 
> Am I missing something if I think that this behaviour is badly broken ?
> 
>> I don't know how this is supposed to work,
>> but it seems to me that on packets going out a bridge device
>> this should be reset in case it originates from a different
>> bridge (actually I think it should be reset unconditionally
> 
> So do I. Otherwise a packet received on a bridge can be forwarded back 
> to the same bridge and would be wrongly considered bridged.
> 
>> but that would probably break bridged DNAT).
> 
> Why ?


Because if I'm not mistaken these packets also go through the
bridge device xmit function.
-
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: Fw: Problems with nf_nat_ftp.ko and nf_conntrack_ftp.ko in 2.6.22.6

[bdschuym@pandora.be]

>----- Oorspronkelijk bericht -----
>Van: Patrick McHardy [mailto:kaber@trash.net]
>Verzonden: woensdag, november 7, 2007 11:33 AM
>Aan: 'ron lai'
>CC: netfilter@vger.kernel.org, netfilter-devel@vger.kernel.org, 'Bart De Schuymer'
>Onderwerp: Re: Fw: Problems with nf_nat_ftp.ko and nf_conntrack_ftp.ko in 2.6.22.6
>
>Patrick McHardy wrote:
>I can reproduce this with forwarding between two bridges.
>The reason is that skb->nf_bridge still contains the data
>from the first bridge and so br_netfilter thinks this is
>a bridged packet. I don't know how this is supposed to work,
>but it seems to me that on packets going out a bridge device
>this should be reset in case it originates from a different
>bridge (actually I think it should be reset unconditionally
>but that would probably break bridged DNAT).
>
>Bart, what do you think about changing this:

(sorry for the webmail mess)
I think that would work. It shouldn't be reset unconditionally at that point since we allow IP dnating of bridged packets (bridged-and-DNAT'ed case). Another solution I think is this:
in br_nf_post_routing():
change
if (!nf_bridge)
to
if (!nf_bridge || !(nf_bridge->mask & BRNF_BRIDGED_DNAT))

This regression was introduced when the ip_out sabotage stuff was removed. br_nf_post_routing should now only consider bridged IP packets.

cheers,
Bart

Re: Fw: Problems with nf_nat_ftp.ko and nf_conntrack_ftp.ko in 2.6.22.6

[Patrick McHardy]

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

bdschuym@pandora.be wrote:
>> Patrick McHardy wrote:
>> I can reproduce this with forwarding between two bridges.
>> The reason is that skb->nf_bridge still contains the data
>>from the first bridge and so br_netfilter thinks this is
>> a bridged packet. I don't know how this is supposed to work,
>> but it seems to me that on packets going out a bridge device
>> this should be reset in case it originates from a different
>> bridge (actually I think it should be reset unconditionally
>> but that would probably break bridged DNAT).
>>
>> Bart, what do you think about changing this:
> 
> (sorry for the webmail mess)
> I think that would work. It shouldn't be reset unconditionally at that point since we allow IP dnating of bridged packets (bridged-and-DNAT'ed case).

Could you check the attached patch?

 > Another solution I think is this:
> in br_nf_post_routing():
> change
> if (!nf_bridge)
> to
> if (!nf_bridge || !(nf_bridge->mask & BRNF_BRIDGED_DNAT))

Wouldn't that break the regular case of packets forwarded
through a single bridge?

> This regression was introduced when the ip_out sabotage stuff was removed. br_nf_post_routing should now only consider bridged IP packets.

Yes, though the underlying problem seems to be that skb->nf_bridge
has no clearly defined lifetime. We want to pass the bridge port
information up exactly one layer, and then it should disappear.
But that seems to require sprinkling nf_bridge_put in lots of places.


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

diff --git a/net/bridge/br_netfilter.c b/net/bridge/br_netfilter.c
index da22f90..b7cac8d 100644
--- a/net/bridge/br_netfilter.c
+++ b/net/bridge/br_netfilter.c
@@ -713,8 +713,11 @@ static unsigned int br_nf_local_out(unsigned int hook, struct sk_buff *skb,
 		return NF_ACCEPT;
 
 	nf_bridge = skb->nf_bridge;
-	if (!(nf_bridge->mask & BRNF_BRIDGED_DNAT))
+	if (!(nf_bridge->mask & BRNF_BRIDGED_DNAT)) {
+		nf_bridge_put(skb->nf_bridge);
+		skb->nf_bridge = NULL;
 		return NF_ACCEPT;
+	}
 
 	/* Bridged, take PF_BRIDGE/FORWARD.
 	 * (see big note in front of br_nf_pre_routing_finish) */

Re: Fw: Problems with nf_nat_ftp.ko and nf_conntrack_ftp.ko in 2.6.22.6

[ron lai]

I am using a single bridge with one device.

Ron
----- Original Message ----- 
From: "Patrick McHardy" <kaber@trash.net>
To: "ron lai" <ronlai@cs.stanford.edu>
Cc: <netfilter@vger.kernel.org>; <netfilter-devel@vger.kernel.org>; "Bart De 
Schuymer" <bdschuym@pandora.be>
Sent: Wednesday, November 07, 2007 1:49 AM
Subject: Re: Fw: Problems with nf_nat_ftp.ko and nf_conntrack_ftp.ko in 
2.6.22.6


> ron lai wrote:
>> I've verified that the module works fine if no bridge is used. 
>> Unfortunately the patch doesn't fix the 2-calls-of-the-helper-function 
>> problem if a bridge is applied to the system.
>
>
> Strange, I can't reproduce this. To clarify - you're using only a
> single bridge with one device, or two bridges with one device each?
>
>
> -
> 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: Fw: Problems with nf_nat_ftp.ko and nf_conntrack_ftp.ko in 2.6.22.6

[Patrick McHardy]

ron lai wrote:
> I am using a single bridge with one device.

In that case please post the full output of:

ip link list
ip addr show
ip route show
brctl show

Re: Fw: Problems with nf_nat_ftp.ko and nf_conntrack_ftp.ko in 2.6.22.6

[Bart De Schuymer]

Op wo, 07-11-2007 te 12:55 +0100, schreef Patrick McHardy:
> Could you check the attached patch?

Looks ok to me.

>  > Another solution I think is this:
> > in br_nf_post_routing():
> > change
> > if (!nf_bridge)
> > to
> > if (!nf_bridge || !(nf_bridge->mask & BRNF_BRIDGED_DNAT))
> 
> Wouldn't that break the regular case of packets forwarded
> through a single bridge?

Hmm, yes, we'd need to or it with BRNF_BRIDGED. I personally prefer
something like that, leaving the call to nf_bridge_put when the skbuff
is removed. But it's your call :)

cheers,
Bart

Re: Fw: Problems with nf_nat_ftp.ko and nf_conntrack_ftp.ko in 2.6.22.6

[Ron Lai]

-ip link list
1: pether1: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen 
1000
    link/ether 00:d0:68:0d:f4:94 brd ff:ff:ff:ff:ff:ff
2: pether2: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 00:d0:68:0d:f4:93 brd ff:ff:ff:ff:ff:ff
3: pether6: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 00:e0:ed:07:f8:98 brd ff:ff:ff:ff:ff:ff
4: pether5: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 00:e0:ed:07:f8:99 brd ff:ff:ff:ff:ff:ff
5: pether4: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 00:e0:ed:07:f8:9a brd ff:ff:ff:ff:ff:ff
6: pether3: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 00:e0:ed:07:f8:9b brd ff:ff:ff:ff:ff:ff
7: lo: <LOOPBACK,UP,10000> mtu 16436 qdisc noqueue
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
12: ether1: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc noqueue
    link/ether 00:d0:68:0d:f4:94 brd ff:ff:ff:ff:ff:ff

-ip addr show
1: pether1: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen 
1000
    link/ether 00:d0:68:0d:f4:94 brd ff:ff:ff:ff:ff:ff
2: pether2: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 00:d0:68:0d:f4:93 brd ff:ff:ff:ff:ff:ff
3: pether6: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 00:e0:ed:07:f8:98 brd ff:ff:ff:ff:ff:ff
4: pether5: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 00:e0:ed:07:f8:99 brd ff:ff:ff:ff:ff:ff
5: pether4: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 00:e0:ed:07:f8:9a brd ff:ff:ff:ff:ff:ff
6: pether3: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 00:e0:ed:07:f8:9b brd ff:ff:ff:ff:ff:ff
7: lo: <LOOPBACK,UP,10000> mtu 16436 qdisc noqueue
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
12: ether1: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc noqueue
    link/ether 00:d0:68:0d:f4:94 brd ff:ff:ff:ff:ff:ff
    inet 172.16.119.87/12 brd 172.31.255.255 scope global ether1

-ip route show
172.16.0.0/12 dev ether1  proto kernel  scope link  src 172.16.119.87
default via 172.16.1.1 dev ether1  metric 1

-brctl show
bridge name     bridge id               STP enabled     interfaces
ether1          8000.00d0680df494       no              pether1

----- Original Message ----- 
From: "Patrick McHardy" <kaber@trash.net>
To: "ron lai" <ronlai@cs.stanford.edu>
Cc: <netfilter@vger.kernel.org>; <netfilter-devel@vger.kernel.org>; "Bart De 
Schuymer" <bdschuym@pandora.be>
Sent: Wednesday, November 07, 2007 3:19 PM
Subject: Re: Fw: Problems with nf_nat_ftp.ko and nf_conntrack_ftp.ko in 
2.6.22.6


> ron lai wrote:
>> I am using a single bridge with one device.
>
> In that case please post the full output of:
>
> ip link list
> ip addr show
> ip route show
> brctl show
> -
> To unsubscribe from this list: send the line "unsubscribe netfilter" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html 

Re: Fw: Problems with nf_nat_ftp.ko and nf_conntrack_ftp.ko in 2.6.22.6

[Philip Craig]

Patrick McHardy wrote:
>  > Another solution I think is this:
>> in br_nf_post_routing():
>> change
>> if (!nf_bridge)
>> to
>> if (!nf_bridge || !(nf_bridge->mask & BRNF_BRIDGED_DNAT))
> 
> Wouldn't that break the regular case of packets forwarded
> through a single bridge?

How about:

if (!nf_bridge || !(nf_bridge->mask & (BRNF_BRIDGED | BRNF_BRIDGED_DNAT))

(I didn't follow the code enough to see if BRNF_BRIDGED_DNAT
implies BRNF_BRIDGED.)

> Yes, though the underlying problem seems to be that skb->nf_bridge
> has no clearly defined lifetime. We want to pass the bridge port
> information up exactly one layer, and then it should disappear.
> But that seems to require sprinkling nf_bridge_put in lots of places.

An alternative to clearing nf_bridge is settings flags in the mask,
whether that is existing flags or a new one.

Re: Fw: Problems with nf_nat_ftp.ko and nf_conntrack_ftp.ko in 2.6.22.6

[Pascal Hambourg]

Ron Lai a écrit :
> 
> -ip route show
> 172.16.0.0/12 dev ether1  proto kernel  scope link  src 172.16.119.87
> default via 172.16.1.1 dev ether1  metric 1
> 
> -brctl show
> bridge name     bridge id               STP enabled     interfaces
> ether1          8000.00d0680df494       no              pether1
[...]
>>> I am using a single bridge with one device.

But from the information you provided it seems that the bridge "ether1" 
is the only active interface in you system. So IP forwarding can only 
happen from a bridge (ether1) to a bridge (ether1), which is the 
situation causing the IP POST_ROUTING hook to be called twice.

Re: Fw: Problems with nf_nat_ftp.ko and nf_conntrack_ftp.ko in 2.6.22.6

[Patrick McHardy]

Pascal Hambourg wrote:
> Ron Lai a écrit :
>>
>> -ip route show
>> 172.16.0.0/12 dev ether1  proto kernel  scope link  src 172.16.119.87
>> default via 172.16.1.1 dev ether1  metric 1
>>
>> -brctl show
>> bridge name     bridge id               STP enabled     interfaces
>> ether1          8000.00d0680df494       no              pether1
> [...]
>>>> I am using a single bridge with one device.
> 
> But from the information you provided it seems that the bridge "ether1" 
> is the only active interface in you system. So IP forwarding can only 
> happen from a bridge (ether1) to a bridge (ether1), which is the 
> situation causing the IP POST_ROUTING hook to be called twice.


That explains how it can happen with only a single bridge, thanks :)

-
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: Fw: Problems with nf_nat_ftp.ko and nf_conntrack_ftp.ko in 2.6.22.6

[Patrick McHardy]

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

Bart De Schuymer wrote:
> Op wo, 07-11-2007 te 12:55 +0100, schreef Patrick McHardy:
>> Could you check the attached patch?
> 
> Looks ok to me.
> 
>>  > Another solution I think is this:
>>> in br_nf_post_routing():
>>> change
>>> if (!nf_bridge)
>>> to
>>> if (!nf_bridge || !(nf_bridge->mask & BRNF_BRIDGED_DNAT))
>> Wouldn't that break the regular case of packets forwarded
>> through a single bridge?
> 
> Hmm, yes, we'd need to or it with BRNF_BRIDGED. I personally prefer
> something like that, leaving the call to nf_bridge_put when the skbuff
> is removed. But it's your call :)


Both are fine with me. Does this patch look correct to you?


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

diff --git a/net/bridge/br_netfilter.c b/net/bridge/br_netfilter.c
index da22f90..ce68284 100644
--- a/net/bridge/br_netfilter.c
+++ b/net/bridge/br_netfilter.c
@@ -766,6 +766,9 @@ static unsigned int br_nf_post_routing(unsigned int hook, struct sk_buff *skb,
 	if (!nf_bridge)
 		return NF_ACCEPT;
 
+	if (!nf_bridge->mask & (BRNF_BRIDGED | BRNF_BRIDGED_DNAT))
+		return NF_ACCEPT;
+
 	if (!realoutdev)
 		return NF_DROP;
 

Re: Fw: Problems with nf_nat_ftp.ko and nf_conntrack_ftp.ko in 2.6.22.6

[bdschuym@pandora.be]

>Van: Patrick McHardy [mailto:kaber@trash.net]
>> Hmm, yes, we'd need to or it with BRNF_BRIDGED. I personally prefer
>> something like that, leaving the call to nf_bridge_put when the skbuff
>> is removed. But it's your call :)
>
>
>Both are fine with me. Does this patch look correct to you?

Yes.

cheers,
Bart

Re: Fw: Problems with nf_nat_ftp.ko and nf_conntrack_ftp.ko in 2.6.22.6

[Philip Craig]

Patrick McHardy wrote:
> Both are fine with me. Does this patch look correct to you?
> 
> +	if (!nf_bridge->mask & (BRNF_BRIDGED | BRNF_BRIDGED_DNAT))

I think it needs more parentheses:

	if (!(nf_bridge->mask & (BRNF_BRIDGED | BRNF_BRIDGED_DNAT)))

Re: Fw: Problems with nf_nat_ftp.ko and nf_conntrack_ftp.ko in 2.6.22.6

[Patrick McHardy]

Philip Craig wrote:
> Patrick McHardy wrote:
>> Both are fine with me. Does this patch look correct to you?
>>
>> +	if (!nf_bridge->mask & (BRNF_BRIDGED | BRNF_BRIDGED_DNAT))
> 
> I think it needs more parentheses:
> 
> 	if (!(nf_bridge->mask & (BRNF_BRIDGED | BRNF_BRIDGED_DNAT)))
> 


Yes, I already noticed and fixed that when trying to compile it :)