Ftp has problems

[gyugyu13]

Hi there,

I experience strange behaviour on Win7 Ultimate 64 bit.
(the ftp is a hardware ftp, an old one, connected to the net)

With version 23 and now with 25:
After connect, I can change directory 3 times only and then hangs.
Disconnect rises a msgbox saying "Command in progress".
Change drive, get back to "O:" drive, msgbox "Connection lost, reconnect?" ->Yes -> msgbox "IP address not found".
BUT: After connect, change dir and disconnect then reconnect, no problem after the next boot.
Copy to ftp doesn't work just stay on copy, "Cancel" -> label changes to "Data connection lost!" Unresponsive for 10s.
Upload works.

With version 24: It worked with unlimited dir changes, but no copy to the ftp worked. After F5 -> "User Interrupt" Yes/No -> No ->Remote file created, that's it.
Download worked.

Thanks Gyula

PS: 215 UNIX Type: L8
FEAT
211-Extensions supported:
XPWD
EPRT
EPSV
ALLO
APPE
MDTM
XCWD
XCUP
XMKD
XRMD
REST
SIZE
211 End
HELP SITE
214 Syntax: <sp> string
OPTS UTF8 ON
500 Unknown command: "OPTS UTF8 ON"
Connect ok!

[ghisler(Author)]

Sounds like a firewall problem. Try using passive mode: Ctrl+F - Edit connection - Passive mode.

[gyugyu13]

Tried with and without passive mode.

[Sob]

It does not make sense. It's some kind of problem with data connections, but it all seem too random. E.g. working directory changes, but non-working upload, but in both cases it uses exactly the same type of data connection, so why would one work and not the other?

Is it perhaps possible that there's some "inteligent" content-inspecting firewall on the way? Not that I'd have an explanation why it would behave differently with various TC betas.

What about different FTP clients (FileZilla, etc...) on the same computer, do they work fine?

[gyugyu13]

Ok, I have two different locations for accessing the same ftp.
One is a Win Vista Home Edition, used with released versions, never experienced problems. DLINK router.
The other one is Win 7 Ultimate 64 bit. Always tried different versions. Problem started with the 64 bit, before I have 32 bit Win7 Prof not problem whatsoever. Linksys with DD-WRT. Windows firewall.

And interestingly with this particular ftp, not any other ftp. I read a similar ftp problem a while ago, can n't recall when. I thought it will help you localize the problem between versions.
I'm copying basically the same stuff up and down, but the problem is always changing the directory, which is almost always the same.

I've never tried any other ftp client, it was so handy to
use TC.

[ghisler(Author)]

You need to post a log of the failing transfers, otherwise I can't help you, sorry.

[gyugyu13]

So here is the log. I changed the actual ftp ip address, the rest is the same.

----------
Connect to: (04/18/2012 11:00:02)
hostname=103.10.4.40
username=Stephen
startdir=
103.10.4.40=103.10.4.40
220 ftp server ready.
USER Stephen
331 Password please.
PASS ***********
230 User logged in.
SYST
215 UNIX Type: L8
FEAT
211-Extensions supported:
XPWD
EPRT
EPSV
ALLO
APPE
MDTM
XCWD
XCUP
XMKD
XRMD
REST
SIZE
211 End
HELP SITE
214 Syntax: <sp> string
OPTS UTF8 ON
500 Unknown command: "OPTS UTF8 ON"
Connect ok!
PWD
257 "/" is the current working directory.
Get directory
TYPE A
200 OK
PORT 192,168,100,113,193,80
200 PORT 24.235.163.87:49488 OK
LIST
150 Data connection established.
Download
Waiting for server...
226 Directory list has been submitted.
CWD cishare
250 OK
PWD
257 "/cishare" is the current working directory.
Get directory
PORT 192,168,100,113,193,81
200 PORT 24.235.163.87:49489 OK
LIST
150 Data connection established.
Download
Waiting for server...
226 Directory list has been submitted.
CWD Releases - Remit SQL
250 OK
PWD
257 "/cishare/Releases - Remit SQL" is the current working directory.
Get directory
PORT 192,168,100,113,193,82
200 PORT 24.235.163.87:49490 OK
LIST
150 Data connection established.
Download
Waiting for server...
226 Directory list has been submitted.
CWD Install
250 OK
PWD
Cancel pressed!
PWD
Cancel pressed!
PWD
Cancel pressed!
PWD
Cancel pressed!

After trying to change to 'Install' it is dead.
The first Cancel pressed is actually a disconnect request, because nothing happened and Command in progress msgbox comes up after it.

[Sob]

This log shows something different than I thought it is, this one is actually non-responding control connection..

[gyugyu13]

Is it something I can take care of or it is the ftp, which needs some adjustment or somthing else?

[Sob]

Sorry, no bright all-solving idea comes to mind.

The control connection is established at the beginning and stays open for the whole time you're connected to server and normally it does not just break. The reasons for that to happen include timeout if not used (not the case here), bad network with big packet loss (it would be more random) or some "too clever" stateful firewall anywhere on the way (most likely, for the lack of better ideas).

Debugging firewall problems is not always easy. It depends a lot on how big control you have over both ends of connection. One easy test if some nosy firewall is doing something bad, is to temporarily move the server from standard port 21 to different one. For performance reasons, firewalls don't inspect all ports. So if it helps, you know what's causing it and have to find where it is. If you don't have control over server side, it's more complicated.

[gyugyu13]

Thanks for all of you.
As I said, I just thought I can help you to find something fishy. It works for any other ftp except this one so I can live with that.
Have a great weekend guys.

[ghisler(Author)]

Indeed you can't do anything on Total Commander's side with this problem - there is something seriously wrong with the network connection or the server, which causes the connection to die in the middle.

[gyugyu13]

Thank you guys again.
You were right. I did a new search on the Net and turned out, that there are issues with routers, not forwarding the ports in case of ftps.
Anyway, the solution was to remove all rules for TC and then create an inbound rule on the firewall enabling not just 20,21 but all ports (because the ftp data port can change). It did the trick.
Thanks again. Have a good weekend.
Gyugyu

[Dalai]

Anyway, the solution was to remove all rules for TC and then create an inbound rule on the firewall enabling not just 20,21 but all ports (because the ftp data port can change). It did the trick.

That's what FTP passive mode was made for, so I recommend you use that (set it in FTP connection details) instead of forwarding every port.

Regards
Dalai

[Sob]

Passive mode was the first suggestion and the reply was:

Tried with and without passive mode.

Also if the problem was with active mode and ftp*s* (as said in last reply), it would require very specific conditions (existing manually forwarded port range only partially covering the port range used by TC) to have problem with only some data transfers and not all, otherwise it would always get stuck right on the very first directory listing.

On top of that, the posted log does not show ftps connection and not even problem with data connection. The whole active/passive mode thing should not matter here.

So for me, it's not clear at all. :)

Anyway, passive mode (PASV command instead of PORT) is definitely good idea. It's most compatible and does not require any *inbound* firewall exceptions or forwarded ports on client side. Really, none at all, not even ports 20, 21. It does require *outbound* access to any port, but as the default for most routers and firewalls is to allow all outgoing connections, it means no need for any additional configuration.