FXP-Bug in v4.1 Final

Hi,

my friend (also owner of flashfxp) and i are using the newest FlashFXP v4.1.1 Build 1651 Final on Windows 7 SP1 x64 Enterprise German and we recognized a fxp problem since v4.1 beta, but didn't care to report it till now. IT SEEMS that it is ONLY releated to this specific windows ftpd OR ANY windows ftpd, the bug does NOT occur on linux ftpd's!

i have Gene6 FTP Server installed which can be found here: http://www.g6ftpserver.com/en/home

i upgraded it to the latest version (v3.10.0.15) which can be found here: http://www.g6ftpserver.com/forum/ind...showtopic=3995

before you read on, note that the described bug below didn't occur in any version prior to v4.1 beta and nothing was changed in the settings of the ftp server NOR flashfxp itself! for us this smells like if there was something changed in flashfxp fxp routine and most likely the bug has to be found there, but hey, we ain't programmers of course

Description:

a) on the left window my friend logs on to SOME GUY'S ftp (glftpd and/or other linux ftp)

b) on the right window he logs on to MY ftp (gene6 ftp v3.10.0.15)

c) he tries to fxp a file from ftp left to ftp right (some guy to me)

d) the transfer starts but then the problem occurs as you can see on this screenshot: http://img7.imagebanana.com/img/rpfw7zrz/ffxpbug41.png

i marked the Calculating info with red since it never showed up EVER in any flashfxp version before.

what happens is that the file was transferred but other files that are queued do not continue to get transferred anymore (flashfxp just hangs). if he hits cancel and refreshes the dir listing, the file was transferred successfully, even though the log says it wasn't! see here:

Transfer Failed: blabla.jpg
Transferred 0 Files (0 bytes) in 9 seconds (0,0 KB/s)
1 File Failed

to clarify the "hanging": flashfxp does not crash, it just is stuck as in what you can see on the screenshot.

i hope that this information is enough to find the problem.
please don't come up with suggestions like "just change the ftpd then" since that is no solution for me. it worked before as i said so even if this is not a bug, there must be a workaround for this?!

If you leave FlashFXP hanging like that, does it eventually timeout?

Post session log to see what exactly is happening there.

Hello,

I am quite familiar with gene6 and we use it for the majority of our testing. In my opinion its one of the best FTP servers for windows.

During the first site to site transfer FlashFXP will not be able to provide any estimated transfer speed/time remaining, etc. Instead of displaying nothing the text was changed to display calculating, this simply gives the user some type of indicator as to why no transfer speed is shown.

This isn't a bug nor a problem.

As for the transfers hanging, Something else is going on but I will need to see a copy of the session log to better understand the problem. Assuming the log shows anything at all.

When you perform a site to site transfer the client acts as the middle-man sending the commands to each server and waiting for the proper replies with the actual transfer being performed directly between the two servers. The only indication FlashFXP has that the transfer has completed is when the server returns a reply.

What I suspect is that perhaps FlashFXP isn't receiving the reply and is left holding the bag, FlashFXP will wait forever because it would be impractical to place any time constraint on the transfer.

The most common reason for FlashFXP not getting a transfer complete reply is due to a firewall or router silently closing the connection. Firewalls and routers will often close idle connections after a certain period of time. P2P file sharing applications can increase the burden on these and cause idle connections to close more frequently.

I would recommend testing a small file, something just a few KB and see if that works and go from there.

FlashFXP has a feature that allows you to "send NOOP command during transfers" this feature was added to resolve these type of issues but its not compatible with all FTP servers.

the session log shows nothing and using the option with noop's didn't help either

Did you try transferring a small file?

Perhaps monitoring the ftp session from the server side might reveal more information, I know that gene6 provides this ability. Perhaps the commands are being sent but never reach FlashFXP, or maybe there's some other error.

I have not been able to reproduce this issue, perhaps it might be easier if you could make me a test account on your ftp server to try and duplicate the issue.

Do you know what FTP server software is being used as the source?

Hi,

i can confirm the behavior described by MHJ. Im running the same FlashFXP build and also Windows 7 x64. Except one thing that this happens also when i transfer files from a *nix system (ProFTPD) also. Therefore it seems that FlashFXP always hangs up on the
226 response from the source server.

Best regards.

Edit:
The NOOP during transfers does not fix this for me. But as bigstar suggested tiny files still works.

Originally Posted by IUnknown

Edit:
The NOOP during transfers does not fix this for me. But as bigstar suggested tiny files still works.

for me it doesn't matter what type or size of file i use, it doesn't work

Still need to see session log, otherwise it's just guessing.

