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

From: "Barreira, Fernando [IT]" <[email-masked]>
Date: Mon, 13 May 2002 10:52:36 -0400

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]

---

From: Ted Keller <[email-masked]>
Date: Mon, 13 May 2002 15:04:28 -0400 (EDT)

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:

> You are currently subscribed to fwtk-users as: [email-masked]

---

---

From: "Michael R. Eckhoff" <[email-masked]>
Date: Mon, 13 May 2002 15:47:16 -0500

Ted,

I have been working with Fernando on this so I'm going 
to go ahead and reply.  I don't think he knows I'm 
also on this list.

I see this problem with all FTP destinations.

Here is a copy of the control stream to the NT Server:
220 
USER [email-masked]
331-(----GATEWAY CONNECTED TO destination.host----)
331-(220 destination Microsoft FTP Service (Version 
5.0).)
331 Password required for user.
PASS secretpassword
230-This is a private FTP site.
230-All Access Is monitored and logged.
230-
230-
230-Please Disconnect
230 User user logged in.
SYST
215 Windows_NT version 5.0
PWD
257 "/" is current directory.
TYPE I
200 Type set to I.
CWD /12345/foo
250 CWD command successful.
PWD
257 "/12345/foo" is current directory.
PWD
257 "/12345/foo" is current directory.
TYPE A
200 Type set to A.
PORT 10,11,12,30,9,215
200 PORT command successful.
LIST
150 Opening ASCII mode data connection for /bin/ls.
226 Transfer complete.
TYPE I
200 Type set to I.
STAT /12345/foo/test.txt
530 Peer has closed connection
PORT 10,11,12,30,9,216
QUIT

...notice the 530 immediately after the STAT.  The 
PORT command following the STAT is getting ready for 
the RETR.  It then figures out that the channel is 
dead and issues a QUIT.

Here is one to ftp.cdrom.com:

220 
USER [email-masked]
331-(----GATEWAY CONNECTED TO ftp.cdrom.com----)
331-(220 wcarchive.cdrom.com FTP server (Version DG-
4.1.75 1020766287) ready.)
331 Guest login ok, send your email address as 
password.
PASS [email-masked]
230-Welcome to ftp.cdrom.com, a service of Digital 
River, Inc.
230 Guest login ok, access restrictions apply.
SYST
215 UNIX Type: L8 Version: BSD-199506
PWD
257 "/" is current directory.
TYPE I
200 Type set to I.
PWD
257 "/" is current directory.
PORT 10,11,12,30,9,216
200 PORT command successful.
STAT .
530 Peer has closed connection

Notice, again, the as soon as the STAT is issued, the 
connection closes.  This is immediate, there is no 
delay between the stat being issued and the 530 being 
returned.

Hope this helps.

Mike

---

---

From: Ted Keller <[email-masked]>
Date: Mon, 13 May 2002 17:58:11 -0400 (EDT)

Michael,

Just in case I'm crazy (as many people have implied) would you try this
with ftp.bfg.com.  This is a wu-ftpd server.  When I try there - things
seem to work fine - or I am seeing something different than you.

ted keller

---

---

From: Rick Murphy <[email-masked]>
Date: Mon, 13 May 2002 18:25:31 -0400

At 10:52 AM 5/13/02 -0400, Barreira, Fernando [IT] wrote:
>is just that the STAT command destroys the connection.

Have a look at how ftp-gw handles STAT commands - look at the "ops[]" 
structure in the ftp-gw source:

         "stat",         OP_CONN,        /* overload */  cmd_abor,

A "stat" command is only valid if connected, and when recognized, it calls 
'cmd_abor' to abort your connection.
Changing this to
         "stat",         OP_CONN,        0,
would allow your application to send the "STAT" command.
Interestingly enough, this alias of STAT to ABOR has been in ftp-gw for 
quite a while. I'll bet that the Gauntlet ftp-gw has the same code.

I think this was coded this way because ftp-gw wasn't prepared to handle 
the STAT command while a data transfer is in progress. If so, coding a 
function to reject the STAT under those conditions would have made more sense.
         -Rick

---