Timothy A. Musson wrote:

>
> The Passive FTP stuff that Theo Borm was talking about is where the 
> FTP Server does not make a back-connection to the client. This mode of 
> FTP works fine with older and/or simpler firewalls, but many large FTP 
> sites do not allow that type of connection due to performance issues 
> (all traffic happens over port 20, as you said earlier; meaning that 
> only one client can connect at a time). Your FTP client likely 
> attempted passive mode by default and got rejected, but you can go 
> ahead and try to force it anyway (with -p ?).
>
Hi Timothy

Now you have me confused.....

- Why there should be performance issues using passive mode FTP?

- Can you give me an example of a "large" site (e.g. "ftp.netbsd.org?)
  with up to date FTP server software that does *not* allow passive mode 
FTP?

- I was under the impression that most modern browsers' integrated FTP
  client use passive mode FTP? are you suggesting the oposite?

- As far as I know Apple's (see original post) command line FTP client
  defaults to non-passive mode, NetBSD's command line FTP client
  defaults to passive mode.

- Why should it be impossible to have more than one passive mode
  FTP session? IP connections are only fully charactarized by a combination
  of BOTH server and client IP-address-port pairs.

e.g: Take a NAT/PAT router with external IP address 10.0.0.10, through
which two passive mode FTP sessions are open simultaneously to
a server with IP address 192.168.0.100.
The router connects from 10.0.0.10:5000 to server 192.168.0.100:20
AND another session connects from 10.0.0.10:5001 to 192.168.0.100:20
these can easily be distinguished between at /both/ ends because the
/combination/ of source and destination IP addresses AND source
/and/ destination ports are unique.
Any NAT/PAT router will handle this without problem - regardless
of wether the sessions originated from the same machine or from two
entirely different machines hidden behind the NAT/PAT router. This
is the NAT/PAT routers' most basic job - it does so for every mail
server you connect to, for every HTTP server you connect to and
for /many/ other protocols - to do so it does not even have to know
*anything* about the protocols and ports that are used for these
protocols.

Active mode FTP is different (as are some other protocols).

In case (active mode FTP) the server opens back a connection, with a new
IP-addresses-and-port-numbers combination, the NAT/PAT router has to
figure out which FTP session (with a different IP-addresses-and-port-
numbers combination) wants that data in order to be able to correctly route
the packets. Many strategies exist for this situation: The router can
(rather simplistically) choose to route the data to the most recently 
started
session, the one with the most recent activity on the control channel or by
inspecting the data in the PORT command. Most cheap router bricks
will only allow a limited number of simultaneous active mode FTP
connections per client because they lack resources to keep track of more.

HTTP is in many respects much like passive mode FTP. I've never heard
of performance issues surrounding HTTP servers related to being limited
to "passive mode" data transfers; I've never heard people complain that
this "passive mode"-only behaviour of HTTP was a design mistake. I do
however know about a lot of qualms people have with active mode FTP,
and some people actually think that "active mode" FTP was a mistake
to begin with. Actually, the only good thing about active mode FTP that
I can think about now is (mentioned by David Laight already) that you can
theoretically have the data sent to a different machine, though I wonder
how many people use that feature.

with kind regards,

Theo