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

Re: Problem Sending File to Vendor



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
-----------------------------------------------------------------------