theo borm wrote:
> 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.....

Well, that's not surprising considering that I was in a hurry and put down some half-remembered facts without double-checking them. After googling a bit:
 
> - Why there should be performance issues using passive mode FTP?

There probably shouldn't. I was under the impression that it caused more forking, but after looking at detailed descriptions of behavior and thinking about it, I don't know why that would be true. The problems I have had in the past may have been caused by FTP servers who did not wish to open high ports, rather than being worried about performance.
 
> - 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?

No, although I'm sure I've had the problem in the past. See previous fuzzy memories.
 
> - I was under the impression that most modern browsers' integrated FTP
>  client use passive mode FTP? are you suggesting the oposite?

Nope.
 
> - 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.

I wondered why you seemed to assume he was using Safari. I assume you had off-list communication? In any case, I'm sure you are correct.
 
> - 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.

That was just complete idiocy on my part. Sorry for the confusion and waste of bandwidth. Concerning all of these points: I should have stopped after "turn on connection tracking". :)
 
> 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

Yep, it's easy to allow outgoing connection requests and the corresponding requested incoming traffic.

> 
> Active mode FTP is different (as are some other protocols).
> 
> In case (active mode FTP) the server opens back a connection, with a new
<...snip...>

I hopefully conveyed the same message.

> 
> 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

The only arguments I've heard are for pre-forking children vs. threading or forking as each client connects. I think the argument could also be applied to FTP, but I'm not sure how active or passive modes would affect the outcome. I don't have time to think about it right now...

> 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

The behavior of active FTP has always confused me, so I know I wish that it hadn't been implemented ;)

> 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
> 

Thanks for not letting me get away with being sloppy.

-Tim