MIME-Version: 1.0
Date: Mon, 9 Mar 2009 09:29:35 -0500
Message-ID: <b60e0a230903090729g46ab28aej64a12fa87e513db2@mail.gmail.com>
Subject: UPDATE: Active FTP Issue with inetutils 1.5
From: "Curt Gran (crazykz)" <crazyst AT gmail DOT com>
To: cygwin AT cygwin DOT com
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com

Hi,

I did some more research this week reading though RFC959 about FTP and
have determined that the active data connection initiated from the
server must be port 20 if your FTP daemon is running on port 21.  The
RFC refers to the control port as "L".  Later in the document L is
stated as equal to 21.  The data connection is to be initiated at L-1
or port 20 if you're running the daemon on port 21.

Here is the response I received from Sergey, one of the inetutils
developers, about this issue:
>> However I'm hoping you can help me with understanding why this seems
>> to have changed.  We use to use 1.3-2 on our systems and that version
>> did source from port 20.  That behavior has changed in 1.5 and is now
>> sourcing from a high ordered port.  Do you know if this was done on
>> purpose or if it's a bug?

>Thanks for drawing my attention to this.  Indeed, ftpd.c as of version
>1.3.2 explicitly set data source port to be control port - 1 (which
>yielded 20 in most cases).  After analyzing our CVS history, I
>discovered that this assignment disappeared on Jul 13, 2000.  The commit
>on that day (see [1] for details) added the standalone daemon feature to
>ftpd, and judging by the changeset, the loss of data source port
>assignment was not intentional.  It seems rather to be some kind of
>copy-n-paste error.
>
>Since this was the historical ftpd behavior, I will restore it.  In the
>meantime, please apply the attached patch and let me know if it works
>for you.
>
>Regards,
>Sergey
>
>[1] http://cvs.savannah.gnu.org/viewvc/inetutils/ftpd/ftpd.c?root=inetutils&r1=1.33&r2=1.34
>
>
>Attached Diff
>Index: ftpd/ftpd.c
>===================================================================
>RCS file: /cvsroot/inetutils/inetutils/ftpd/ftpd.c,v
>retrieving revision 1.64
>diff -p -u -r1.64 ftpd.c
>--- ftpd/ftpd.c	27 Dec 2008 20:35:56 -0000	1.64
>+++ ftpd/ftpd.c	9 Mar 2009 11:34:09 -0000
>@@ -1045,6 +1045,7 @@ getdatasock (const char *mode)
>   /* anchor socket to avoid multi-homing problems */
>   data_source.sin_family = AF_INET;
>   data_source.sin_addr = ctrl_addr.sin_addr;
>+  data_source.sin_port = htons (ntohs (ctrl_addr.sin_port) - 1);
>   for (tries = 1;; tries++)
>     {
>       if (bind (s, (struct sockaddr *) &data_source,
>

So it seems that this will be fixed going forward.  I'm not sure how
inetutils gets ported to cygwin, or if it's even a port for that
matter, but I'm hoping that someone will be able to update cygwin with
the latest inetutils once this fix has been applied.

Could someone help me understand how we might be able to get this fix
into cygwin or when it could be available for download?

Thanks,
Curt

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/