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.