7.57a FTP Hang Under Win7 x64

[N2Cheval]

After installing the 7.57a, when one tries a FTP connection the process hangs.

The Progress window stays open with the Title of "Download", message "Get Directory" and the Cancel button showing.

When you press Cancel, the connection side is blank and the connection button says Disconnect.

The connection log looks good until
150 Opening ASCII mode data connection for /bin/ls.
Download
Cancel Pressed!

The FTP Log is as follows:
xxx = destination machine ip address
----------
Connect to: (13/03/2012 3:06:05 PM)
hostname=192.168.0.xxx
username=Administrator
startdir=
220 Microsoft FTP Service
USER Administrator

[Flint]

N2Cheval
Try passive mode.

[N2Cheval]

That fixed it. Thanks.

[Hacker]

[mod]Moved to the English forum.

Hacker (Moderator)[/mod]

[N2Cheval]

Not to be happy with a work-a-round; another colleague running Win7 x64 can connect to the same machine via FTP with the TC v7.57a default active FTP settings.

Could my Total Commander install be corrupt? Are there any registry settings or the like I can check?

How about instructions for a manual complete un-install and re-install?

[Hacker]

N2Cheval,

Could my Total Commander install be corrupt?

Nope. Is there a firewall on your or the target computer? If yes, try deactivating it for testing purposes.

Roman

[ghisler(Author)]

I also think that it's caused by a local firewall. If you allow a program, and then update that program, the firewall will see that it was changed and automatically block it. You will need to allow the new version too.

[Sob]

@ghisler(Author): Have you thought lately about finally changing the default mode to passive? Just assume pasvmode=1 for clean installs where user has not set it yet.

Today's typical network connection uses NAT. Many ISPs have to put their customers behind it and if they don't, almost all users will have it anyway, thanks to their wi-fi routers. So far it's not so bad. You just have to add otherwise unnecessary local firewall exception for TC for incoming connections and it will work. But there is also (slow) move towards more security, i.e. FTP is not safe, use it with SSL. But when you do it, TC with default settings simply breaks (from user's POV). With passive mode as default it would work just fine.

I made you this nice comparison of active and passive mode compatibility once in the past.

[Flint]

I support the suggestion. Users fall into this trap far too often to ignore the problem any longer.

[N2Cheval]

ghisler: You are correct; it was the firewall on my local machine.

The other person had added a new exception to the local computer firewall after their last upgrade, so it's not something that happens often enough to remember unless you get the problem.

Passive mode by default does sound like an appropriate option if the upgrade installer doesn't also update the local Windows firewall in the install.

[ghisler(Author)]

Have you thought lately about finally changing the default mode to passive?

Yes I have - I changed that in the past during one beta version, and got a lot of feedback from users where it didn't work at all - either due to a firewall on the server side, or a server not supporting passive mode! I remember that the mainframe at the University where I studied didn't support passive mode at all.

[N2Cheval]

ghisler: Fair enough. Ok then if the local firewall cannot be updated on each install, then (without the clippy nightmare returning) what about detecting the timeout and raise a suggestions window or link to a page that offers suggestions on common problems when FTP Active mode is set?

At the best is reminds the knowledgeable user of doing that part and/or other users self fixing the problem. At worse it's better than thinking TC is buggy and creating a false positive bug fix request here.

Yes, they could make things worse in the firewall (also true in general use), but better than not using this great product at all.

[Sob]

... got a lot of feedback from users where it didn't work at all - either due to a firewall on the server side ...

If server software agrees to passive mode, but the incoming data connections are blocked by server machine's firewall, then the FTP server as whole is clearly misconfigured. Making it work for user is a plus, but IMO the normal correctly configured scenarios should have priority.

... or a server not supporting passive mode!

Interestingly, even though PASV command is in RFC959 from 1985, it's not the requirement for minimum implementation. So it's possible without being a bug. Who would think that. :) But such server should return 502 command not implemented or at worst 500 command unrecognized. Anything else would not make sense. So it can be easily detected.