[ 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
kernel.)

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      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>