Re: FTPAPI question

[Scott Klement <klemscot@xxxxxxxxxxxx>]

Sender: Scott Klement <klemscot@xxxxxxxxxxxx>


Hi Steve,

I see that you've signed up to the FTPAPI mailing list, I'm going to CC:
my reply to that list so others can benefit from any knowledge, and maybe
also give their input.

> I downloaded and compiled your FTPAPI utility in order to test it for
> possible use in an application.  My AS/400 (model 170, running V5R1) is
> located on my home network behind a Linksys router.  On the router, I
> currently have ports 20 - 23 forwarded to the AS/400's IP address behind the
> router (10.0.0.170).

So it appears that you're using NAT to translate 10.0.0.x addresses to
your external one?   Do you also have a firewall running?

FTP is an unusual protocol in that it uses more than one connection to
transfer data.  An FTP client first connects on port 21 (the "FTP control
port").  This port is used to establish credentials (userid &
password), to send commands back & forth, and to receive messages
indicating success or failure.  (The messages you see in the job log are
all messages on the control connection...)

Then, for each file or directory listing transferred, the client & server
will negotiate (by sending messages on the control connection) an address
and port for a "data connection."

In standard FTP (i.e. non-passive) the client sends a message that amounts
to "connect back to me at address x.x.x.x port x"  that's the PORT command
you see in the job log.  and then the server initates a connection to that
port.

In passive FTP the server sends a message that says much the same thing
"connect back to me at address x.x.x.x port x" and then the client makes
the connection to that port.

This is why you see so many questions about making FTP work through
firewalls and NAT on midrange-l.  Because it can use any open port, and
because NAT actually changes the address in the packets, in standard mode
the messages sent on the control connection won't match the actual address
that the server needs to connect to!    However, most NAT implementations
are smart enough to scour each packet on port 21 looking for the "PORT"
command, and they change it appropritately.   I don't know if that's true
of the Linksys router you're using, I've never used any Linksys equipment.
But it's true of Netgear, newer Cisco, and also software NAT in FreeBSD.
I assume that Linksys works pretty much the same way.

Whew.  I'm probably explaining too much.  Running FTPAPI in passive mode
should solve the NAT issue, if it's an issue.

Now, if you have a firewall running, that's another obstacle.  Since the
FTP server or client picks any available port number for the secondary
(data) connection, a strict firewall will often cause problems with FTP.
The usual solution is to allow any "outbound" connection, and then to
use passive mode, since with passive mode both the control connection and
the data connection will be outgoing.

Telling your router to forward ports 20-23 from the external address to
your iSeries won't help, since the FTP server never connects to you on
those ports -- though you do want to forward port 21 if you need to make
your iSeries' FTP *SERVER* available from outside...   but FTPAPI is not a
server, so that's not really relevant.

> Test 1:
> When I tried to call your TESTGET program to get the fips.exe file from the
> ftp2.freebsd.org site, it creates an empty fips.exe file in the root folder
> of the IFS and fails (see joblog information below).  For problem
> determination I set the DMZ host on the router as the IP address of the
> AS/400 (thinking that it could be related to being behind the router and not
> knowing which ports need to be opened), but I got the same error again when
> I called TESTGET (again, see joblog information below).

The relevant message from your job log:
   PORT 10,0,0,170,186,54
   DSPLY  A connection with a remote socket was reset by that

See, you're telling it to connect back to you on address 10.0.0.170, and
port 47670.  (186 * 256 + 54 = 47460).   When it receives this request,
it's simply dropping your connection.   I have a feeling that it's seeing
that the address in this PORT command doesn't match the address it
believes that it's connected to, and then is simply dumping you --
since otherwise it might be a security breach.

Like I said, NAT should be translating that message to the external
address (though that wouldn't be visible in the job log) but if your
router doesn't do that, you can work around the problem by using passive
mode.  Just do:

      callp ftp_passiv(*ON)

You can either do it at the start of the program, or anytime before your
first FTP_GET/FTP_PUT/FTP_DIR, etc.

>
> Test 2:
> I copied your TESTGET program and changed it so that I could test it
> locally, behind the router.  I successfully copied a file from a share on my
> W2K server under /QNTC/W2KSERVER/... to the /home/SJL folder in the IFS and
> it displays the "Success" message.  I verified that the file was
> successfully copied to the IFS folder.
>
> Test 3:
> As a final test, I copied your TESTGET program again and changed it so that
> I could test it locally, behind the router, to copy a file from my local
> Windows FTP server (10.0.0.30, port 22).  I successfully copied a file from
> my FTP server running on my W2K server to the /home/SJL folder in the IFS
> and it displays the "Success" message.  I verified that this file was also
> successfully copied to the IFS.

These tests look successful, so I won't try to address them :)

-----------------------------------------------------------------------
This is the FTPAPI mailing list.  To unsubsribe from the list send mail
to majordomo@xxxxxxxxxxxxx with the body: unsubscribe ftpapi mymailaddr
-----------------------------------------------------------------------