Copyright (c) 1999,2000 WU-FTPD Development Group.
 All rights reserved.

 Portions Copyright (c) 1980, 1985, 1988, 1989, 1990, 1991, 1993, 1994
   The Regents of the University of California.
 Portions Copyright (c) 1993, 1994 Washington University in Saint Louis.
 Portions Copyright (c) 1996, 1998 Berkeley Software Design, Inc.
 Portions Copyright (c) 1989 Massachusetts Institute of Technology.
 Portions Copyright (c) 1998 Sendmail, Inc.
 Portions Copyright (c) 1983, 1995, 1996, 1997 Eric P.  Allman.
 Portions Copyright (c) 1997 Stan Barber.
 Portions Copyright (c) 1997 Kent Landfield.
 Portions Copyright (c) 1991, 1992, 1993, 1994, 1995, 1996, 1997
   Free Software Foundation, Inc.

 Use and distribution of this software and its source code are governed
 by the terms and conditions of the WU-FTPD Software License ("LICENSE").

 If you did not receive a copy of the license, it may be obtained online
 at http://www.wu-ftpd.org/license.html.


                Testing your FTP server using TELNET


Often testing an FTP server with a real client can hide problems with the
server.  I find it usefull to eliminate the quirks of the client software from
consideration by using Telnet instead.  The operations discussed in this
document are generally usable with all FTP servers.

Although you'll see the internals of an FTP session here, it is not my
intention to teach the entire protocol.  Refer to RFC 959 for a complete
discussion.



Using the system logs
---------------------
Many times, direct, by-hand testing is not needed.  If you enable logging
on the command line with the -l option, you can add the following line to
your ftpaccess to see most of the conversation in your system logs.  This
can often show you where the problem is occuring.  If not, it will at least
allow you to follow the same command sequence as the actual client, in case
the problem depends upon the specific commands issued.

 log commands real,guest,anonymous

Be warned, though, for a busy site logging all commands can make your
system logs amazingly large.



PASV downloads via telnet
-------------------------
When using PASV mode, data connections originate with the client.  This
makes testing quite a bit easier since you only need a telnet client and a
calculator.  (If you don't have a calculator handy, use your organic backup
system; it's slower and more error-prone, but almost everyone has one.)

Two or more telnet sessions are needed to completely test an FTP session.
I usually use multiple windows since they're easier to read, but for this
example, I'll use a single session.

First, open a telnet session to the FTP server and log in.  I'll make
believe I'm Netscape Navigator while I'm at it.

 $telnet ftp ftp
 Trying 205.133.13.13...
 Connected to ftp.vr.net.
 Escape character is '^]'.
 220 ftp.vr.net FTP server ready.
 USER anonymous
 331 Guest login ok, send your complete e-mail address as password.
 PASS mozilla@
 230 Guest login ok, access restrictions apply.
 SYST
 215 UNIX Type: L8
 TYPE I
 200 Type set to I.
 PASV
 227 Entering Passive Mode (205,133,13,13,21,169)
 NLST
 ^]

 telnet>
 [1]+  Stopped                 telnet ftp ftp

In this example, I'm using NLST.  You can use RETR to fetch a specific
file.  If you're just testing the ability to do PASV connections, NLST is
fine.  Break out of the current telnet session and start another.  You'll
need to read and interpret the 227 response.  The first four numbers are
the IP address you must connect to (usually the same as the FTP server's IP
address).  The next two are the port number.  You will need to do a little
math here.  In this case, calculate ((21 * 256) + 169) to get the port
number, 5545.  Open a session to that port.  Since there is already a
transfer pending the output will display and the connection close
automatically.

 $telnet ftp 5545
 Trying 205.133.13.13...
 Connected to ftp.vr.net.
 Escape character is '^]'.
 etc
 pub
 bin
 incoming
 .notar
 private
 dev
 Connection closed by foreign host.

Back to the originial telnet session.  Because this is being done on one
window, you won't see one detail: the 150 message appeared when the data
connection was openned and the 226 appreared when it completed.  For long
transfers, or when things go awry, this timing is appearent (sometimes
important); which is the reason I usually use two windows for this testing.

 $fg
 telnet ftp ftp

 150 Opening BINARY mode data connection for file list.
 226 Transfer complete.
 PASV
 227 Entering Passive Mode (205,133,13,13,58,225)
 LIST
 ^]

 telnet>
 [1]+  Stopped                 telnet ftp ftp

Since I used NLST earlier, and since most of the questions occur because of
'dir' and 'ls' issues (NLST and LIST), I'll do a LIST so you can see the
difference.  Back to the calculator for ((58 * 256) + 225).

 $telnet ftp 15073
 Trying 205.133.13.13...
 Connected to ftp.vr.net.
 Escape character is '^]'.
 total 8
 dr-xr-xr-x   8 root     root         1024 Feb 12 03:07 .
 dr-xr-xr-x   8 root     root         1024 Feb 12 03:07 ..
 ----------   1 root     root            0 Jun  9  1998 .notar
 d--x--x--x   3 root     root         1024 Sep 14 16:40 bin
 d--x--x--x   2 root     root         1024 Dec 24 16:31 dev
 d--x--x--x   2 root     root         1024 Dec 27 19:34 etc
 drwxrws-wx   2 vrnet    vrnet        1024 Oct  8 00:43 incoming
 drwxrws--t   7 vrnet    vrnet        1024 Feb  2 20:44 private
 drwxrwsr-t   4 vrnet    vrnet        1024 Aug 15  1998 pub
 Connection closed by foreign host.

Finally, back to the control session to close the FTP session.

 $fg
 telnet ftp ftp

 150 Opening BINARY mode data connection for /bin/ls.
 226 Transfer complete.
 QUIT
 221-You have transferred 0 bytes in 0 files.
 221-Total traffic for this session was 1146 bytes in 2 transfers.
 221-Thank you for using the FTP service on ftp.vr.net.
 221 Goodbye.
 Connection closed by foreign host.
 $



PASV uploads via telnet
-----------------------
Testing uploads (STOR command) using PASV mode via telnet is much like
testing downloads.  The only difference is that whatever you type into the
data connection telnet session is stored in the uploaded file.



PORT transfers via telnet and netcat
------------------------------------
PORT mode transfers require that you have a 'listener' running, waiting for
the FTP server.  The netcat utility is such a program.  For downloads, set
it to listen on a port and copy what it received to your screen or a file.
For uploads, give it a file to transmit.  You will need to know the IP
number and port number where netcat is waiting and you will need to supply
a PORT command instead of a PASV command so the server has this
information.  An example of a port command (for the PASV port used above),
and the server's response, would be:

 PORT 205,133,13,13,58,225
 200 PORT command successful.

If netcat were listening on TCP port 15073 and we issued the PORT command
instead of a PASV command, the results would be similar to the PASV
transfer.  I'll be honest, though, I don't even have netcat installed, so I
cannot show examples.  I've never needed to test PORT mode communications;
every problem I've ever needed to test was visible using PASV mode.

You are viewing proxied material from ftp.icm.edu.pl. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.