Transmission stalls in the middle

[anonymous]

I posted in the forum but seems no replies.

It happened when I was downloading a one-level dir
with some (about 40) pictures. The transmission simply
stalled in the middle of a file. More accurately, the
stalled files are put to the end of the queue
with "too many retries". The error message in message
log window is "timeout". I repeated this operation
several times. Sometimes it is OK while sometimes it
stalled again.

I am running it on a Win2000 professional. Installed
without admin previledge. The server is Serv-U ftpd
3.0 with no timeout settings.

Fan

[codesquid]

I need some more information before I can tell you more
about this potential bug.
- Which version of FileZilla
- Can you reproduce the problem?

If yes, does this happen with other servers, too?

- Where is the server located:

a) your machine
b) LAN
c) Internet
If it is the last one, how are you connected with the

internet?
- Have you set any proxy or firewall in FileZilla?

[anonymous]

Logged In: NO

1.I am using the newest 1.5a Filezilla
2.The problem occurs now and then, especially when
tranferring large files (actually not so large, once it
stalled on a 100k file). I have tried on another server,
also serv-u, the file stalled again with "too many retries".
3.Both servers I tried are all in a LAN.
4.No proxy needed.

Furthermore, when transferring a large files, filezilla has
a behavior like "stop and resume". It could happen up to 5
times when transferring a 4M mp3. Is that due to the design
mechanism inside?

Fan

[anonymous]

Logged In: NO

I have the same problem. Here my answers to your queries:

Which version of FileZilla

Version 1.6

Can you reproduce the problem?

Happens with every server I have tried.

Where is the server located:
a) your machine
b) LAN
c) Internet
If it is the last one, how are you connected with the
internet?

It makes no difference. I can verify that with LAN and
Internet (direct).

Have you set any proxy or firewall in FileZilla?

Nope.

The same thing happens with WU-FTPD and ProFTPD. Other
programs seem to work just fine with the same servers in
question. Also this bug happens very often and is easy to
reproduce by dropping bunch of files to queue.

I can provide a little debug data, but I think it would not
help so much:

---

dispatching PRE_CMD command 'TYPE I' to mod_core
dispatching CMD command 'TYPE I' to mod_xfer
dispatching PRE_CMD command 'SIZE x0.sav' to mod_core
dispatching CMD command 'SIZE x0.sav' to mod_core
dispatching PRE_CMD command 'PORT CLIENT,6,225' to mod_core
dispatching CMD command 'PORT CLIENT,6,225' to mod_core
dispatching PRE_CMD command 'REST 0' to mod_core
dispatching CMD command 'REST 0' to mod_xfer
dispatching PRE_CMD command 'RETR x0.sav' to mod_core
dispatching PRE_CMD command 'RETR x0.sav' to mod_xfer
dispatching CMD command 'RETR x0.sav' to mod_xfer
active data connection opened - local : SERVER:20
active data connection opened - remote : CLIENT:1761
Transfer aborted after 2473984 bytes in 62.90 seconds.
FTP session closed.
...
connected - local : SERVER:21
connected - remote : CLIENT:1762
FTP session opened.
...
dispatching PRE_CMD command 'TYPE I' to mod_core
dispatching CMD command 'TYPE I' to mod_xfer
dispatching PRE_CMD command 'SIZE x0.sav' to mod_core
dispatching CMD command 'SIZE x0.sav' to mod_core
dispatching PRE_CMD command 'PORT CLIENT,6,229' to mod_core
dispatching CMD command 'PORT CLIENT,6,229' to mod_core
dispatching PRE_CMD command 'REST 2449248' to mod_core
dispatching CMD command 'REST 2449248' to mod_xfer
dispatching PRE_CMD command 'RETR x0.sav' to mod_core
dispatching PRE_CMD command 'RETR x0.sav' to mod_xfer
dispatching CMD command 'RETR x0.sav' to mod_xfer
active data connection opened - local : SERVER:20
active data connection opened - remote : CLIENT:1765
Transfer completed: 2982314 bytes in 2.98 seconds.

---

Oh yes, the client in running Windows 2000 SP2

Mig

[codesquid]

