3

In the documentation it's not clear whether lftp support keepalive for FTP and SFTP protocols. Does someone know the answer?

2
  • @PimpJuiceIT, Hi, I've seen this. It says only about HTTP, but not about FTP/SFTP and I'm primarily interested to learn about FTP/SFTP.
    – Gill Bates
    Commented Oct 23, 2018 at 13:03
  • Good point, comment removed!! Commented Oct 23, 2018 at 13:24

3 Answers 3

4
+75

For FTP is there is no keep-alive mechanism, so no, as explained here: https://unix.stackexchange.com/questions/101399/how-to-keep-ftp-connection-alive

However you can try using the net options to set timeouts manually:

net:idle (time interval)

disconnect from server after this idle time. >Default is 3 minutes.

And

net:timeout (time interval)

sets the network protocol timeout.

As for sftp, it depends on your SSH client setup, for example you can adjust the timeout and keep alive options for openssh in /etc/ssh_config normally (the file location varies between distributions). This is best explained in this answer https://unix.stackexchange.com/a/261905/10525 but in short you need:

Host *
ServerAliveInterval XX
ServerAliveCountMax YY
1
  • Seems like you are right.
    – Gill Bates
    Commented Oct 24, 2018 at 11:08
0

A very good explanation of the problem comes from the ProFTPD projrct :

Consider what happens for FTP transfers which take a long time (either due to very large file(s) being transferred, or a slow connection): you have one TCP connection for the control connection, and a separate TCP connection for the data transfer conenction. All of the bytes are being transferred over the data connection, so that data connection is certainly not idle -- but while the data transfer is occurring, the control connection is idle! And let's assume that your FTP connections are going through some NAT device in between the client and the server.

That NAT may not be very smart; it may not know that the two different TCP connections of your FTP session are related to each other; it only sees one idle TCP connection, and one busy TCP connection. If that FTP control connection is idle for too long, then the NAT may close it (in order to keep valuable space in its state tables available for TCP connections that actually need to transfer bytes). (Some NATs have been known to close TCP connections that have been idle for only 5 minutes.) The FTP server sees that the FTP control connection is closed, and aborts the data transfer. What a mess!

If either the FTP server or the FTP client had used TCP keepalives on the control connection, then maybe that NAT would have seen the TCP keepalive probes, and not closed the idle control connection.

The ProFTPD projrct is a full-fledged FTP server that has support for TCP keepalives from the server itself.

From the client side, there are clients that can be configured to keep alive the TCP connection with the server, such as Filezilla.

From Unix Stack Exchange :

There is no absolute answer here, as FTP protocol in itself does not include such a mechanism.

There is however, FTP protocol commands with no real meanings on a given situation like "NOOP", "LIST" or "CWD" which can be used to keep the FTP connection alive.

So this is up to the client itself to implement such a mechanism using these "meaningless" commands in order to reset the timeout timers on the server side. Of course, you might also need to tune these client side mechanism in order to match the server side max idle time value.

To give you an example, the well known Filezilla is implementing such a mechanism (see in "Edit" -> "Settings" menu item, then in "Connection" -> "FTP" tab):

Filezilla Settings

0

You can try to set the ftp:nop-interval variable:

ftp:nop-interval (seconds)

delay between NOOP commands when downloading tail of a file. This is useful for ftp servers which send "Transfer complete" message before flushing data transfer. In such cases NOOP commands can prevent connection timeout.

set ftp:nop-interval 10;

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .