Package: proftpd
Version: 1.3.0-24
Severity: important
Tags: ipv6
I've run into an issue where, only when using ipv6, apt's ftp download
method fails to download Packages files from my proftpd-based ftp server.
The reason it fails is as follows:
- because the connection is IPv6, the client issues an EPSV command
- proftpd opens a socket in response, and sends the port number to the
client
- the client connects to the socket
- the client then issues a RETR command for a non-existent file (I have no
Packages.bz2 on this server)
- the server sends back a 550 No such file or directory
- the client closes the data socket
- the server does NOT close the data socket, or check that the client has
done so
- the client issues a second EPSV request
- the server returns the same port number as before, believing that its
existing fd is still valid
- the client makes a second connection to the server
- the server never calls accept() for this second connection
- the client issues a second RETR command
- the server sends the file back to the client using sendfile() on the
previously opened socket, which fails at the TCP level with a RST (but the
sendfile() call appears to succeed)
- the client sits around waiting for a file it will never receive
So the difference between the behavior of PASV and EPSV seems to be at lines
3012-3016 of modules/mod_core.c:core_pasv():
/* If we already have a passive listen data connection open, kill it. */
if (session.d) {
pr_inet_close(session.d->pool, session.d);
session.d = NULL;
}
There is no corresponding code in the core_epsv() implementation, resulting
in this problem that nothing checks for the validity of the socket before
reusing it, and no code exists to accept a second connection on an existing
socket.
The following naive patch addresses the problem for me, but is probably not
a correct solution wrt the rest of the code (e.g., there are other possible
unhandled errors in cmd_pre_xfer), so I have not tagged this bug 'patch'.
--- /tmp/oXwn00RfyV/proftpd-dfsg-1.3.0/modules/mod_xfer.c 2007-04-24
05:39:22.000000000 -0700
+++ /tmp/38tFBn2aXl/proftpd-dfsg-1.3.0/modules/mod_xfer.c 2007-09-09
19:24:39.000000000 -0700
@@ -1570,6 +1570,7 @@
if (!dir ||
!dir_check(cmd->tmp_pool, cmd->argv[0], cmd->group, dir, NULL)) {
pr_response_add_err(R_550, "%s: %s", cmd->arg, strerror(errno));
+ pr_data_close(FALSE);
return ERROR(cmd);
}
I have also confirmed this behavior with other ipv6-capable ftp clients, so
it doesn't appear to be a question of a buggy client.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
[EMAIL PROTECTED] http://www.debian.org/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