I've attached a test release of FileZilla 1.7.
Please download it and copy it into your FileZilla folder.
The open the settings dialog, select the debug page and
activate "Trace messages from the ftp engine" and "Log to
file". As filename enter "c:\FileZilla Log.rtf" (without
quotes)
Then try to reproduce the error. If the error occurs, close
FileZilla and send me the log.

[anonymous]

Logged In: NO

To reproduce possibly the same error, log into
linux.nssl.noaa.gov as anonymous and try to
download /pub/linux/redhat/linux/7.2/en/iso/i386/enigma-
i386-disc1.iso.
FileZilla 1.6 works well for a few seconds then it stalls
and soon times out.

Xiaowen

[anonymous]

Logged In: NO

The bug is still there. Here's a debug log from FileZilla
1.7:

---

...

Status: RETR x3.sav
Status: X:.cpp(237) : OnAccept(0)
Status: 150 Opening BINARY mode data connection for x3.sav
(4774985 bytes).
Status: X:.cpp(311) : OnSend(0)
Status: X:.cpp(253) : OnConnect(0)
Status: X:.cpp(96) : OnReceive(0)
Status: X:.cpp(96) : OnReceive(0)
Status: X:.cpp(96) : OnReceive(0)

...

Status: X:.cpp(96) : OnReceive(0)
Status: X:.cpp(96) : OnReceive(0)
Status: X:.cpp(96) : OnReceive(0)
Status: X:.cpp(281) : OnClose(0)
Status: X:.cpp(96) : OnReceive(0)
Status: Timeout detected!
Status: X:.cpp(960) : TransferEnd(24)
Status: Download failed
Status: Starting download of x3.sav

...

---

Mig

[jclinton]

I am also experiencing the same results running Windows 2000
SP2. The dubug log looks similar and I've tested it on a
varietty of servers... the result is always the same: after
a variable about of time, the transfer will fail with the
same error messages mentioned in the bug tracker's openning
message.

My guess is Win2k packet handling is the source of the
problem? If that's true, this should also occur on WinXP.

[rglidden]

For what it's worth, this problem is still there in
FileZilla 1.8.3. Running Windows 2000 SP2, direct
connection to a FreeBSD ftp server via 100 Mbps Ethernet.
Transfers stall after a random amount of time. Stalls seem
more likely when transferring large files. I have been
unable to make other windows FTP clients (Win2K command line
ftp, IE6, NS6.2) fail transferring the same file from the
same server.

--- Log ---

