Subject: Re: kern/7368: ipnat not rewriting PORT command 100% of time
To: None <firstname.lastname@example.org,>
From: Andrew Brown <email@example.com>
Date: 04/17/1999 01:28:43
>> Subject: Re: kern/7368: ipnat not rewriting PORT command 100% of time
>I've been successfully using IP-Filter 3.2.11-beta5 on a FreeBSD-3.0
>machine for a NAT and FTP proxy with several different Macintosh and
>Windows FTP clients, including some rather dumb and old ones, and it
>works flawlessly with this check still enabled. Blindly hacking this
>check out seems like a very wrong thing to do in any case. Is there any
>proof (tcpdump trace, etc.) that this change is really necessary?
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
as i said before (at least, i think i did), ftp clients that don't
send the crlf in the same packet are dumb, but we can accomodate that,
the only thing that will now lose (as a result of this hack) would be
an ftp client that didn't send the entire port command in one packet.
so they're broken through nat as well right now, would still broken
(in a different way) with this patch, but imho, they deserve to lose
anyway if they're that broken.
|-----< "CODE WARRIOR" >-----|
firstname.lastname@example.org * "ah! i see you have the internet
email@example.com (Andrew Brown) that goes *ping*!"
firstname.lastname@example.org * "information is power -- share the wealth."