#11623 closed Bug report (rejected)

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

Reported by: arfyness Owned by:
Priority: normal Component: FileZilla Client
Keywords: idle timeout reconnect delay Cc:
Component version: FileZilla_3.33.0_macosx-x86.app Operating system type: OS X
Operating system version: 10.13.4 (current)

Description

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.

Attachments (1)

Screen Shot 2018-06-05 at 3.29.09 AM.png (221.1 KB) - added by arfyness 18 months ago.
Relevant settings

Download all attachments as: .zip

Change History (3)

Changed 18 months ago by arfyness

Relevant settings

comment:1 Changed 18 months ago by 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)

comment:2 Changed 18 months ago by Tim Kosse

Resolution: rejected
Status: newclosed

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.

Note: See TracTickets for help on using tickets.