Martin, Thanks for your reply. I have now moved on but made no progress on the underlying problem.
Changes from last mail. Jamie Pratt wrote: >>Not sure if this will work, but try putting this at the top of your script (Not sure if it will fix things, but it works >>for me, and you seem to have similar rules and modules goin... >>(Also, make sure you unload all the modules before running your script again so they start "fresh") >># Load ftp modules for PORT style FTP transfers: >> modprobe ip_conntrack_ftp >> modprobe ip_nat_ftp No change. An lsmod still shows these modules as unused. Upgraded the kernel to 2.4.9-21. A number of other upgrades none related to IPTABLES. Removed the NEW parameter from the INPUT rule (gaping security hole) The status of the problem is now: The problem of the packets being dropped and FTP disabled without the NEW parameter seems to have disappeared with the exception of: All goes well, until FTP stalls, then about 2 minutes after the stall I get the following packet dropped. Feb 20 10:08:03 multimedia kernel: IN=eth1 OUT= MAC=00:04:e2:10:72:2a:00:03:e3:31:b9:8c:08:00 SRC=203.2.75.5 DST=203.164.4.37 LEN=101 TOS=0x00 PREC=0x00 TTL=58 ID=60623 DF PROTO=TCP SPT=19 DPT=1299 WINDOW=32120 RES=0x00 ACK PSH URGP=0 Since this is an ACK packet, it makes me think you are on the right track. Could it be a timing issue? Is the ACK packet above the one FTP was waiting for all along? Has IPTABLES closed the connection before the packet arrives. The Redhat Network now reports my system as completely up to date, with no outstanding errata. Is 2.4.9-21 relatively recent? Do you have any further ideas? 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.
