On Fri, 26 Jun 2009, Patrick McHardy wrote:
Krzysztof Oledzki wrote:
On Fri, 26 Jun 2009, Patrick McHardy wrote:
Krzysztof Oledzki wrote:
This patch kills long living ftp transfers from one of my hosts. I'm not
able to transfer large files if it takes more than
net.netfilter.nf_conntrack_tcp_timeout_unacknowledged seconds.
After logging to the remote host and issuing any FTP command (ls or
put/get for example) tuple's timeout is reduced. Additional commands are
able to bump it but only upto
net.netfilter.nf_conntrack_tcp_timeout_unacknowledged.
It seems that IP_CT_TCP_FLAG_DATA_UNACKNOWLEDGED flag is never cleard.
Tested on 2.6.28.10.
Interesting, are you using the FTP NAT helper?
Actually, yes :)
I'm guessing there is some bad interaction between sequence number
adjustments when changing the packet sizes and sequence number
tracking in conntrack.
Very likely, src ip and nat ip have different lengths.
I think I know what the problem is. We update the highest seen
sequence number when adjusting packet lengths in NAT, but only
upwards:
void nf_conntrack_tcp_update(const struct sk_buff *skb,
unsigned int dataoff,
struct nf_conn *ct,
int dir)
{
...
if (after(end, ct->proto.tcp.seen[dir].td_end))
ct->proto.tcp.seen[dir].td_end = end;
So I'm guessing in your case, the NAT address is shorter than
the original one.
Exactly. Just checked and this problem does not exist when
strlen(src_ip) <= strlen(nat_ip)
This patch changes TCP conntrack to update the highest sequence
number when the old number matches the new one + the size offset,
so it should effectively update it after NAT whenever the packet
caused an update before NAT.
Please test whether this patch fixes the problem.
The patch fixes my problem. Thank you.
Tested-by: Krzysztof Piotr Oledzki <ole@xxxxxx>
Best regards,
Krzysztof Olędzki
