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().
Related
I'm looking for a command like:
ping google.com
But I also want to use the port, like google.com:8080
I want to know if a client can connect to my servers socket listener at a certain port.
My core problem is, 100% of users are able to connect to my websocket port at 8080, but only single digit x% are able to connect to websocket port at 2053. This is independent of device. After research I've found out that some ISPs might be blocking this port.
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)
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 just re-installed Ubuntu server 10.04 and decided to change all of my default ports to get a little extra security. Everything works fine, except when I decided to change the FTP (ProFTPd) port from the standard 21 to 3521. No problems with firewalls or port forwarding. ProFTPd was restarted but when I am trying to connect to it,even though it does respond, it throws the client (FileZilla) into a "passive mode" and then never goes into listing a directory.
I don't really want to use the "passive mode" and I have it disabled in proftpd.conf, but nevertheless I can't seem to change the default port otherwise and make it working. It does seem to work fine on port 21. FYI, the proftpd was installed as a standalone daemon, if that matters somehow?
Ok, I think I figured this out after reading this page: link . It appears that most FTP connections are indeed "passive" and the problem with "active" connections comes from the use of firewalls on the client side since FTP server is initiating an outgoing "data" connection to the client on some random port. In passive mode the client initiates both "command" and "data" connections to the server and hence the firewall isn't a problem, but you should specify which "passive" ports to use on the server. I enabled 3520 and 3521 PassivePorts and it's now working
FTP Active Mode by definition requires the server to initiate its outgoing connections from port L-1. Does your firewall allow outgoing connections from port 3520 as well?
From the FTP RFC:
3.2. ESTABLISHING DATA CONNECTIONS
The mechanics of transferring data consists of setting up the data
connection to the appropriate ports and choosing the parameters
for transfer. Both the user and the server-DTPs have a default
data port. The user-process default data port is the same as the
control connection port (i.e., U). The server-process default
data port is the port adjacent to the control connection port
(i.e., L-1).
...
3.3. DATA CONNECTION MANAGEMENT
Default Data Connection Ports: All FTP implementations must
support use of the default data connection ports, and only the
User-PI may initiate the use of non-default ports.
Negotiating Non-Default Data Ports: The User-PI may specify a
non-default user side data port with the PORT command. The
User-PI may request the server side to identify a non-default
server side data port with the PASV command. Since a connection
is defined by the pair of addresses, either of these actions is
enough to get a different data connection, still it is permitted
to do both commands to use new ports on both ends of the data
connection.
You might wish to take the opportunity to change your users to SFTP, a much nicer protocol.