[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug-inetutils] Active FTP Issue with Inetutils 1.5-4

From: Curt Gran (crazykz)
Subject: [bug-inetutils] Active FTP Issue with Inetutils 1.5-4
Date: Thu, 5 Mar 2009 14:56:30 -0600


I posted this to the cygwin list but I'm thinking this is probably the
better place to ask this.  Let me preface this by saying that I have
done some research and sniffing of this issue from both sides on a few
machines (all windows 32 or 64 bit) and have seen the same thing on
them all.  I have also done a little reading in the RFC's on FTP.  I
can't find an explanation for this and that is why I'm posting this

Active FTP data connections are NOT being sourced from port 20 as
stated in the RFC.

I saw a post for a fix in 1.5-4 that stated this:  * fixed bug in ftpd
that prevented large file transfers  with recent 1.5.x cygwin kernels.
Reported by antony baxter.   (worked around by disabling MMAP and
limiting buffer sizes  to 4k).

I don't know if the issue I'm seeing is related and I don't know if
1.6 fixes this issue since cygwin hasn't ported 1.6 yet.

Here's what I'm seeing.  When I make an active FTP connection to a
server running inetutils ftpd (in cygwin) it does the usual port 21
control channel without an issue.  This allows small amounts of data
across it without the need for a separate data connection.  However
when I do a large file transfer or a large ls -al command the clients
sends the port command and the server opens a data connection back to
the client.  When I sniff this I can see that the client sends the
PORT command to the server and I see the server create the data
connection back to the client.  This is all normal for an active FTP

Normally the server opens a connection back to the client at the IP
and PORT specified by the PORT command in the data portion of the
packet from the client.  The connection that the server makes back to
the client, according to the RFC, is suppose to be sourced at port 20.
 However the issue I'm seeing is that the server sources the
connection at the next high order port back to the client.  Most
firewalls seem to allow this however some firewalls/access
lists/proxies don't allow this.  I can't find any documentation to
support an FTP server being able to source the data connection on
active FTP at any other port besides 20.

This is easy to test.  Use an FTP client that can make an active FTP
connection.  Do a packet capture and watch to see what port the remote
side (i.e server) uses when connecting back to you.  Keep in mind if
you're going through a proxy/firewall it may change the port,
especially if you're NAT'ing.  It's best to do this test with no
firewall in the way.  If the source port is not 20 then that is the
issue I'm seeing.  If it is port 20 then please let me know what
version of inetutils and cygwin you are running.

This behavior changed between inetutils 1.3-2 and 1.5-4.  We've been
using 1.3-2 for years which has worked fine and sources the data
connection at port 20 like you would expect.  The new 1.5-4 causes
issues for us and our customers.

I'm sorry I haven't tested this with the latest version outside of
cygwin (inetutils 1.6).  Maybe this is an easy answer however if
someone knows for sure I would love to be able to get some feedback on
this issue.

As a small aside I did an internet search looking to see if I could
find other people that have found this issue in other places.  We can
see that Sonic Firewalls seem to "proxy" FTP connections and have the
same result where you see an FTP data connection sourced from a port
other than 20.  I also found an article written about FTP that was
interesting and brought up the topic of coders not using port 20 as
the source port because it's a privileged port and it requires root
access to open a connection on it.


Quote:  "Now, this inbound connection should, according to the RFC,
come from TCP port 20 - but lazy programmers being what they are,
combined with the fact that using a privileged port like that requires
root access, means that very few FTP servers actually do that."

Now I can't find anywhere in RFC959 for FTP where it says the source
port has to be 20 however RFC 1700 states that the ftp-data port is
port 20.

Can anyone shed some light on this?  Are we headed down a path where
access-lists will now start blocking ftp data connections because they
are being sourced from port 20 like in the past?  Has anyone else seen
this and considered it an issue?  Is this a bug?  Is this a new
feature with no RFC?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]