Custom Query (8142 matches)

Steps to reproduce

1. Upload a large file (I tried a 1 TiB file) to a proftpd server with "slow" disks using default settings in active mode.
2. Once all disk caches on the server are filled (which happened always somewhere around 12 GiB) and the server has to sync the data to disk, it'll set the TCP Window Size to 0 while the data is written and synced.
3. After that, it'll increase the window size again to continue the transfer.

Expected behavior

FileZilla should consider this an active connection (as long as the tcp window size probes are still ACked ofc), report a 0 byte/s current transfer speed, and continue normally once the window size has been increased again.

Current behavior

FileZilla terminates the file transfer with the reason "connection timed out", probably because of oversight within the timeout logic. It probably only checks for 0 bytes/s transferred instead of also checking if the TCP connection is still alive and only set to a window size of 0. Funnily FileZilla tries to restart the connection but then fails because the temporary ".in.*" file still exists (A 2nd bug, or do we hit some kind of edge case here?) Also noteworthy, the retry setting was set to 5, but FileZilla did only one automatic retry and then failed the transfer. Also, the 10-second delay between retries was not honored here, as the retry happened instantly after the reset was sent to the server. And also noteworthy is that FileZilla will delete the partial upload from the server once it failed the transfer...

Workaround

Go into the options and set the timeout to 0.

But this has still undesirable side effects like no timeouts are detected anymore and the transfer will therefore get stuck completely once an actual timeout happens.

(Admittedly, another workaround is to set the delay kinda high to 5 minutes or so, but even though it would work for this connection, it'll unnecessarily slow down other transfers to different servers and also not correctly detect the connection state. It'd only work if the server manages to sync and accept data again within 5 minutes.)

Proposed fix

1st Add a TCP connection state check into the timeout detection logic (not a timeout if still packages are exchanged, see screenshot for example connection) 2nd And (maybe) add an additional option within the connection timeout section for backward compatibility like "☑️ treat a Zero TCP Window Size as timed out" with a default value of being unchecked (Enabling this option will result in the current behavior again). 3rd (purely visual), fix the connection speed that is shown in the UI, currently it never shows 0, not even if "Display momentary transfer speed instead of average speed" is enabled. 4th If the reconnect logic triggers a reset of an active file transfer, it should expect the temporary ".in.*" file already be present and automatically resume it instead of failing the transfer because it already exists. (My default file exists action is set to "Ask for action" btw, but it also didn't ask, it just failed the (unnecessarily triggered) retry) 5th honor the reconnect settings also for automatic reconnects (amount and delay in-between).

The GUI shows the active mode been set with the correct external IP address but still teh server replies with the internal ip address (LAN IP) of the client and says cannot establish connection. On checking through a Packet Sniffer it can be seen that filezilla is actually sending the LAN IP altough in the console/log/gui it shows its sending the external IP.

Issue with 3.0.9.2 and also with 3.0.9.3 - nightly build

It would be excellent if FileZilla Client would connect in active mode via UPNP Internet gateway device