I didn't have turned them on.

But it looked like this, nothing unusual. Maybe except the fact that the responses gets mixed up.

[R] PASV
[R] 227 
[L] PORT 
[L] 200 
[L] STOR
[L] 150 
[R] RETR 
[R] 150
[R] 226
[R] 226
[L] 226
[R] 226
[L] 226

This log is useless.
Do you want help or do you intentionally want to make this difficult and drag it out for a long time?
Post a full timestamped session log with failing transfers.
If you are so worried about exposing "sensitive" information, here's an example of how to provide useful logs http://www.flashfxp.com/forum/genera...ng-debian.html

Maybe you want to calm down for a moment, I'm trying to help. It's not about any "sensitive" information. As I wrote that I didn't have turned them on as these errors occured. At the moment it is not possible for me to reproduce because our servers are under maintenance.

i am too busy right now to assist with further information, all i can repeatly say is that downgrading to v3.6.0 Build 1240 resolves the problem for me and frankly i am too disappointed that v4 has this issue to put efforts like suggested above (access to my ftp to test fxp ability).

to me the this problem seems pretty much located by bigstar already, he mentioned

What I suspect is that perhaps FlashFXP isn't receiving the reply and is left holding the bag, FlashFXP will wait forever because it would be impractical to place any time constraint on the transfer.

and

Perhaps the commands are being sent but never reach FlashFXP

sure, it's guessing, but why isn't looked into it, even if the problem is not reproducable on your end?

This isn't your typical issue, this can be an extremely complicated problem with multiple avenues that need to be explored before a solution can be reached.

First off, FlashFXP 3.6 runs in compatibility mode on Windows Vista and 7, applications running in compatibility mode are treated differently, they aren't subject to the same rules as a normal compatible application.

For example we had a customer who was unable to connect to any servers using FlashFXP v4.0 but was able to connect just fine using v3.6 on Windows 7, after extensive diagnostics we discovered that the issue was caused by a 3rd party web content filter that the customer was using to keep his kids safe. I contacted the author of the 3rd party application and they confirmed the issued. The 3rd party web content filter application was unable to block FlashFXP v3.6 because it was running in compatibility mode.

That being said.. The way FlashFXP handles FXP transfers has not changed much in v4.0, let alone in 4.1

We are just now starting to see customers migrate from FlashFXP v3.6 to 4.x, We delayed the roll out to 3.6 customers to avoid these types of problems, unfortunately no matter how hard we tried to prevent it, it does happen.

We rely on our customers as much as they rely on us. We do everything within our power to insure the highest level of quality in our software.

I am more than happy to work with you on this issue but this isn't something I can magically fix without your help.

As for your question,

I'm not quite sure how to answer it. I was speculating on what I thought might be happening and if this was the case then the problem is not in FlashFXP. I would look at other software on your computer that might be conflicting with FlashFXP v4.0.

Assuming that 3.6 and 4.1 are using the exact same settings (The best way to confirm is to compare the session log and pref/site settings) then I'm 90% certain that this issue is caused by something else conflicting with FlashFXP.

ok bigstar thanks for the info, i didn't know that. i will try to find some more time to get this fixed, please leave it pending here if possible

edit:

my friend changed a setting in flashfxp and guess what? it works now!
what does this tell you regarding the problem? is it any help to find the issue?

http://img6.imagebanana.com/img/kolkxmt9/changed.png

he changed from direct (fxp) to indirect btw. and only on MY ftp in site manager, the source ftp he uses still has direct (fxp) set!

The setting your friend changed was just introduced in the last build, its a new experimental option that performs an indirect site to site transfer. This method is provided as a work-a-round for servers that do not support/allow direct site to site transfers.

This setting is relative to the site its set on, any other site you transfer to/from with this site will be an indirect transfer.

This is not the solution or answer to your problem, this is just another option that we're planning on providing our customers.

Originally Posted by bigstar

This setting is relative to the site its set on, any other site you transfer to/from with this site will be an indirect transfer.

i understand that using this option means, any site to site transfer he does to my ftp involves his own home connection so the transfer goes like this: source ftp -> [download to] his cache on his home line -> [upload to] my ftp

is this correct or is it still a site to site transfer without his personal line in use?

yes it transfers the file over his own internet connection.

This issue was caused by the way FlashFXP was handling the server reply message on your server, it was sending 226<space> but in a recent change we trimmed trailing spaces from the end of lines, this invalidated the server reply.

You can download the fix via the update check within FlashFXP, you'll need to make sure you check for beta updates to download it.

very nice, it works after updating to the beta and switching back the setting to Direct (FXP)

thanks bigstar