tag 441471 + upstream
forwarded 441471 bugs.proftpd.org
thanks
http://bugs.proftpd.org/attachment.cgi?id=2639&action=view and also
http://bugs.proftpd.org/show_bug.cgi?id=2863
to be checked
On Sun, Sep 09, 2007 at 07:58:29PM -0700, Steve Langasek wrote:
> 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.
>
--
Francesco P. Lovergine
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
