Subject: Re: "PASV"?

From: [email-masked] (Mukesh Kacker)
Date: Wed, 24 Jan 1996 09:56:44 -0800

> 
> > Does anyone know what the point is on the PASV command to the server?
> 
> Ftp-Data connections are then initiated 'the other way around' then normal.
> This can be usefull if the ftp client is inside a firewall, and can't
> accept new connections coming from the outside.
> 

I will clarify and get into the some more gory details and hope stop
some rumors about Solaris :-)

The "normal/default" way the FTP server operates is that the clients
first open a "control" TCP connections on which all your ftp commands
are sent. Each command that results in some I/O to/from the file
system (like ls, dir, get, put) use a separate ftp data connections that
is set up and then torn down for each command. This data connections
is initiated from the server ("Active" open in TCP speak) and the server
knows which port to connect() to through the PORT command.

There is another more obscure way traditional BSD ftp clients can be
used to do a 3-way transfer. [ client on machine X connects to machine A and B
and then transfers files between A and B]. THe "proxy" command on your
"ftp" command ( which you may not have ever used :-)) does that. To accomplish
that PASV command was invented where one end of server actively opens the
connection while the other end listens (PASiVe open in TCP speak).

For various reasons I will not get into, Firewall folks do not like
ability of externally intiated connections to be able to connect to
services inside the protected zones. So RFC 1579 "Firewall Friendly FTP"
by Steve Bellovin advocated the use of PASV command even for normal
two way ftp data connections.

> > What does it do in all the gory details?  It seems that my server
> > is hanging when this command is being sent to my ftpd.  (What's
> > sending, why Netscape, of course).  This is unfortunately the only
> > browser that I have found that sends that command to my ftpd, and it
> > is the only browser that does not like ftp to my server.
> 

As far as I know only Netscape client implements RFC1579 "Firewall Friendly
FTP". However in doing that a combination of bugs in all BSD derived FTP
daemons (that might translate to all ftpd daemons :-)) and some
(broken?) Firewall/packet filter policies.

Certain Firewall/packet-filters only allow the "normal/default" FTP data
setup for their ftp clients where the incoming FTP data connection is from
ftp-data port (port 20) and the other end in some TCP "anonymous" port range.
The RFC 1579 advocated PASV command FTP data connections have "anonymous" port
range on both ends of the TCP connections. They are silently dropped. So
ironically these Firewall/packet-filter policies are not quite in sync with
the "Firewall Friendly FTP" RFC 1579.

The bug in BSD derived implementations of FTP servers is that once put in
passive mode, the server waits forever for an incoming data connections which
presumably is never made or dropped by certain (broken?) firewalls. This is
manifested as hanging ftpd processes that stay forever on your server
holding resources and eventually eat up the swap and affect performance and
force you to take notice :-)

For the stock SOlaris ftpd we fixed the problem in SOlaris 2.5. We released
a patch for SOlaris 2.4.

A lot of our customers do use the more feature rich Wu-ftpd. So we protoyped
our fixes on Wu-ftpd too and communicated them to the developers of Wu-ftpd.
I am not sure if those (or any other fix to that problem) has shown up in
the "official release" of Wu-ftpd are not.

Some folks on this list have done some ad-hoc fixes too for the same
problem where they timeout the accept() call and I have seen those
curculated. [ The way we have fixed is different and we have fixed certain
other scenarios which can generate hanging ftpd processes too which also
involve turning on TCP keepalives ]

If the "release" of Wu-ftpd does not have the fixes, then the FAQ should
contain atleast some version of the fix.

> In case you're running on Solaris...
> 
> >From the FAQ :
> 
> --------------------------------------------------------------------
> 
>         9. Normal ftp clients work, Netscape ftp's fail. So, passive
>             mode doesn't work.
> 
>             Apparantly ftpd needs write permission on ~ftp/dev/tcp in
>             order to operate correctly in passive mode (Solaris).
>          
>             Fix: 
> 
> cd ~ftp/dev      
> chgrp ftp tcp 
> chmod 775 tcp    
>         Thanks to Simon Rakov ([email-masked]) for
>             this one.

I am not sure about this information in the FAQ. We have not heard of this
problem reported from any customer. I will file this as a
bug and have someone investigate if this is true or not. If this is
true, it should be well documented.

Whatever this issue is, it is orthogonal to the "hanging ftpd" processes
problem seen on various ftpd installations.

-Mukesh Kacker
 Internet Engineering