summaryrefslogtreecommitdiffstats
path: root/block/blk-map.c
diff options
context:
space:
mode:
authorJozsef Kadlecsik <kadlec@blackhole.kfki.hu>2009-11-06 00:43:42 -0800
committerDavid S. Miller <davem@davemloft.net>2009-11-06 00:43:42 -0800
commitf9dd09c7f7199685601d75882447a6598be8a3e0 (patch)
tree98ab4a75ec6c74cdb4aa807c491002ba33de56c5 /block/blk-map.c
parentf5209b4446d185cc95f46363f8043a743530c15a (diff)
downloadlinux-f9dd09c7f7199685601d75882447a6598be8a3e0.tar.gz
linux-f9dd09c7f7199685601d75882447a6598be8a3e0.tar.bz2
linux-f9dd09c7f7199685601d75882447a6598be8a3e0.zip
netfilter: nf_nat: fix NAT issue in 2.6.30.4+
Vitezslav Samel discovered that since 2.6.30.4+ active FTP can not work over NAT. The "cause" of the problem was a fix of unacknowledged data detection with NAT (commit a3a9f79e361e864f0e9d75ebe2a0cb43d17c4272). However, actually, that fix uncovered a long standing bug in TCP conntrack: when NAT was enabled, we simply updated the max of the right edge of the segments we have seen (td_end), by the offset NAT produced with changing IP/port in the data. However, we did not update the other parameter (td_maxend) which is affected by the NAT offset. Thus that could drift away from the correct value and thus resulted breaking active FTP. The patch below fixes the issue by *not* updating the conntrack parameters from NAT, but instead taking into account the NAT offsets in conntrack in a consistent way. (Updating from NAT would be more harder and expensive because it'd need to re-calculate parameters we already calculated in conntrack.) Signed-off-by: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu> Signed-off-by: Patrick McHardy <kaber@trash.net> Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'block/blk-map.c')
0 files changed, 0 insertions, 0 deletions