Freezes on LAN download from server with connection limits

[Cryptor]

Filezilla version: 3.5.3

I am connecting to two server over LAN. When I queue and process file downloads from both servers concurrently in a FZ client session, the client freezes and must be force-closed.

The servers are slightly unusual in that they are embedded servers in Topcon GPS receivers. The server software enforces a strict limit of one connection per receiver. I have configured this limitation in the Site Manager (Limit Number of Simultaneous Connections = 1).

If a subsequent connection is attempted, the receiver will return a 530 error message and disconnect. This behavior has been observed using Topcon NetG3A receivers as well as Topcon GB1000.

I have tried this using multiple client PCs (Asus netbooks, Dell desktops, laptops) using various operating systems from Vista to XP to Windows 7.

By contrast, if I open two separate filezilla client instances, and start a concurrent queue of downloads in each of these separate filezilla instances, the downloads work just fine. So this seems to point to some kind of race condition, or perhaps a connection isn't getting closed in the right order, when downloading within the same filezilla instance.

[Alexander Schuch]

"If possible, provide the contents from the message log. To do so, you should set the program's language to English, set the debug level to 3 in the settings and restart the client. Then connect to the server, perform the action that causes problems and copy the entire log to the clipboard and attach it to the bug report.
Do not tamper with the log, leave it exactly as is. Do not obfuscate any addresses or filenames. You will most certainly remove vital information from the log if you modify it."

Can you please enable message logging to file using the above settings. Then, do what you did in order to make FileZilla freeze. Next, wait a bit and see if new message are added. For example, note the time when FileZilla starts to freeze. Wait 5 minutes, and then kill it.

You of course have timestamps enabled for logging.

So there are some possibilities then: FileZilla still runs just the GUI is not updating anymore - this can be seen by timestamps later than the freezing.

Well… just attach the logs and we'll see.

[Cryptor]

Log from dragging all items to transfer queue before initiating transfer.

[Cryptor]

Here's the action to produce the behavior in fz20120701_tfrqueue.log:

1. Open connection to 1st server
2. Open connection to 2nd server
3. Drag and drop files from server 2 to queue
4. Drag and drop files from server 1 to queue
5. At 16:25:00, I click the Process queues button.

Result:
GUI freezes. Windows task manager says CPU usage at 45% (on dual core system). I/O reads and writes have stopped. Waiting "ring" icon and client window grays out and says "(Not Responding)"

So it appears that upon clicking transfer queues, no log messages are added, since the last time stamp is 16:24:56.

[Cryptor]

Log from dragging files from remote to the local directory to initiate transfers automatically

[Cryptor]

1. Open connection to 1st server
2. Open connection to 2nd server
3. 16:29:02 - drag and drop files from server 2 to download window
4. 16:29:30 - drag and drop files from server 1 to window

Result:

GUI Freezes at 16:29:50 after finishing transfer of file JKB420510m.
Windows task manager says CPU usage at ~50% (on dual core system). I/O reads and writes have stopped. Waiting "ring" icon and client window grays out and says "(Not Responding)"

Also, please see attached fzclientwindow.png, at the bottom, in the transfer queue, there is a note that says "waiting for browsing c..." which I thought could be useful.

[Zaphod Beeblebrox]

Hi,
I am having this same above issue while transferring files to my android phone and tablet.

Thnx for the free server software. I have version 0.9.45 installed on Win7 SP1 x64. Previous Filezilla versions had same issue. I did not have this issue with the trial version of Serv-U FTP server.

• It occurs irrespective of settings in limited connections or server to server blocking settings.
• It occurs almost always when I transfer more than 3 files.
• It occurs while using either Total Commander for Android with FTP plugin or with AndFTP software.
• disconnecting and reconnecting the phone from WiFi LAN does not fix it till ~ few mins later. This does not seem to be related to the router since I had same issue on another network at my parents home.
• The LOG file does not mention an error. It only mentions "421 Connection timed out.". If I only transfer 1 or 2 files, it mentions regular "Goodbye" and "Disconnected".

Please let me know of any other needed info by email.

[Zaphod Beeblebrox]

I should have clarified that this issue seems to be in the Server and not in the client.

[Cryptor]

Not to get too pissy, but you can't just hijack my bug which was correctly filed two y ears ago against Filezilla Client (because Filezilla Server wasn't involved), change the title from "Freezes on LAN download from server with connection limits", and rename it "Freezing transfer on LAN download from Filezilla Server", and reassign it to Filezilla server.

You should probably file your own bug in the Filezilla Server component with your own log files.

[Zaphod Beeblebrox]

Replying to cryptor3:

Not to get too pissy, but you can't just hijack my bug which was correctly filed two y ears ago against Filezilla Client (because Filezilla Server wasn't involved), change the title from "Freezes on LAN download from server with connection limits", and rename it "Freezing transfer on LAN download from Filezilla Server", and reassign it to Filezilla server.

You should probably file your own bug in the Filezilla Server component with your own log files.

I am not a software expert, and I had no idea I was hijacking anything.
​http://trac.filezilla-project.org/ticket/1191
​http://serverfault.com/questions/231087/passive-mode-for-filezilla-ftp-isnt-working

It seems I am just wasting my time here...

[Cryptor]

I'm sorry that I sounded upset, but let me explain what happened and why it made me upset. It was like stepping into an existing conversation and changing the subject. When you made changes under "Change Properties", it changed the topic and content of the bug so that it was inaccurate and not relevant to the original report. It did not create a new bug for you.

I am a user (not a developer) of Filezilla just like you who is trying to make the software better by filing focused bug reports that can be individually addressed by developers.

If this is also your goal, I would encourage you to take the time to look at bugs under the Filezilla Server component and see if any bugs matching that filter seem to have the same behavior. If not, then try posting the same information under a new bug with Filezilla Server as the component type. That will definitely give you the best chance that a developer will be able to look at your request and ask for more information if required.

[Tim Kosse]

@Beeblebrox: Please don't hijack tickets.

@cryptor3: Does this issue still occur using the latest version of the client?

[Cryptor]

@codesquid,

I finally got my hands on a pair of NetG3A receivers and it looks like the problem no longer occurs as of 3.9.0.1. I'm getting good transfer rates as well (2.5 MB/s each, reasonable for these receivers).

So looks like it is fixed. Whatever happened to fix the problem, thanks.