Your message dated Fri, 4 Apr 2008 14:38:05 +0200
with message-id <[EMAIL PROTECTED]>
and subject line This seems now better handled.
has caused the Debian Bug report #441471,
regarding proftpd: fails to cleanup sockets on ENOENT
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [EMAIL PROTECTED]
immediately.)
--
441471: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=441471
Debian Bug Tracking System
Contact [EMAIL PROTECTED] with problems
--- Begin Message ---
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/
--- End Message ---
--- Begin Message ---
Version: 1.3.1-1
Both core_pasv() and core_epasv() now kill the pending data connection,
so this should be fixed. I cannot easily verify on an IPv6 net, so
if you could confirm this it would be great, thanks; else feel free
to reopen the bug.
--
Francesco P. Lovergine
--- End Message ---
