--bjuZg6miEcdLYP6q
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On 2005.09.15 06:21:41 -0400, der Mouse wrote:
| 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.
|=20
| 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.
|=20
| Investigating with tcpdump, I see the protocol going thus:
|=20
| ....login and CWD and suchlike...
| Send> SIZE FC4-i386-disc1.iso
| Recv< 213 665434112
| Send> EPSV
| Recv< 229 Entering Extended Passive Mode (|||11931|)
|=20
| At this point the client tries to connect to port 11931, but the SYN
| segment elicits an RST in response.  It then continues with
|=20
| 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
|=20
| 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.)
|=20
| 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.
|=20
| 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.
|=20
| Or has this changed since 2.0?

No, I'm running -current and it has the same problem.

		-- Rui Paulo

--bjuZg6miEcdLYP6q
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (NetBSD)

iD8DBQFDKWNiZPqyxs9FH4QRAjR+AKCCoys7IkkLD7Zc/d945euXa/ygbgCgmuS4
gkc6gRnIgDspmPlPtBKS3A0=
=fTmP
-----END PGP SIGNATURE-----

--bjuZg6miEcdLYP6q--