FTP ls works fine, but LIST not working. vsFTP server

Question

Here just log. Remote clients also cant connect why ls works, but not a LIST?

vsFTP works fine via SFTP, but does not lock client in home directory if lock client in home only via ftp

root@zzzzzz:~# ftp localhost
Connected to localhost.
220 (vsFTPd 3.0.3)
Name (localhost:root): aaaa
331 Please specify the password.
Password:
230 Login successful.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> ls
200 EPRT command successful. Consider using EPSV.
150 Here comes the directory listing.
-------------------------------
226 Directory send OK.
ftp> quote LIST
425 Use PORT or PASV first.
ftp> quote PASV
227 Entering Passive Mode (0,0,0,0,190,115).
ftp> quote LIST
---- 1 minute delay ----
425 Failed to establish connection.
ftp> recv
(remote-file) robots.txt
(local-file) 111
local: 111 remote: robots.txt
200 EPRT command successful. Consider using EPSV.
150 Opening BINARY mode data connection for robots.txt (23 bytes).
226 Transfer complete.
23 bytes received in 0.02 secs (1.4171 kB/s)
ftp> quote RECV
500 Unknown command.
ftp> quote RETR
425 Use PORT or PASV first.
ftp> quote PASV
227 Entering Passive Mode (0,0,0,0,66,14).
ftp> quote RETR
550 Failed to open file.
ftp> quote RETR robots.txt
---- 1 minute delay ----
425 Failed to establish connection.
ftp>

Answer 1

The way FTP works is to have a constant connection on a control channel, port 21, and to set up and tear down connections to pass data over, on some random channel decided by the server or the client

In PORT (active) mode the client decides what port it will open, it tells the server and the server connects to the client. This isn't very good these days because most clients are likely being some NAT device that won't forward the connection on

In PASV (passive) mode the server decides what port to open, and the client conents into it. This is much more compatible with the majority of client side NAT devices, and the range of ports the server will open is typically configured by the network admin responsible for the server who is also responsible for the firewall on the server's network (so they can configure the forwarding rules to work out)

This split was originally pretty useful for transferring large files between two servers on fast connections, controlled by a client on a slow connection - the client could connect to each server simultaneously, tell one server to expect a connection, and the other to make a connection and cause the servers to connect directly so the data didn't flow though the client.

---

You're using quote a lot in your log - this sends a raw command to the server but the client won't necessarily take any further interest in it - just because you quote PASV to request the server go to passive mode doesn't mean it will switch the client over to knowing it has to operate in passively so even when the server does switch to expecting a connection, the client won't connect.

If you're using windows FTP command line client with a server that requires passive connections I'm afraid you're sunk - the client doesn't suport passive operation. I recommend seeking an alternative client with a command line version that does support passive.

nb, SFTP is an entirely different beast that just happens to share part of an acronym. SFTP doesn't have this "control channel + multiple random data channels" idea so it's often more reliable and easier for network admin to permit because everything goes over the one channel; that may be your solution and one that is perhaps preferable because it's more secure all round. With FTP you don't really have any good guarantees that the data is from the actual same source that was instructed to send it