The bad news is that I believe that the PASV detection in the module is
broken (and thus the binding doesn't take place). Active ftp gets
detected properly.
Here's a patch (hand pulled out of a larger patch of mine) which should
fix things.
diff -ru linux-2.2.11/net/ipv4/ip_fw.c linux/net/ipv4/ip_fw.c
--- linux-2.2.11/net/ipv4/ip_fw.c Mon Aug 9 15:05:05 1999
+++ linux/net/ipv4/ip_fw.c Wed Aug 11 11:49:25 1999
@@ -101,18 +192,26 @@
skb = *skb_p;
iph = skb->nh.iph;
th = (struct tcphdr *)&(((char *)iph)[iph->ihl*4]);
- data = (char *)&th[1];
+ data = (char *)th + sizeof(struct tcphdr);
- data_limit = skb->h.raw + skb->len - 18;
- if (skb->len >= 6 && (memcmp(data, "PASV\r\n", 6) == 0 ||
memcmp(data, "pasv\r\n", 6) == 0))
- ms->app_data = &masq_ftp_pasv;
+ data_limit = skb->h.raw + skb->len;
while (data < data_limit)
{
+ if ((memcmp(data, "PASV\r\n", 6) == 0 || memcmp(data,
"pasv\r\n", 6) == 0)) {
+ app_data->look_for_passive = 1;
+ return 0;
+ }
+
if (memcmp(data,"PORT ",5) && memcmp(data,"port ",5))
{
data ++;
It may not be perfect, but I've been using it for a couple of months
without problem.
-kf
P.S. The larger patch dynamically creates forwarding rules for ftp. With
the patch in place, you only have to masquerade outgoing port 21 instead
of having to create an outgoing port 20 (for active) and outgoing
1024-4999 (for passive). See http://pebbles.net/~kfrench/linux/ for the
whole thing. I can feel the kernel gods cringing right now, heh.
On Sun, 17 Oct 1999, William Stearns wrote:
> 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.
> >
> 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
-
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/