Re: Problem Sending File to Vendor

[Scott Klement <sk@xxxxxxxxxxxxxxxx>]

Hi Mike,

Interesting...   I see in your code that you're doing an FTP_chdir(), 
but it's not in the log you're posting at all!  Is it possible that you 
omitted that command when you generated the log? Because I can't come up 
with any other explanation. as to why that would be missing.  'chdir' is 
sent entirely within the command channel, and you obviously have a 
command channel running.  Anyway, I'll assume this is a red herring...

FTP works by first establishing a "command connection" in which it sends 
commands (the log you sent is a log of the command connection.) Then, 
any command that requires a large amount of data to be transferred (i.e. 
a DIR, PUT or GET command) will open a separate "data channel", one for 
each file transfer.  The difference between "active" (or "normal") FTP 
and passive is the way that the data channel is established.

We can see from your log that you are using the active method, because 
we see this command:
PORT 192,168,0,200,167,239

This is sent by the FTP client (in this case, FTPAPI) to the FTP server 
to tell it where to make the connection for a data channel. The numbers 
are a string of 6 bytes, in decimal format, separated by commas.  The 
first 4 numbers are the IP address to connect to, the last two are the 
high/low bytes of the port number (which is a 16-bit unsigned integer).  
So FTPAPI is asking the FTP server to make a connection back to it at 
192.168.0.200 on port 42991.

So here's my guess of the problem:  192.168.0.200 is a private IP 
address.  There's no way a server that's outside of your NAT gateway can 
possibly connect to that.  This NORMALLY isn't a problem, because a NAT 
gateway will watch all outgoing traffic on port 21 and look for the FTP 
PORT command.  When it sees it, it'll replace the private address 
(192.168.0.200 in this case) with whatever the public IP address is.   
So the problem would be solved, except... you are not using port 21.  So 
your NAT gateway is not searching for the FTP PORT command...   and 
therefore, the private address gets transmitted as-is.   The server 
tries to connect back to the private address, which doesn't work, and so 
your connection hangs until the server's attempt times out.

There are two possible solutions:

1) Switch to using PASSIVE mode.  In passive mode the server will send 
the string of 6 bytes (instead of the client) and the client (FTPAPI) 
will attempt to make an outbound connection.   This will probably work, 
since now it's no longer _your_ NAT gateway that matters, it's the 
server's NAT gateway, which has probably been set up properly (knock on 
wood) for port 2033, since the server folk probably do this a lot with 
other customers.   Or, of course, it's possible that the server isn't 
running NAT at all.  Either way, passive solves the problem.

-or-

2) Reconfigure your NAT gateway to use port 2033 in addition to port 21 
for FTP.    Not all NAT gateways allow this, but some do... if yours 
does, this could be a solution.

I would personally recommend #1, as it's much easier.

Good luck!


On 7/31/2013 10:06 PM, Mike Wills wrote:
> I am using FTP API to send out a file to a vendor's FTP server. They
> are using a non-standard port of 2033. When I run my program, I get
> the following log:
>
> 1-: FTPAPI version 3.0beta1 released on 2010-02-21
> 99-: Connecting to host xxx.xxx.com at address xxx.xxx.xxx.xxx using
>    port 2033.
> 0: 220 Server ready for new user.
> 0: > USER xxxxxxxxx
> 0: 331 Password required for xxxxxxxxx.
> 0: > PASS **********
> 0: 230 User xxxxxxxx logged in.
> 0: > TYPE I
> 0: 200 Type set to I.
> 0: > PORT 192,168,0,200,167,239
>
> At first I thought I was getting hung up on sending the file. Now
> don't think that is the case. Here is my code:
> https://gist.github.com/MikeWills/d004f1d89f57cfa8de9e
>
> Any thoughts as to what might be wrong? The admin said that they allow
> all outgoing ports. Do I need to switch to passive?
>
> --
> Mike Wills
> http://mikewills.me
> -----------------------------------------------------------------------
> This is the FTPAPI mailing list.  To unsubscribe, please go to:
> http://www.scottklement.com/mailman/listinfo/ftpapi
> -----------------------------------------------------------------------

-----------------------------------------------------------------------
This is the FTPAPI mailing list.  To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------