Subject: Re: kern/7368: ipnat not rewriting PORT command 100% of time
To: Andrew Brown <firstname.lastname@example.org>
From: Greg A. Woods <email@example.com>
Date: 04/17/1999 12:48:48
[ On Saturday, April 17, 1999 at 01:28:43 (-0400), Andrew Brown wrote: ]
> Subject: Re: kern/7368: ipnat not rewriting PORT command 100% of time
> yep. don't have one here, but i can get one. mklinux (perhaps not
> current) has an ftp client (standard ftp client, not ncftp) needs it.
> for some reason the ftp client sends the port command in one packet
> and the crlf in the next. without this *GROSS* little *HACK*, ti
> doesn't work in active mode. passive works, of course, and ncftp
> works (since it's more well behaved), but without this patch it is
> indeed broken.
What I don't like about the hack is that it seems to assume there's a
CR/LF in all cases and if indeed the CR/LF arrives in a separate packet
then it doesn't seem obvious to me what happens to it. I can't claim
I've really taken the time to understand that bit of the code though....
Is there any way you can test against 3.2.11beta6? (I can provide a
FreeBSD kernel with it already integrated, though it would take me quite
a bit more work to build a NetBSD kernel with it, esp. a non 1.3.3
What's surprising to me is that so far as I can find yours is the first
ever complaint about this problem -- at least with enough detail to
identify it uniquely. There are (it seems) several Linux users on the
ip-filter mailing list, but I didn't find any reference to such a
problem in the list archives (not that the search there is of much use
or that everyone includes as much detail in their reports!).
I suppose the thing to do would be to ask on the ip-filter mailing list,
but at the moment I'm not on it and only read it rarely via the archives.
Greg A. Woods
+1 416 218-0098 VE3TCP <firstname.lastname@example.org> <robohack!woods>
Planix, Inc. <email@example.com>; Secrets of the Weird <firstname.lastname@example.org>