Martin, I think I am onto something here. Is it possible for the FTP server to switch IP addresses mid stream? By that I mean between files. Without NAT would the client be happy about it? In my last email, I think the dropped packet has a source IP which is different from that in /proc/net/ip_conntrack. I think that would certainly fool the NATing. I have captured some data from another session using PORT mode which seems to illustrate the point.
ip_conntrack reports EXPECTING: proto=6 src=203.2.75.213 dst=203.164.4.37 sport=0 dport=2060 setup by the PORT command I think? /var/log/messages reports Feb 20 13:45:26 multimedia kernel: IN=eth1 OUT= MAC=00:04:e2:10:72:2a:00:03:e3:31:b9:8c:08:00 SRC=203.2.75.28 DST=203.164.4.37 LEN=60 TOS=0x00 PREC=0x00 TTL=58 ID=34460 DF PROTO=TCP SPT=18 DPT=2060 WINDOW=32120 RES=0x00 SYN URGP=0 This implies to me, I was expecting a response on 203.2.75.213 and actually got one on 203.2.75.28 This is further supported by the two packets dropped in an earlier unrelated FTP session shown below. If I read this right I have the same MAC address reported as 203.2.75.29 and 203.2.75.28 an easy thing to do, but confusing for NAT. Feb 20 13:34:13 multimedia kernel: IN=eth1 OUT= MAC=00:04:e2:10:72:2a:00:03:e3:31:b9:8c:08:00 SRC=203.2.75.29 DST=203.164.4.37 LEN=101 TOS=0x00 PREC=0x00 TTL=58 ID=42379 DF PROTO=TCP SPT=19 DPT=1821 WINDOW=32120 RES=0x00 ACK PSH URGP=0 Feb 20 13:45:26 multimedia kernel: IN=eth1 OUT= MAC=00:04:e2:10:72:2a:00:03:e3:31:b9:8c:08:00 SRC=203.2.75.28 DST=203.164.4.37 LEN=60 TOS=0x00 PREC=0x00 TTL=58 ID=34460 DF PROTO=TCP SPT=18 DPT=2060 WINDOW=32120 RES=0x00 SYN URGP=0 If I am correct, can IPTABLES be setup to handle this type of situation? Kind Regards Steve McAllister -----Original Message----- From: Martin Josefsson [mailto:[EMAIL PROTECTED]] Sent: Wednesday, 20 February 2002 6:53 AM To: Steve McAllister Cc: [EMAIL PROTECTED] Subject: Re: Batching of FTP Transfers Fails On Wed, 20 Feb 2002, Steve McAllister wrote: > The kernel is 2.4.7-10 and the masquerading is done via IPTABLES 1.2.4-2. I > Module Size Used by > ip_conntrack_ftp 4080 0 (unused) > ip_nat_ftp 3680 0 (unused) I've seen problems like this but I can't remember which kernelversions. I know there was a problem with the rewriting of the ACK number in packets which have been modified, it sometimes calculated the wrong number and the transfer dies. This has been fixed in later kernels, please upgrade your kernel to 2.4.17 or something a lot more recent then that ancient 2.4.7 you are running. /Martin Never argue with an idiot. They drag you down to their level, then beat you with experience.
