Client seems unaware that it has disconnected because of specified Idle Timeout (FileZilla_3.33.0_macosx-x86.app.tar.bz2)

[arfyness]

Expected:
1) Idle timeout causes disconnect.
2) User request a refresh.
3) FileZilla should immediately reconnect and refresh listing.

Observed:
1) Idle timeout elapses, connection dies. (no messages in the log indicate this)
2) User request a refresh.
3) "Delay between reconnect attempts" (e.g. 20sec) is enforced
4) FileZilla reconnects and refreshes directory listing

It seems like FileZilla is not aware that the connection has been terminated due to idle timeout until it tries to use the dead connection again. The disconnect button on the toolbar also remains available after the timeout disconnect. In fact, using the Disconnect and Reconnect buttons will work as expected for a connected session, even after the idle timeout has long passed.

---

Log set to Debug is pasted below with event comments

---

Trace: CTransferSocket::OnConnect
Trace: CTlsSocketImpl::OnRead()
Trace: CTransferSocket::OnReceive(), m_transferMode=0
Trace: CTransferSocket::TransferEnd(1)
Trace: CFtpControlSocket::TransferEnd()
Trace: CTlsSocketImpl::OnRead()
Trace: CFtpControlSocket::OnReceive()
Response: 226 Transfer ok.
Trace: CFtpRawTransferOpData::ParseResponse() in state 7
Trace: CFtpControlSocket::ResetOperation(0)
Trace: CControlSocket::ResetOperation(0)
Trace: CControlSocket::ParseSubcommandResult(0)
Trace: CFtpListOpData::SubcommandResult() in state 3
Trace: CFtpControlSocket::ResetOperation(0)
Trace: CControlSocket::ResetOperation(0)
Status: Directory listing of “/path/data" successful
Trace: CFileZillaEnginePrivate::ResetOperation(0)

* This is where I wait for the “timeout”

• This timeout value is set in …. Edit > Settings > Connection > Timeout in seconds = 10 (10 sec for testing)
• About 15 seconds after the last log message, I hit refresh…
• I would expect the client would already knows it has idle-timeout disconnected at this point.

Status: Retrieving directory listing of “/path/data"...
Trace: CControlSocket::SendNextCommand()
Trace: CFtpListOpData::ListSend() in state 0
Trace: CFtpChangeDirOpData::Send() in state 0
Trace: CFtpControlSocket::ResetOperation(0)
Trace: CControlSocket::ResetOperation(0)
Trace: CControlSocket::ParseSubcommandResult(0)
Trace: CFtpListOpData::SubcommandResult() in state 1
Trace: CControlSocket::SendNextCommand()
Trace: CFtpListOpData::ListSend() in state 2
Trace: CFtpRawTransferOpData::Send() in state 2
Command: PASV
Error: Connection timed out after 10 seconds of inactivity

* This is where the “Delay between failed retry attempts” is enforced (e.g. 20 sec).

Trace: CRealControlSocket::DoClose(2050)
Trace: CControlSocket::DoClose(2050)
Trace: CFtpControlSocket::ResetOperation(2114)
Trace: CControlSocket::ResetOperation(2114)
Trace: CFtpControlSocket::ResetOperation(2114)
Trace: CControlSocket::ResetOperation(2114)
Error: Failed to retrieve directory listing
Trace: CFileZillaEnginePrivate::ResetOperation(2114)
Status: Disconnected from server
Trace: CRealControlSocket::DoClose(66)
Trace: CControlSocket::DoClose(66)
Trace: CRealControlSocket::DoClose(66)
Trace: CControlSocket::DoClose(66)
Trace: CControlSocket::DoClose(66)
Trace: CFileZillaEnginePrivate::ResetOperation(0)
Trace: CControlSocket::SendNextCommand()
Trace: CFtpLogonOpData::Send() in state 0

* From here, the reconnect proceeds as expected, and refreshes the directory listing.

Thanks for taking a look. For now I just put 2 hours for the idle timeout, even though that's not really ideal. I also don't know if this is in the client or libfilezilla but it manifests in the client so that's what I chose.

[arfyness]

Relevant settings

[arfyness]

* This is the log from hitting disconnect long after the idle timeout has passed:

...
Status: Directory listing of "/path/data" successful
Trace: CFileZillaEnginePrivate::ResetOperation(0)

• Disconnect button pressed

Status: Disconnected from server
Trace: CRealControlSocket::DoClose(66)
Trace: CControlSocket::DoClose(66)
Trace: CFtpControlSocket::ResetOperation(66)
Trace: CControlSocket::ResetOperation(66)
Trace: CFileZillaEnginePrivate::ResetOperation(66)
Trace: CRealControlSocket::DoClose(66)
Trace: CControlSocket::DoClose(66)
Trace: CControlSocket::DoClose(66)
Trace: CFileZillaEnginePrivate::ResetOperation(0)

[Tim Kosse]

The problem is faulty firewalls and NAT routers that silently drop active connections without informing both peers.

Please fix or remove all faulty firewalls and NAT routers not adhering to REQ-5 from RFC 5382.