Messages in this thread | | | Date | Sun, 17 Oct 1999 18:09:05 -0400 (EDT) | From | William Stearns <> | Subject | Re: FTP Masquerading - unable to finish ftp transfer |
| |
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 (wstearns@pobox.com). Mason, Buildkernel, named2hosts, and ipfwadm2ipchains are at: http://www.pobox.com/~wstearns/ --------------------------------------------------------------------------
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |