/* HINT: Search archives @ http://www.indyramp.com/masq/ before posting! */ Good day, Rok, On Sun, 17 Oct 1999, Rok Papez wrote: > I have a Linux server. The server has a modem it connects my private > LAN (192.168.1.x) to the internet thru IpMasquerading. > > I have recently upgraded the server from RedHat 5.2 (2.0.36 kernel) > to RedHat 6.0 (2.2.12 kernel). From upgrade on I experiance a problem that > *seems* to be related to masquerading. > > I open a few ftp connection to *one* ftp server. If files are small there is no > problem, but with larger files at one moment one of the transfers never > finishes (Netscape - same is with NcFTP - keeps it stuck at 100% and it never > finishes). After one tansfer never finishes, *no* transfer finishes. > If I stop all transfers and reconnect later, everything is OK, until another > transfers hangs at 100%. > > I didn't have this kind of problems with 2.0.36 kernel. > > Here is my setup: > - kernel 2.2.12 > - [/root]# rpm -qa | grep ipchains > ipchains-1.3.8-3 > - [/root]# cat /etc/rc.d/rc.masq > #!/bin/sh > echo "Setting up masquerading." > /sbin/modprobe ip_masq_ftp > /sbin/modprobe ip_masq_irc > /sbin/modprobe ip_masq_quake > /sbin/modprobe ip_masq_raudio > /sbin/modprobe ip_masq_cuseeme > /sbin/modprobe ip_masq_vdolive > /sbin/modprobe ip_masq_user.o > # Reset the rules! > /sbin/ipchains -F > /sbin/ipchains -P input ACCEPT > /sbin/ipchains -P output ACCEPT > /sbin/ipchains -P forward ACCEPT > /sbin/ipchains -P forward REJECT > /sbin/ipchains -A forward -s 192.168.1.0/255.255.255.0 -j MASQ I can't be sure, but I would guess that you're seeing a subtle problem with connection timeouts. In an ftp transfer, the control channel (always to port 21) is opened first to handle all of the login, and high level communication work. When actual data has to be transferred (either a directory listing or a file transfer), a second channel is opened. While a large file is being transferred, the data channel sits idle. If your file transfer takes longer than the tcp timeout on your masquerading box, that box removes the control channel from its list of open tcp connections. When the file transfer is complete, the ftp client attempts to handle some housekeeping chores over the control channel, but the masquerading box not longer has any record of how to talk over that channel. In short, even though the client and server both believe the control channel is open, the masquerading box refuses to masquerade that connection anymore. The solution is simple - increase the timeout on the masuqerading box. To increase the timeout to 8 hours (28800 seconds), use the following: ipchains -M -S 28800 0 0 Those still using ipfwadm need to use: ipfwadm -M -s 28800 0 0 instead. Unless someone believes there is still a specific kernel bug involved in this problem, I would suggest that this thread move to the ip-masq mailing list. Cheers, - Bill --------------------------------------------------------------------------- My desk has a security flaw. If I bang my forehead at it for two days continuously I can make a hole in it. Wuss, bang harder. -- Slashdot debate on a Unix security issue -------------------------------------------------------------------------- William Stearns ([EMAIL PROTECTED]). Mason, Buildkernel, named2hosts, and ipfwadm2ipchains are at: http://www.pobox.com/~wstearns/ _______________________________________________ Masq maillist - [EMAIL PROTECTED] Admin requests can be handled at http://www.indyramp.com/masq-list/ -- THIS INCLUDES UNSUBSCRIBING! or email to [EMAIL PROTECTED] PLEASE read the HOWTO and search the archives before posting. You can start your search at http://www.indyramp.com/masq/ Please keep general linux/unix/pc/internet questions off the list.
