delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/2009/03/04/19:28:46

X-Recipient: archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status: No, hits=2.0 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_33,SARE_MSGID_LONG40,SPF_PASS
X-Spam-Check-By: sourceware.org
MIME-Version: 1.0
Date: Wed, 4 Mar 2009 18:28:26 -0600
Message-ID: <b60e0a230903041628q58d248e3td6706fce537c67af@mail.gmail.com>
Subject: Active FTP Issue with inetutils 1.5
From: "Curt Gran (crazykz)" <crazyst AT gmail DOT com>
To: cygwin AT cygwin DOT com
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

Hi,

I apologize if this should be in the apps list and not here but it
seems like it might get more views here.  Let me preface this by
saying that I have done some research and sniffing of this 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 question.

Synopsis:
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.5.4 fixes this issue since I can't load the system with 1.5.4. (not
my system but I'll try to get someone to do it if someone thinks this
has been fixed or if someone tests on a newer version to let me know
it's fixed)

When I make an active FTP connection to a server running 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 it opens the data connection and completes.  When I sniff this
I can see that the client sends the PORT command to the server.  The
server is suppose to open a connection back to the client at the IP
and PORT specified in the data 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 I can see 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 seem to allow this.  I can't find any
documentation to support a 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.

I'm sorry I haven't tested this with the latest version.  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.

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/

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019