Date: Thu, 9 Nov 2000 21:38:42 -0800 From: "Crist J . Clark" <cjclark@reflexnet.net> To: David Greenman <dg@root.com> Cc: Dag-Erling Smorgrav <des@ofug.org>, Terry Lambert <tlambert@primenet.com>, chat@FreeBSD.ORG Subject: Re: ftp.freebsd.org b0rked? Message-ID: <20001109213842.U75251@149.211.6.64.reflexcom.com> In-Reply-To: <200011092225.OAA08474@implode.root.com>; from dg@root.com on Thu, Nov 09, 2000 at 02:25:28PM -0800 References: <20001109104110.A91691@149.211.6.64.reflexcom.com> <200011092225.OAA08474@implode.root.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Nov 09, 2000 at 02:25:28PM -0800, David Greenman wrote: > >On Tue, Oct 31, 2000 at 10:11:38AM +0100, Dag-Erling Smorgrav wrote: > >> Terry Lambert <tlambert@primenet.com> writes: > >> > I have seen this with particular firewalls (I think CheckPoint > >> > was one), where they attempt to do state tracking on FTP, and > >> > fail to be able to do that and do address rewriting at the same > >> > time. > >> > >> Not relevant. I'm using real IP addresses and the connection is > >> dropped immediately after the PASS command, no matter what password I > >> actually send. There is a FW1 upstream, but it's supposed to let all > >> traffic to and from my subnet through untouched. > >> > >> David - is there any way we can try to debug this? I guess the first > >> thing to try is if it's specific to dgftpd - do you have another site > >> that runs dgftpd I can test against? > > > >Better late than never? We had a problem with our FW-1 after an > >"upgrade." Here is a source that sums up the different approaches to > >the issue, > > > > http://www.securityportal.com/topnews/weekly/checkpoint20000918.html > > > >Scroll down to the "Multiple Problems with FTP After Upgrading" > >section. HTH. > > I don't see how dg-ftpd is doing anything wrong. It always replies with > CRLF terminated lines on the command channel as RFC-959 requires. ...so I > don't think this is the cause. > The problem appears to be a real bug in the checkpoint firewall code. When I was watching FW-1 reset connections, I was thinking the same thing. From the best I could tell, FW-1 would reset the connection if the FTP data portion _of any single packet_ did not end in a CRLF. I would get most of the "230" lines until one line was broken between packets... then FW-1 would send TCP RSTs each way. To me, that's gotta be broken behavior. Why should the application layer, FTP, care how the data is broken up at the transport layer, TCP? -- Crist J. Clark cjclark@alum.mit.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20001109213842.U75251>