Transfers stall after completion on XP 64bit

I'm using 3.6.0 build 1240 on an HP ML115 G5 quad core AMD running XP sp2 64bit, ever since this new install there have been issues transferring files whereby after each file completes the client stalls until the remote FTP disconnects (or the flashfxp idle/tranfer timeout kicks in). It'll then reconnect and go onto the next file.

It also appears to, less often, stall the transfer towards the very end, with the same issue.

Unfortunatley time stamping wasn't turned on, but the below shows this issue.

[R] RETR BEWS.91.4691.1.aa_264660.zip
[R] 150 Opening BINARY mode data connection for BEWS.91.4691.1.aa_264660.zip.
[R] Connection lost: ftp.support.veritas.com
[R] Attempting to Reconnect.
~~~
removed all the reconnect info
~~~
[R] REST 112555780
[R] 350 Restarting at 112555780.
[R] RETR BEWS.91.4691.1.aa_264660.zip
[R] 150 Opening BINARY mode data connection for BEWS.91.4691.1.aa_264660.zip.
[R] 226 Transfer complete.
Resumed: BEWS.91.4691.1.aa_264660.zip 2.66 MB in 9.06 seconds (300.4 KB/s)

Which proves it did all but 2.66 MB (of 110MB) before the initial connection lost.

On the occasions it does complete a file OK, but still stalls, it keeps the failed file in the queue even though it completed OK, but due to the disconnect it doesn't think it did, so tries to complete it.

XP 64bit is on the only platform where this appears to be an issue, and it affects a multiple of FTPd, LAN (vsftpd) and WAN (proven on ftp.support.veritas.com as per above).

Network is Gig with an MTU of 1500.

Same hardware setup with an HP ML115 G1 dual core AMD with 32bit XP has worked without issue.

Hello,

Typically a stall at the end of a transfer indicates that the control connection was closed during the transfer, FlashFXP will continue to transfer the data as long as the data connection remains open.

The control connection might of been closed by a firewall or your router due to inactivity, one way to determine this is by watching and seeing how long it takes for the transfer to complete, if only transfer taking more than a certain amount of time trigger this then its a good indicator that this is what's occurring.

FlashFXP attempts to work out this issue with an option "send noops during transfer" however its not compatible with all ftp servers.

The correct way to resolve this issue is to determine what is closing the idle connection, this might be a firewall or your router. Usually they have an option to close inactive or idle connections and the timeout needs to be increased or the option turned off.

Hi.

As per my initial post, no hardware has changed (inc router(firewall & settings), cables, etc) and there are no issues with any other platform on the same network, apart from under 64bit XP.

I'll try and prove the issue is 64bit XP related by doing a 64bit XP install on the same physical hardware which ran 32bit OK for the last 18 months.

The issue will happen on files of all sizes.

I'll change my settings to auto-resume and setup some files locally of different sizes with the timestamp turned on so you can get a better idea of what's going on.

It could be a driver bug for the NIC, but no other application is affected, only FlashFXP. I'll also try changing the buffer size down to minimum and up to maximum, within FlashFXP.

Thanks
Chris

I've done a little flash to show a working, and a non-working.

It may be something to do with timing, but not those on the ftpd or firewall (no firewall for LAN traffic), and no other machine is affected.

Notice how for the 2nd, speed limited, transfer which is the one which fails, the status bar is blank when the xfer should have finished but its a further couple of minutes until the timestamped log actually completes. This is where the issue is, although this time it removed the xfer from the queue rather than failing it.

Make sure you're watching till the timestamped log gets to 15:16:42
Also notice the time descrapancy (2min 10sec) between the 2 timestamps of identical times.

http://www.zaq.me/FlashFXP.swf.html

Interestingly, irrespective of the ftpd connected to, when the stall happens, it always appears to be approx 2 mins 10 seconds (the same as the gap shown in the timestamp log) between the connection/tranfer stalling and FlashFXP coming back to life again.

FlashFXP works great on 64bit OS's, I develop FlashFXP on Vista 64bit and perform testing using Windows 2008 R2 64bit, and Windows 7 64bit and it works flawlessly.

It could be a driver issue but this seems very unlikely.

I still think its related to some sort of inactivity timeout set somewhere.

Originally Posted by bigstar

I still think its related to some sort of inactivity timeout set somewhere.

Given it only affects one client machine, I can't see how.

vsftpd (the one doing the local ftp) is set to 120 seconds (which is close to the 2mins 10secs) for data_connection_timeout, but it always has been and doesn't affect flashfxp on other machines on the LAN in the same way.

I do have MBAM running on this machine however, which is different to all the others. So I'm about to reboot with it disabled and test again.

Nope, still the same after disabling MBAM.

Do you have access to an XP 64bit machine to test against, the test file I used is clearly available and I presume you have a machine you can stick vsftpd on?

Interestingly whilst installing FileZilla, the following warning appeared, notice XP 64 and the exact symptoms I'm getting.



Turned off the XP firewall, the issue goes away in FlashFXP.