Re: Problem Sending File to Vendor

[Mike Wills <mike@xxxxxxxxxxxx>]

It was passive mode... thanks for the help in confirming what I had a
feeling was the issue.
--
Mike Wills
http://mikewills.me


On Thu, Aug 1, 2013 at 11:39 AM, Mike Wills <mike@xxxxxxxxxxxx> wrote:
> I haven't tried passive yet, but I will tonight. FTP is one of those
> services that I have a hard time wrapping my head around how it all
> works. That is why I came to the hive mind instead of slamming my head
> against the wall more trying to figure out why it hangs.
> --
> Mike Wills
> http://mikewills.me
>
>
> On Thu, Aug 1, 2013 at 11:28 AM, Scott Klement <sk@xxxxxxxxxxxxxxxx> wrote:
>> 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
-----------------------------------------------------------------------