FileZilla started (03/01/2002 20:48:55)
Status:
Connecting to charon.localnet ...
Trace:
ControlSocket.cpp(252) : OnReceive(0)
Status:
Connected with charon.localnet. Waiting for welcome message...
Response:
220 charon.localnet FTP server (Version 6.00LS) ready.
Command:
USER rglidden
Trace:
ControlSocket.cpp(252) : OnReceive(0)
Response:
331 s/key 98 ch88594
Command:
PASS ********
Trace:
ControlSocket.cpp(252) : OnReceive(0)
Response:
230 User rglidden logged in.
Status:
Connected
Trace:
ControlSocket.cpp(2351) : ResetOperation(1)
Trace:
ControlSocket.cpp(735) : List(FALSE,0,"","",1)
Status:
Retrieving directory listing...
Command:
PWD
Trace:
ControlSocket.cpp(252) : OnReceive(0)
Response:
257 "/home/rglidden" is current directory.
Trace:
ControlSocket.cpp(735) : List(FALSE,0,"","",0)
Command:
PORT 192,168,1,2,7,107
Trace:
ControlSocket.cpp(252) : OnReceive(0)
Response:
200 PORT command successful.
Trace:
ControlSocket.cpp(735) : List(FALSE,0,"","",0)
Command:
TYPE A
Trace:
ControlSocket.cpp(252) : OnReceive(0)
Response:
200 Type set to A.
Trace:
ControlSocket.cpp(735) : List(FALSE,0,"","",0)
Command:
LIST
Trace:
TransferSocket.cpp(227) : OnAccept(0)
Trace:
ControlSocket.cpp(252) : OnReceive(0)
Response:
150 Opening ASCII mode data connection for '/bin/ls'.
Trace:
TransferSocket.cpp(311) : OnSend(0)
Trace:
TransferSocket.cpp(243) : OnConnect(0)
Trace:
ControlSocket.cpp(735) : List(FALSE,0,"","",0)
Trace:
TransferSocket.cpp(95) : OnReceive(0)
Trace:
TransferSocket.cpp(644) : Close()
Trace:
ControlSocket.cpp(252) : OnReceive(0)
Response:
226 Transfer complete.
Trace:
TransferSocket.cpp(271) : OnClose(0)
Trace:
TransferSocket.cpp(95) : OnReceive(0)
Trace:
TransferSocket.cpp(644) : Close()
Trace:
TransferSocket.cpp(644) : Close()
Trace:
ControlSocket.cpp(1260) : TransferEnd(4)
Trace:
ControlSocket.cpp(735) : List(TRUE,0,"","",0)
Trace:
ControlSocket.cpp(735) : List(FALSE,0,"","",0)
Trace:
ControlSocket.cpp(2351) : ResetOperation(1)
Trace:
ControlSocket.cpp(1296) : FileTransfer(9031256, FALSE, 0)
OpMode=0 OpState=-1
Status:
Starting download of testfile.bin
Command:
TYPE I
Trace:
ControlSocket.cpp(252) : OnReceive(0)
Response:
200 Type set to I.
Trace:
ControlSocket.cpp(1296) : FileTransfer(0, FALSE, 0)
OpMode=24 OpState=8
Command:
PORT 192,168,1,2,7,108
Trace:
ControlSocket.cpp(252) : OnReceive(0)
Response:
200 PORT command successful.
Trace:
ControlSocket.cpp(1296) : FileTransfer(0, FALSE, 0)
OpMode=24 OpState=10
Command:
RETR testfile.bin
Trace:
TransferSocket.cpp(227) : OnAccept(0)
Trace:
ControlSocket.cpp(252) : OnReceive(0)
Response:
150 Opening BINARY mode data connection for 'testfile.bin'
(512342016 bytes).
Trace:
TransferSocket.cpp(311) : OnSend(0)
Trace:
TransferSocket.cpp(243) : OnConnect(0)
Trace:
ControlSocket.cpp(1296) : FileTransfer(0, FALSE, 0)
OpMode=24 OpState=11
Trace:
TransferSocket.cpp(95) : OnReceive(0)
Trace:
TransferSocket.cpp(95) : OnReceive(0)

<... OnReceive(0) many many more times ...>

Trace:
TransferSocket.cpp(95) : OnReceive(0)
Trace:
TransferSocket.cpp(95) : OnReceive(0)
Error:
Timeout detected!
Trace:
TransferSocket.cpp(644) : Close()
Trace:
ControlSocket.cpp(1260) : TransferEnd(152)
Trace:
ControlSocket.cpp(1296) : FileTransfer(0, TRUE, 128)
OpMode=24 OpState=12
Trace:
ControlSocket.cpp(2351) : ResetOperation(4100)
Error:
Download failed
Status:
Connecting to charon.localnet ...
Trace:
ControlSocket.cpp(252) : OnReceive(0)
Status:
Connected with charon.localnet. Waiting for welcome message...

<... and so on ...>

[codesquid]

version 1.8.4 tr 3

[codesquid]

Here's a new testrelease, it should really fix the bug.

[rglidden]

It looks like the new testrelease solves the problem. I've
successfully transfered a 488 MB file back and forth about
10 times between my Win2K machine and the FreeBSD server I
was using for tests before. Aside from the occasional
hiccup (a slight pause of about 1/4 second, which is to be
expected as the machines write their cache to disk, etc),
the transfer goes smoothly. The timeout problem is gone.

The transfer rate seems to be a bit better too, though I
couldn't tell for sure because the status bar said "(null)B/s".

Thanks for the fix codesquid!

[goosecreature]

I downloaded the new test release file and did some
testing, and I agree it seems to be fine now. I've
transferred over 500mb to various different machines and it
has't stalled once.

Nice fix! :) and thanks.