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.
Ron----- Original Message ----- From: "Patrick McHardy" <kaber@xxxxxxxxx>
To: "Ron Lai" <ronlai@xxxxxxxxxxxxxxx>Cc: <netfilter@xxxxxxxxxxxxxxx>; "Netfilter Development Mailinglist" <netfilter-devel@xxxxxxxxxxxxxxx>
Sent: Tuesday, October 23, 2007 6:17 AM Subject: Re: Problems with nf_nat_ftp.ko and nf_conntrack_ftp.ko in 2.6.22.6
Please send bugreports to netfilter-devel. Ron Lai wrote:Hi all,My 2.6.22.6 Linux box is acting as a NAT device. I found that a NATted FTP client is having problem using active mode to connect to a outside FTP server. (Passive mode works fine.)correctly modified by the Linux box to use the converted NAT address. However, the confirmation from the server never makes it to the client and the client just keeps retransmitting the PORT command packet.From the trace I could see that the PORT command from the FTP client isDo you mean it never makes it to the FTP client or to the machine where the client is running?The interesting part is that active mode can work if the length of the actual IP address of the client is the same as the length of the converted NAT address. It looks like if there is no TCP sequence number modification by the Linux box, the FTP connection can work properly in active mode. I am suspecting that there may a problem in the TCP sequence number tracking in the kernel modules.The same settings work fine when I try with Linux 2.6.15 loading ip_nat_ftp.ko and ip_conntrack_ftp.ko. Did I miss anything in configuring the Linux 2.6.22.6 box?Works fine here. Please post the dump, ideally from a box in the middle. - To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo@xxxxxxxxxxxxxxxMore majordomo info at http://vger.kernel.org/majordomo-info.html
Attachment:
ftp_test.pcap
Description: Binary data
