Two CRITICAL FlashFXP errors

[Pichento]

First of all thanks for a great ftp-client. I have registered well over six months ago and so far I'm very happy with the many cool features FlashFXP offers.

But FlashFXP has to very serious bugs that I sincerely hope you get fixed ASAP.

1. (FlashFXP + ioftpd)

- When transfering in SSL mode (local uploads / downloads) files skip the last few bytes (i.e. 15.000.000 -> 14.999.995). I have tested it with the latest 909b4 and 8 other versions of FlashFXP. Also I 25 users have tested it and 85% get errors. The funny thing is that a few transfer with no problems. It seems that the transfer just completes before it's actually finished. I've tried three other ftp clients (wincmd + ssl wrap, cute ftp pro and smartftp) and they do NOT show this behavior.

2. (FlashFXP + ioftpd / raidenftpd)

- SSL transfers slow down, unless you change the transfer-buffers manually. This is not possible in raidenftpd, but unless you modify the buffers, you're stuck at 80 kb/s (ioftpd) and around 150 kb/s (raidenftpd) download speed max on a 2mbit connection. Also the three above-mentioned clients do NOT show this behavior.

[Pichento]

OS: .NET RC2 (Windows Server 2003)

FlashFXP: All build since 906
IoFTPD: Latest (4.6.1)
RaidenFTPD: Latest (2.4 build 345)

[bigstar]

I don't have any ioftpd test servers. Would you like to provide me with one?

[Pichento]

Sure.

Download 4.6.2 here:

ioFTPD 4.6.2 (unregistered) (http://www.ioftpd.com/~darkone/ioftpd/ioFTPD-beta4-6-2u.exe)

[bigstar]

It seems like ioftpd prematurely closes the data socket by tiggering a FD_CLOSE before all of the data is sent.. I noticed ioftpd uses a 16k buffer this might partly to blame.. more testing is required.

[Pichento]

BigStar: I already did tests with different buffer sizes. Really has no effect on the error in question.

Im running with much larger buffers in general to ensure higher speeds.

But it DOES close prematurely.

[MidKnight]

thats why we are currently testing this situation a little further in. but stay tuned for more details ;)

[Pichento]

Sounds cool guys.

Maybe you should talk to DarkOne directly. I'm sure you'll have the problem fixed in no time.

[darkone]

Hmms.. in unregistered version all timeouts are disabled => if server does not receive proper connection closure (ssl_shutdown()) - it hangs inndefinetely. Neat, uhh? :)

What comes to FD_CLOSE - I'm quite confident that all data is being processed properly. Also FD_CLOSE should not occur in SSL mode before SSL_shutdown() has returned 1. If SSL_shutdown() is not called at all, some data may/will be lost.


Edit: I tried with smartftp, and did not notice any problems (timeouts disabled)

[darkone]

SSL_shutdown is called before FD_CLOSE occurs. If client is sending data (uploading), it should call SSL_shutdown() once all data has been sent (EOF). Server does SSL_read() until SSL_ERROR_ZERO_RETURN is returned. At this point server calls, SSL_shutdown(). Both ends wait until SSL_shutdown returns with 1/error, or timeout elapses. Socket is to be closed at this point.


C> SSL_connect()
S> SSL_accept()
C> SSL_write()
S> SSL_read()
C> SSL_shutdown()
S> SSL_read(), SSL_ERROR_ZERO_RETURN
S> SSL_shutdown()
C> SSL_shutdown(), return 1
S> SSL_shutdown(), return 1
C> closesocket() (FD_CLOSE)
S> closesocket() (FD_CLOSE)

[darkone]

Is FFXP using method I described for receiving data? It should be waiting SSL_read() to return SSL_ERROR_ZERO_RETURN error, instead of waiting for FD_CLOSE socket event to occur.

[bigstar]

I'm 99% sure the problem has been resolved. I'll find out later today when Midknight comes around and sets up ioFTPD for me to test.

If so expect a new build released later today.

[bigstar]

It appears the problem has been resolved :cool:

This fix has been included in the public beta
http://forum.flashfxp.com/showthread.php?s=&postid=12650