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/