I've a problem with my FTP test server. I've installed and configured FileZilla server, It's listening for control connection on port 21, then it can provide passive mode data connection on ports between 50100 and 51100.
I'm trying a local connection 127.0.0.1:21 and retrieve the LIST of files and folders in the root FTP directory.
FileZilla Client: Works
FTP in MS-DOS: Works
TELNET in MS-DOS: Control connection and user authentication OK, then I switch to passive mode, and when I'm trying to retrieve files and folder with the command LIST It respond "Can't open data connection for transfer of "/"".
I've tried setting firewall rules for ports 50100-51100 and the FileZilla server. It's still not working.
You cannot retrieve files over FTP protocol using a Telnet client.
While you can simulate the FTP client by typing FTP commands on a Telnet console, you cannot do file transfers this way. It's because for file transfer you need a separate data transfer connection, what the Telnet client cannot do.
That's why the FTP server fails. In an active mode, it fails to connect back to your client machine, because there's nothing listening. In a passive more, it timeouts waiting for the client to connect to its data port.
Related
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.
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 am using Tftpd64 as server for transferring file to client.
Now when client request the file then i see below error in log viewer window of Tftpd64.
Connection received from 2a01:7e00:e000:11c:3546:7805:766:7110 on port 61445 [23/06 11:50:44.967]
Read request for file <test.ota>. Mode octet [23/06 11:50:44.967]
OACK: <blksize=1200,timeout=5,> [23/06 11:50:44.967]
Using local port 61801 [23/06 11:50:44.967]
File <test.ota> : error 10054 in system call recv An existing connection was forcibly closed by the remote host. [23/06 11:50:45.131]
Is any one have idea about above error?
Also i disabled the firewall in my PC but still getting same error.
Finally i am able to make Tftpd64 server up and running. I made below changes.
Enabled Windows Firewall.
Create rule for Tftp server (Widnows firewall->Advance settings->Inbound Rules->New Rule) to allow connection and apply rule for domain, public and private.
Why does Apache-Commons-Net's FTPClient sometimes make the wrong computation for the port number in the PORT command? This is in active mode. For example FTPClient it could send out
PORT <some>,<ip>,<address>,<here>,235,181 when in fact the port number used is 60340. What's the cause for this wrong computation?
This could happen on version 3.3.
I know ftpClient.enterLocalPassiveMode(); could solve this, but I want to know the part where the active mode doesn't work as expected.
From your comments, I assume you mistake an FTP control connection with a data connection.
I assume that the 60340 is local port of the FTP control connection. When opening data connection, 60341 is assigned (hence the PORT ...,235,181).
Reasoning: In an FTP active mode, the client opens listening port for the expected data connection, which it then reports to the server via PORT command over an existing control connection. If the server cannot connect to the port, no TCP/IP packet can ever come to that port. As you claim that the "two machines still communicate at port 60340", it must be the control connection. There cannot be any communication on port, if the connection failed ("Can't open data connection").
The actual cause of the "Can't open data connection" error is likely that you are behind a firewall, so the server cannot connect back to the client. What is a common nowadays. That's what passive mode is good for.
I want to add support for the PORT command to my FTP server. I'm reading RFC 959, but I can't figure out when it's safe to connect to the FTP client. For example, consider this sequence:
PORT 127,0,0,1,34,34
LIST
Does the FTP client start listening before issuing the PORT command, or after issuing the LIST command? Because if the server attempts to connect to the client immediately after receiving PORT, it might fail because the client might not have started listening yet.
What does the specification say? Can the server connect immediately, or should it wait until after it receives the command that will make use of the data connection?
The server shouldn't connect to the client until it gets a command that requests a data transfer, such as LIST or RETR. See section 7 of RFC 959, which shows a typical sequence of operations (RFC's didn't have the formal MUST/MAY/SHOULD specifications in those early days).
However, since the port used in the PORT command is typically an ephemeral port, the client needs to open a socket to get the OS to assign a port number. This implies that by the time the PORT command is sent, the port would have to be open. However, it's possible that it might not yet have called listen().