"Ryan P. Matijcio" wrote: > > Well changing the masq timeout values doesn't to have done anything.
When having ftp problems, it's time to dust off telnet and brush up on your ftp commands. You can simulate the ftp client and get some feedback and see what's working and what's not. You may need to determine if the command connection is timing out and if it still works when you have the problem. It'd help if you had some cut and paste output of the exact problem and a repeatable test case. I have an oxygen distro I can test from. > Unfortunately I can't seem to find a status screen that will tell me the > current timeout values so I can verify they have been changed. I couldn't find how to get it to tell you the values. If you set it, you might try a brute force grep through the proc directory, with care :), and seach for those values. I found somewhere that the -M -S tcp tcpfin udp style command defaults to 15min, 2min, 5min. Are your transferring many small files in rapid succession or many big files? How big? > But as > far as the seawall configuration goes, they are set and the firewall > script has been restarted. From the testing I've been doing the same > problem is apparent. Again please post a repeatable test case and description if at all possible. > One strange thing I've noticed is that doing a netstat -M doesn't make > any output at all when I know it should. Weird. Not even after getting on a masq'd internal computer and surfing the net? Really? > Anyways, if anyone has any suggestions I'd love to hear 'em. > > I've started to notice FTP problems with an Oxygen firewall I have > running. The problem occurs on both unix and NT systems located > behind the firewall. I have found that all ftp transfers be they > incoming or outgoing eventually freeze. Although it appears that > NT -> NT transfers are more stable, they too freeze after about > 800-1500 files have been transferred. After a certain number of files? Repeatable? Are you doing PORT or PASV transfers? Check that you're not running out of masq ports. I think there's 4096 ports available on a LEAF box for masqing outgoing connections. The ftpd, if serving incoming PASV request from behind a masq'ing firewall, will only have a certain number of ports dedicated to the data transfer connection. If you use too many of them in rapid succession, then some of them may not be completely "unESTABLISHED", iirc they may go into some time-out wait state. I had this exact problem when I allowed less than 100 ports for incoming ftpd data connections to my masqd ftpd. I also recall that the newer oxygen handled the reuse of ports much better and that the problem may have gone away. I think it was part of the kernel upgrade in the new distro. So maybe lowering your tcpfin or examining what's going on in netstat -an. > One thing I've noticed that I think is interesting to note is that this > problem does not occur when using LeechFTP. Force leech ftp into debugging mode and check what's it's doing against the ftpd server's syslog to determine what commands, if any, it's sending on the command channel during a download. Or do you mean it's sending NOOPs when it's idle? Also a tcpdump of the LeechFTP commands might be interesting if you can't get the info from the syslog. >I believe this because > LeechFTP tends to keep sending commands to keep the connection active. > That's why I was wondering if it could have something to do with the > masq timeouts. _______________________________________________ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
