I want to write a CLLE Program to transfer Files from the IFS to a Webserver.
The Webserver is registered in the Hosttable from the Iseries.
(commandline: CFGTCP -> Option 10 -> Scroll to the Webserver IP)
Current CLLE Program: (only the ftp-access)
PGM
OVRDBF FILE(INPUT) TOFILE(CMDDTAR7_2/US9FIP) OVRSCOPE(*JOB)
OVRDBF FILE(OUTPUT) TOFILE(CMDDTAR7_2/US9FOP) +
OVRSCOPE(*JOB)
FTP RMTSYS('10.1.2.99')
ENDPGM
After i call my Program i get some results in a PF-File.
The Results are in German but i translated shortly for you.
The Connection is unavalable to 10.1.2.99 on Port 21. Try it again later.
[...]
My Question at the end.
Do you have some solutions for me to transfer xml files to my Webserver from the iseries?
You're writing about a web server and you want to transfer files by ftp. Perhaps you're mixing up protocols here. I'll concentrate to resolve your apparent ftp connection problem.
Seems that the destination host 10.1.2.99 doesn't accept connections on Port 21.
Please make sure, there's no firewall or other stuff blocking your request to the destination host. Moreover, on the host 10.1.2.99 try telnet 10.1.2.99 ftp or ftp 10.1.2.99 in a command window, depending on OS and installed components.
Before automating, just test manually if you can successfully connect and log in via standard command line: ftp 10.1.2.99.
Transferring data by FTP is just fine in a local LAN. Beware that any data including username and password will be transferred in clear text and thus can be possibly read by others as the intended hosts.
Following up to your comment: Actually there are many possibilities to copy files. If you're running a recent version of IBM i, I'd opt for using scp. It's encrypted and thus safe for running outside of local LANs. Great to automate by utilizing Key-Authentication instead of passwords. And many web hosting companies offer scp/sftp access.
Related
Im trying to download a file from a FTP server using active mode.However,it looks like my connection just"expire" or something each time.First,I open a port on my computer using netcat,ex:
nc -vv -l -p 62077
this will listen on port 62077 on my computer.Then,I open another netcat windows,log in to the FTP link using port 21,and once im in the directory where the file I want is in,I do
PORT (my IP separated by , ),(242,125(wich equals to port 62077)\r\n
However,after I enter this command,nothing happen for about 10-15 seconds,and the netcat just quit without saying anything.Nothing happen either on the netcat window that is listening on port 62077.It does that everytime,I dont know what I am doing wrong.I did the same thing with Filezilla(in active mode) and examinated the commands with wireshark,I do the exact same command as Filezilla,however filezilla will be able to retrieve the file while netcat wont.I want to retrieve it with netcat and I dont know what im doing wrong.I am using Windows 10.
thank you!
After you have established your listening nc socket, and after you have sent the USER, PASS, and PORT commands, you then need to trigger the file transfer to that listening socket using e.g.:
RETR /path/to/file/to/download
on the control connection. (Unless you actually are already doing this, but didn't mention it in the post?)
Also, just to note: you mention using something like this:
PORT 1,2,3,4,(242,125)\r\n
Right? Those parentheses might also be an issue. Instead, you might try:
PORT 1,2,3,4,242,125\r\n
without any parentheses.
Now, depending on the IP address you sent (hopefully not a private network address), the data transfer may still not happen, due to firewalls/routers/NAT on the client side of things. Given that your Filezilla download of the same file works, I suspect that those firewall/router/NAT issues may not apply.
Hope this helps!
I am using a call to ftp.exe to upload file to a FTP Server.
This program is running since many years and uploads to number of servers, so far without problems.
After one of the receiver servers has been updated, uploads are no longer possible.
This is the command sequence:
open ftp.xxx.de
<user>
<pw>
>230 User logged in, proceed
cd upload
bin
put <filename>
and in response to this the server replies:
501 PORT IP is not the same as 10.100.244.5
150 File Status okay, about to open Connection
That is it, after this the connection is stuck and gets closed after a certain timeout period.
Funny enough, a google search for "PORT IP is not the same as" return exactly one result, which explains that the IP seen by the server is different from the one expected.
Also, when using WinSCP, FileZilla or other FTP utility programs, the connection has no problem and does transfer files just fine.
So, why does this appear and how to solve it?
The ftp.exe uses an old-fashioned active mode command PORT, which requires the client to specify its IP address to which the FTP servers needs to connect back to open a data transfer connection.
If your are behind a firewall or a NAT, the client may not know its external IP address and uses its local network address. This causes troubles. Either the server fails to connect back as it obviously cannot connect to the client's local network. Or the server rejects the PORT command straight away, if the specified IP address does not match the IP address, from which the FTP client connects to the server. This is a security measure as the difference may indicate a man-in-the-middle attack. Your server does the validation. Some servers might be configured to ignore the IP address specified in the PORT command and connect to a known IP address of the client.
Another way to solve this is, if the firewall/NAT can inspect the FTP traffic and seamlessly modify the IP address in the PORT command. This is obviously not happening.
You do not get the problem with WinSCP or FileZilla, as these clients default to the passive FTP mode, which does not have the problem. Also in the active mode these clients can be configured to use the external IP address. FileZilla also supports the modern EPRT command, that does not need to specify the IP address at all (the server uses the known IP address of the client).
See my article about active/passive FTP mode for details.
I do not think there's any way to make it working with the Windows ftp.exe. It neither supports the passive mode, nor can be configured to use the external IP address, nor supports the EPRT command.
So unless you can configure the FTP server not to do the check and connect to the known IP address of the client or configure your firewall/NAT to modify the IP address in the PORT command, you have to use another FTP client.
As you know that WinSCP works, see the guide for converting the Windows ftp.exe script to WinSCP script.
(I'm the author of WinSCP)
i have a big problem. I need tranfer a lot of files by a server to another server, but the second server isnt a local server. If i tranfer by a local server i cant 100mbs but if i send for another server out the speed is 2mbs. my network is 1gbs. I use a command line 7z.
If your servers are (as you wrote) on the same network and connected through the same line you are most likely to have a network connection problem.
I've often seen that the duplex settings of network cards are not set up correctly which leads to a lot of collisions.
Check your network card settings and try to force for example 100mbps full duplex.
I work for a company where this happens daily when trying to connect IBM network cards with Cisco switches. Have a look here how to set up duplex settings: https://superuser.com/questions/86581/how-do-you-check-the-current-duplex-value-of-a-network-card-set-to-auto-negotiat.
If this doesn´t help you might be better off asking at superuser.com
I'm the part time FTP server administrator (with no real full-time admin). We currently only allow ACTV mode connections. Some of our clients have had issues with this but for the most part they've been ok using ACTV. For the few who aren't, we've been able to push the data over to their servers from ours.
there is one client in particular however who is currently having trouble. He is using file-zilla and issuing a PORT command.
First, does using the PORT command imply that you are in ACTV mode?
Second is there a way in FileZilla to explicitly change to ACTV mode?
Thanks for the help,
_Ramy
Active mode requires the PORT command. PORT is what tells the server where to connect to on the client in order to open the data channel.
Active FTP breaks when the client is behind NAT, hence Passive is the preferred default in most situations where FTP is used. It is strongly preferable to not use FTP and switch to SFTP.
When trying to receive a (large, approx. 100MB) file using an FTP adapter in BizTalk 2006, we run into the following problem, which causes the file to be processed over and over again.
Retrieving the file succeeds; it is placed into the MessageBox and processed properly
When the FTP adapter issues the DELE statement, it never reaches the FTP server the file is on (we have verified this by taking a look at the FTP server's logs)
there are no signs of timeouts on the FTP server; the FTP server log does not mention a timeout occurring
After the interval time set on the adapter expires, the FTP server will still find the large file that we have already processed in the previous run, because the DELE statement failed
The event log in BizTalk states that ‘The connection to the FTP server was broken prematurely’. That is why we think there is a timeout issue.
We have seen that retrieval of the file takes around 35 minutes. The FTP server timeout is set to 1 hour. no problems there I guess.
Then we found the following article: http://www.ncftp.com/ncftpd/doc/misc/ftp_and_firewalls.html#FirewallTimeouts. It states that a firewall / routing device might be responsible for the timeouts. The team managing our firewalls and routers told us that there were no timeouts set here.
Which leaves us in the dark on the cause of our problem. Does anyone of you have any suggestions? Or even better, the solution!!
Have you tried the solutions in this article?
I avoid using the FTP adapter. Instead I use a third party utility to retrieve files and move the transferred file to a file adapter receive location. Third party utilities allow you to configure rules, recovery actions etc, freeing BizTalk from having to manage the transfer.