Subject: FTP EPSV and data connections
To: None <tech-net@netbsd.org>
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
List: tech-net
Date: 09/15/2005 06:21:41
As of 2.0, and dating back at least as far as 1.4T, our FTP client does
something interesting when using EPSV: it tries to open the data
connection, in the TCP sense, immediately upon getting the EPSV
response.

This works fine with our ftpd, of course, and RFC 2428 contains
language that seems to imply it's not incorrect behaviour (that the
server is required to already be listening by the time the response is
sent).  However, it breaks with the FTP daemon on
download.fedora.redhat.com (or at least one of them - that name has
four addresses) and possibly others - the symptom is that I can't
download with "ftp download.fedora.redhat.com:/pub/....", getting "550
Permission denied." and then a lockup.

Investigating with tcpdump, I see the protocol going thus:

....login and CWD and suchlike...
Send> SIZE FC4-i386-disc1.iso
Recv< 213 665434112
Send> EPSV
Recv< 229 Entering Extended Passive Mode (|||11931|)

At this point the client tries to connect to port 11931, but the SYN
segment elicits an RST in response.  It then continues with

Send> EPRT |1|216.46.5.7|55193|
Recv< 550 Permission denied.
Send> PORT 216,46,5,7,215,153
Recv< 550 Permission denied.
Send> RETR FC4-i386-disc1.iso

At this point the server goes catatonic.  As I read the protocol, it
should establish a data connection on the default ports; while I don't
really expect it to do that these days, it should at least return an
error on the RETR.  (I suspect it is *now* waiting for a connection on
port 11931.)

Even if the server really is supposed to have a listen pending right
from EPSV time, I wonder if we may want to have the FTP client tolerate
servers that behave this way by trying the data connection again when a
transfer command is given if the EPSV succeeds but the connection is
refused.

I've written to ftp@redhat.com about this (no response yet, but as it's
been only a few hours, that's no surprise), but it seems that our FTP
client could handle things better too.

Or has this changed since 2.0?

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B