Subject: [fwtk-users] RE: problem with STAT on ftp

From: "Barreira, Fernando [IT]" <[email-masked]>
Date: Mon, 13 May 2002 15:07:16 -0400

i tried it against a UNIX ftp server and see the same problem.

> ----------
> From: 	Ted Keller[SMTP:[email-masked]]
> Sent: 	Monday, May 13, 2002 3:04 PM
> To: 	Barreira, Fernando [IT]
> Cc: 	fwtk-users
> Subject: 	Re: [fwtk-users] problem with STAT on ftp
> 
> Fernando,
> 
> If you do this against a non-windows server  - does it work?  stat seems
> to be supported through ftp-gw - at least to wu-ftpd daemons.
> 
> ted keller
> 
> 
> On Mon, 13 May 2002, Barreira, Fernando [IT] wrote:
> 
> > i have a windows ftp program that is ued as follows..
> >
> > It is a program called REALWATCH and is used to poll a server for
> specific
> > types of files and download them when they appear in the directory.
> >
> >  It is a custom application by the company that provides the service and
> > uses the library CSFTP32.OCX from Catalyst.com in their SocketTools
> package.
> >
> > This library appears to want to do the STAT every time a file is
> retrieved
> > as a 'feature'.  My guess is that they can then call a function like,
> >  'filesize=get("server","filename");' in their code and know how large
> the
> > file is going to be so they can put up a percent complete message.
> >
> > This isn't a feature that it appears they can disable.  They have
> > rewritten the application a number of times to try to avoid it, but the
> > underlying
> > library won't remove the requirement for STAT.
> >
> > ========================here is the
> problem===============================
> >
> >  Ok, here is the problem.  Command line "get" works file
> > FTP makes two connections to the proxy server.  One over port 21, which
> > is the control connection.  And another (the data channel) that is
> > negotiated depending on if it is passive or active mode.
> >
> > Over the control connection, commands get sent to tell the remote ftp
> > server what it is you want to do.
> >
> > These are commands like:
> >
> > RETR
> > LIST
> > SYST
> > PWD
> > CWD
> > PASV
> > TYPE
> > USER
> > PASS
> > DIR
> > ...and the one that is killing us...STAT.
> >
> > You can NOT send these commands using an FTP client.  They are lower
> > level protocol commands.  The only way to manually send them is with a
> RAW
> > (cooked) TCP connection to port 21 to manually manipulate the control
> > channel.  That is why I was using the telnet program to get more
> > specific debug data.
> >
> > When you do a GET on a file using your FTP program, the ftp program
> > translates this into a series of commands.  In a simple FTP client, it
> > may just send the RETR command to retrieve the file.  In a more complex
> FTP
> > program, it may set the binary/ascii TYPE and STAT the file to find out
> > how large it is so it can put up a progress meter, see the rights, etc.
> >
> > When you are doing your GET, you are doing just that - only sending a
> > RETR command to get the file.  You are absolutely right, this works just
> > fine.
> >
> > HOWEVER, not all FTP clients do this.  Some of them, and in this case
> > some FTP processes embedded in proprietary applications that use FTP as
> > their
> > transport, send the additional commands, like STAT.
> >
> > What is happening is that when the client issues the STAT command, the
> > proxy, or the downstream firewall, is killing the control channel.  This
> > should NOT happen.  What should happen is either a message is sent back
> > that says that the command is not supported, or the response should be
> > returned to the user.
> >
> > This is what this incident is about - getting the proxy server to behave
> > in the appropriate manner and either denying the STAT command or sending
> > the response, but NOT destroying the control channel.  The destruction
> of
> > the control channel breaks the whole FTP process and causes the program
> to
> > stop functioning.
> >
> > Everything that is being done in this transfer is fully RFC compliant
> > for a FTP transfer.  Nothing out of the ordinary is being done.  The
> issue
> > is
> > just that the STAT command destroys the connection.
> >
> >
> >
> > ---
> > You are currently subscribed to fwtk-users as: [email-masked]
> > To unsubscribe send a blank email to
> [email-masked]
> >
> 

---
You are currently subscribed to fwtk-users as: [email-masked]
To unsubscribe send a blank email to [email-masked]