On Thu, 15 Sep 2005 16:04:07 -0400 (EDT)
der Mouse <mouse@Rodents.Montreal.QC.CA> wrote:

> I got a reply from Red Hat.  They say they "do not currently support
> commands from the epsv command set" and ask me to "[p]lease use
> commands from the classical passive command set only".  I sent back a
> reply pointing out that their server responds to EPSV with something
> that looks like a perfectly good EPSV response, and they may want to
> change that if they don't really support EPSV.  No response to that
> yet.
> 
> They do acknowledge that this "is not a great response", adding "but it
> is all we have right now", so there is at least some awareness that the
> current situation is..suboptimal.

Indeed we would expect the server to either reply with 500 or 502 when
EPSV is issued, in which case our client degrades to PASV if I remember,
and it seemed appropriate for most servers so far (and I believe it's
better to start off with the extended version, which is a gain when
used with servers supporting it, IMO).

When writing mmftpd I remember finding the RFC unclear about this but
needing to immediately bind(2) and listen(2) upon EPASV/LPSV/PASV to
cope with the variety of clients out there...

One could also assume that the client already has its port ready when
issueing a PORT/LPRT/EPRT if I remember (although I remember waiting to
connect until the transfer request is made in this case, for
compatibility with some clients).  Traditionally, bind(2) would decide
which port to assign, in fact, and the reply needs the port number...

This is not always true nowadays since choosing a random port within a
range is often done to work with various proxy configurations, and to
minimize the possibilities of attackers knowing which ports to connect
to to render transfers difficult (despite the fact that it can be bound
to an interface and drop connections of unexpected addresses), but I'm
pretty sure that many FTP servers and clients are still getting the
ports ready very fast.  When using a random port number, the best way to
know if it's already bound is to bind(2) anyway :)

So I suspect it to be some kind of vsftpd compatibility bug...  If this
was made from a security standpoint, it could be trading voluntarily
some compatibility for being able to have a listening port for the
shortest time possible, I guess, it's always possible

Matt
-- 
Note: Please only reply on the list, other mail is blocked by default.
Private messages from your address can be allowed by first asking.