Hello,
I sent the quoted mail to linux-net with my problem yesterday, but I
did a git bisect today and I got the following output :
> 2bf540b73ed5b304e84bb4d4c390d49d1cfa0ef8 is first bad commit
> commit 2bf540b73ed5b304e84bb4d4c390d49d1cfa0ef8
> Author: Patrick McHardy <kaber@xxxxxxxxx>
> Date: Wed Dec 13 16:54:25 2006 -0800
>
> [NETFILTER]: bridge-netfilter: remove deferred hooks
>
> Remove the deferred hooks and all related code as scheduled in
> feature-removal-schedule.
>
> Signed-off-by: Patrick McHardy <kaber@xxxxxxxxx>
> Signed-off-by: David S. Miller <davem@xxxxxxxxxxxxx>
>
> :040000 040000 c49ea947455937566b6129991dde5e86f2453aae 6611736ce5c0fcde7627494b66b9ea94e37ea42e M Documentation
> :040000 040000 d0dd0700fe68f98b52687be3a0c31d73f7b15b81 f8ddf15a0389c5f5b7f2c11d7d0db039a660e1d5 M include
> :040000 040000 dafccf7ff8657be9adca6b28dbd365cdd6c01ca5 3eeb1cb4b16cc5cb698ab559b47ea6b0991d4d3a M net
With exactly this version, the behaviour is similar with what I see
with 2.6.23 and 2.6.24-rc5 (see below).
The original mail :
On Dec 18, 2007 3:48 PM, Damien Thébault <damien.thebault@xxxxxxxxx> wrote:
> Hello,
>
> I was trying to use a setup with nat and bridge, but conntrack doesn't
> work properly (at first I tried rtsp, but since it's an external patch
> with some modifications, I used ftp for my tests).
> I removed everything but the minimal setup to report this bug :
>
> A) one ftp client, on 192.168.1.0/24 (192.168.1.50 or 192.168.1.5 or
> 192.168.1.150 or 192.168.1.15, see below)
> B) one router doing nat
> b1) one interface is on 192.168.1.0/24 with the ftp client (192.168.1.70)
> b2) the other interface is on 192.168.2.0/24 with the ftp server
> (192.168.2.70 or 192.168.2.7, see below)
> C) one ftp server, on 192.168.2.0/24 (192.168.2.50)
>
> To do my tests, I used only one physical interface on the router,
> configured with two ip addresses. This interface is either a real
> interface or a bridge on top of only this same real interface, for
> exemple :
> ifconfig eth0 192.168.1.70 up
> ifconfig eth0:0 192.168.2.70 up
> or :
> ifconfig eth0:0 down
> brctl addbr br0
> brctl addif br0 eth0
> ifconfig eth0 0.0.0.0 up
> ifconfig br0 192.168.1.70 up
> ifconfig br0:0 192.168.2.70 up
>
> the following netfilter configuration is used :
> iptables -t nat -A POSTROUTING -d 192.168.2.0/24 -j MASQUERADE
>
> I tried this once with three computers, and the today with only two
> computers. But to do this two-computers setup, I had to add another
> rule to do the trick :
> iptables -t nat -A PREROUTING -d 192.168.2.250 -j DNAT
> --to-destination 192.168.2.50
> And I connect from the computer with both 192.168.1.50 and
> 192.168.2.50 to the ftp server 192.168.2.250, the route for
> 192.168.2.0/24 goes via the router, is natted and comes back.
> The behaviour is the same with three distinct computers or with this,
> so it's not really interesting here.
>
> What I'm seeing, is that when the bridge is used, and when the output
> ip address of the router is longer or smaller than the ip address of
> the client, then conntrack doesn't work!
> The good address is present after nat_ftp ("wan"-side ip address of
> ther router), everything seems to work well but the incoming connexion
> from port 20 is not forwarded (RST is replied to the SYN).
> If the bridge is not used, or if the two ip addresses have the same
> length, then it works as expected.
>
> The kernel used on the router is 2.6.24-rc5-git5, and active ftp is used.
> I collected /proc/net/nf_conntrack on each try, if something else is
> needed, I'll get what is needed (the packets captures with wireshark
> look ok in every case, but maybe someone will need them?).
>
> 1) without a bridge
> * 192.168.1.50 -> 192.168.1.70 [ nat ] 192.168.2.7 -> 192.168.2.50
> ftp works
> /proc/net/nf_conntrack :
> ipv4 2 tcp 6 118 TIME_WAIT src=192.168.2.50 dst=192.168.2.7
> sport=20 dport=51956 packets=5 bytes=334 src=192.168.1.50
> dst=192.168.2.250 sport=51956 dport=20 packets=3 bytes=164 [ASSURED]
> mark=0 secmark=0 use=1
> ipv4 2 tcp 6 431998 ESTABLISHED src=192.168.1.50
> dst=192.168.2.250 sport=52709 dport=21 packets=11 bytes=635
> src=192.168.2.50 dst=192.168.2.7 sport=21 dport=52709 packets=8
> bytes=880 [ASSURED] mark=0 secmark=0 use=2
>
> * 192.168.1.50 -> 192.168.1.70 [ nat ] 192.168.2.70 -> 192.168.2.50
> ftp works
> /proc/net/nf_conntrack :
> ipv4 2 tcp 6 431998 ESTABLISHED src=192.168.1.50
> dst=192.168.2.250 sport=52747 dport=21 packets=11 bytes=634
> src=192.168.2.50 dst=192.168.2.70 sport=21 dport=52747 packets=8
> bytes=880 [ASSURED] mark=0 secmark=0 use=2
> ipv4 2 tcp 6 118 TIME_WAIT src=192.168.2.50 dst=192.168.2.70
> sport=20 dport=43608 packets=5 bytes=334 src=192.168.1.50
> dst=192.168.2.250 sport=43608 dport=20 packets=3 bytes=164 [ASSURED]
> mark=0 secmark=0 use=1
>
> * 192.168.1.5 -> 192.168.1.70 [ nat ] 192.168.2.7 -> 192.168.2.50
> ftp works
> /proc/net/nf_conntrack :
> ipv4 2 tcp 6 117 TIME_WAIT src=192.168.2.50 dst=192.168.2.7
> sport=20 dport=41758 packets=5 bytes=334 src=192.168.1.5
> dst=192.168.2.250 sport=41758 dport=20 packets=3 bytes=164 [ASSURED]
> mark=0 secmark=0 use=1
> ipv4 2 tcp 6 431997 ESTABLISHED src=192.168.1.5
> dst=192.168.2.250 sport=47397 dport=21 packets=11 bytes=633
> src=192.168.2.50 dst=192.168.2.7 sport=21 dport=47397 packets=8
> bytes=880 [ASSURED] mark=0 secmark=0 use=2
>
> * 192.168.1.5 -> 192.168.1.70 [ nat ] 192.168.2.70 -> 192.168.2.50
> ftp works
> /proc/net/nf_conntrack :
> ipv4 2 tcp 6 431998 ESTABLISHED src=192.168.1.5
> dst=192.168.2.250 sport=53851 dport=21 packets=11 bytes=634
> src=192.168.2.50 dst=192.168.2.70 sport=21 dport=53851 packets=8
> bytes=880 [ASSURED] mark=0 secmark=0 use=2
> ipv4 2 tcp 6 118 TIME_WAIT src=192.168.2.50 dst=192.168.2.70
> sport=20 dport=51600 packets=5 bytes=334 src=192.168.1.5
> dst=192.168.2.250 sport=51600 dport=20 packets=3 bytes=164 [ASSURED]
> mark=0 secmark=0 use=1
>
> * 192.168.1.150-> 192.168.1.70 [ nat ] 192.168.2.70 -> 192.168.2.50
> ftp works
> /proc/net/nf_conntrack :
> ipv4 2 tcp 6 431998 ESTABLISHED src=192.168.1.150
> dst=192.168.2.250 sport=41108 dport=21 packets=11 bytes=636
> src=192.168.2.50 dst=192.168.2.70 sport=21 dport=41108 packets=8
> bytes=880 [ASSURED] mark=0 secmark=0 use=2
> ipv4 2 tcp 6 118 TIME_WAIT src=192.168.2.50 dst=192.168.2.70
> sport=20 dport=35479 packets=5 bytes=334 src=192.168.1.150
> dst=192.168.2.250 sport=35479 dport=20 packets=3 bytes=164 [ASSURED]
> mark=0 secmark=0 use=1
>
> * 192.168.1.15 -> 192.168.1.70 [ nat ] 192.168.2.70 -> 192.168.2.50
> ftp works
> /proc/net/nf_conntrack :
> ipv4 2 tcp 6 118 TIME_WAIT src=192.168.2.50 dst=192.168.2.70
> sport=20 dport=46819 packets=5 bytes=334 src=192.168.1.15
> dst=192.168.2.250 sport=46819 dport=20 packets=3 bytes=164 [ASSURED]
> mark=0 secmark=0 use=1
> ipv4 2 tcp 6 431998 ESTABLISHED src=192.168.1.15
> dst=192.168.2.250 sport=44839 dport=21 packets=11 bytes=635
> src=192.168.2.50 dst=192.168.2.70 sport=21 dport=44839 packets=8
> bytes=880 [ASSURED] mark=0 secmark=0 use=2
>
> 2) with a bridge
> * 192.168.1.50 -> 192.168.1.70 [ nat ] 192.168.2.7 -> 192.168.2.50
> ftp doesn't work
> /proc/net/nf_conntrack :
> ipv4 2 tcp 6 431998 ESTABLISHED src=192.168.1.50
> dst=192.168.2.250 sport=56140 dport=21 packets=13 bytes=796
> src=192.168.2.50 dst=192.168.2.7 sport=21 dport=56140 packets=13
> bytes=1109 [ASSURED] mark=0 secmark=0 use=1
>
> * 192.168.1.50 -> 192.168.1.70 [ nat ] 192.168.2.70 -> 192.168.2.50
> ftp works
> /proc/net/nf_conntrack :
> ipv4 2 tcp 6 431997 ESTABLISHED src=192.168.1.50
> dst=192.168.2.250 sport=34334 dport=21 packets=11 bytes=635
> src=192.168.2.50 dst=192.168.2.70 sport=21 dport=34334 packets=8
> bytes=880 [ASSURED] mark=0 secmark=0 use=2
> ipv4 2 tcp 6 118 TIME_WAIT src=192.168.2.50 dst=192.168.2.70
> sport=20 dport=59124 packets=5 bytes=334 src=192.168.1.50
> dst=192.168.2.250 sport=59124 dport=20 packets=3 bytes=164 [ASSURED]
> mark=0 secmark=0 use=1
>
> * 192.168.1.5 -> 192.168.1.70 [ nat ] 192.168.2.7 -> 192.168.2.50
> ftp works
> /proc/net/nf_conntrack :
> ipv4 2 tcp 6 116 TIME_WAIT src=192.168.2.50 dst=192.168.2.7
> sport=20 dport=36148 packets=5 bytes=334 src=192.168.1.5
> dst=192.168.2.250 sport=36148 dport=20 packets=3 bytes=164 [ASSURED]
> mark=0 secmark=0 use=1
> ipv4 2 tcp 6 431996 ESTABLISHED src=192.168.1.5
> dst=192.168.2.250 sport=46925 dport=21 packets=11 bytes=633
> src=192.168.2.50 dst=192.168.2.7 sport=21 dport=46925 packets=8
> bytes=880 [ASSURED] mark=0 secmark=0 use=2
>
> * 192.168.1.5 -> 192.168.1.70 [ nat ] 192.168.2.70 -> 192.168.2.50
> ftp doesn't work
> /proc/net/nf_conntrack :
> ipv4 2 tcp 6 59 CLOSE_WAIT src=192.168.2.50 dst=192.168.2.70
> sport=20 dport=60875 packets=4 bytes=282 src=192.168.1.5
> dst=192.168.2.250 sport=60875 dport=20 packets=3 bytes=164 [ASSURED]
> mark=0 secmark=0 use=1
> ipv4 2 tcp 6 431999 ESTABLISHED src=192.168.1.5
> dst=192.168.2.250 sport=48877 dport=21 packets=12 bytes=687
> src=192.168.2.50 dst=192.168.2.70 sport=21 dport=48877 packets=9
> bytes=939 [ASSURED] mark=0 secmark=0 use=2
>
> * 192.168.1.150-> 192.168.1.70 [ nat ] 192.168.2.70 -> 192.168.2.50
> ftp doesn't work
> /proc/net/nf_conntrack :
> ipv4 2 tcp 6 431999 ESTABLISHED src=192.168.1.150
> dst=192.168.2.250 sport=33847 dport=21 packets=14 bytes=878
> src=192.168.2.50 dst=192.168.2.70 sport=21 dport=33847 packets=14
> bytes=1173 [ASSURED] mark=0 secmark=0 use=1
>
> * 192.168.1.15 -> 192.168.1.70 [ nat ] 192.168.2.70 -> 192.168.2.50
> ftp works
> /proc/net/nf_conntrack :
> ipv4 2 tcp 6 431998 ESTABLISHED src=192.168.1.15
> dst=192.168.2.250 sport=46792 dport=21 packets=11 bytes=633
> src=192.168.2.50 dst=192.168.2.70 sport=21 dport=46792 packets=8
> bytes=880 [ASSURED] mark=0 secmark=0 use=2
> ipv4 2 tcp 6 118 TIME_WAIT src=192.168.2.50 dst=192.168.2.70
> sport=20 dport=56576 packets=5 bytes=334 src=192.168.1.15
> dst=192.168.2.250 sport=56576 dport=20 packets=3 bytes=164 [ASSURED]
> mark=0 secmark=0 use=1
>
--
Damien Thébault
-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
