Forum » .NET assembly / COM library »

Post a reply

Options
Add an Attachment

If you do not want to add an Attachment to your Post, please leave the Fields blank.

(maximum 10 MB; please compress large files; only common media, archive, text and programming file formats are allowed)

Options

Topic review

Filip

Two proofs:
1. I disabled MLST with FtpUseMlsd and problem still occurs with FileZilla server
2. I have two different linux servers, one uses CWD and one MLST, and both are working...
martin

Sorry, maybe I miss or forgot something, but how do you know that "MLST is not a problem"? Why do you now focus on the MLSD/LIST
Filip

Well, we know now that MLST is not a problem.
It looks that problem is (maybe) occurance of many same sequences ?

So, response 150 message doesnt matter as long as it is all 150?
I noticed another difference while initiating the transfer - different order of 150 command and establishing TLS:
FileZilla server (not working): 
< 2021-10-05 17:08:24.185 227 Entering Passive Mode (217,16,185,200,226,47)

> 2021-10-05 17:08:24.185 MLSD

. 2021-10-05 17:08:24.185 Connecting to 217.16.185.200:57903 ...

. 2021-10-05 17:08:24.204 Session ID reused

. 2021-10-05 17:08:24.204 Using TLSv1.2, cipher TLSv1.2: ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA, ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AESGCM(256) Mac=AEAD

. 2021-10-05 17:08:24.204 TLS connection established

< 2021-10-05 17:08:24.205 150 Opening data channel for directory listing of "/"

. 2021-10-05 17:08:24.215 Data connection closed

< 2021-10-05 17:08:24.216 226 Successfully transferred "/"

GLFTPD server (working): 
< 2021-10-04 17:51:22.295 227 Entering Passive Mode (46,36,41,244,117,132)

> 2021-10-04 17:51:22.295 LIST -a

. 2021-10-04 17:51:22.295 Connecting to 46.36.41.244:30084 ...

< 2021-10-04 17:51:22.336 150 Opening ASCII mode data connection for directory listing using SSL/TLS.

. 2021-10-04 17:51:22.397 Using TLSv1.2, cipher TLSv1.2: ECDHE-ECDSA-AES256-GCM-SHA384, , ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AESGCM(256) Mac=AEAD

. 2021-10-04 17:51:22.397 TLS connection established

< 2021-10-04 17:51:22.398 226- [Ul: 0.0MiB] [Dl: 0.0MiB] [Speed: 0.00KiB/s] [Free: 6530MB]

< 2021-10-04 17:51:22.456 226  [Section: DEFAULT] [Credits: 14.6MiB] [Ratio: UL: 1:3 | DL: 1:1]

Other (NAS) linux server (working): 
< 2021-10-04 19:50:55.696 227 Entering Passive Mode (xxx).

> 2021-10-04 19:50:55.696 MLSD

. 2021-10-04 19:50:55.696 Connecting to xxx ...

< 2021-10-04 19:50:55.723 150 Opening ASCII mode data connection for MLSD

. 2021-10-04 19:50:55.728 Session ID reused

. 2021-10-04 19:50:55.729 Using TLSv1.2, cipher TLSv1.2: ECDHE-RSA-AES128-GCM-SHA256, 2048 bit RSA, ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AESGCM(128) Mac=AEAD

. 2021-10-04 19:50:55.729 TLS connection established

. 2021-10-04 19:50:55.752 Data connection closed

< 2021-10-04 19:50:55.752 226 Transfer complete

So working servers do 150 first and then establishing TLS.

Any thoughts?
Have you noticed any differences?
Anything else I can check?
Thanks,
Filip
martin

I do not think that the different message can make any difference. Particularly, when it is not related to the MLST command.
The other server does not use/support MLST command at all.
You can try preventing use of MLST by setting FtpUseMlsd=1 raw session settings:
https://winscp.net/eng/docs/rawsettings#ftpusemlsd
I do not expect much from that.
Filip

Hello,
I am attaching session log for other FTP server, which is working fine checking if directory exists (tried in 1000x loop).
Appreciate if you can take a look.

I checked the differences and only thing I found is:
150 Opening data channel for directory listing of "/"

vs
150 Opening ASCII mode data connection for MLSD

Whats the difference internally and can that be a cause of the problem, that within data channel FW is blocking and ASCII mode not?

Thanks in advance, nice day,
Filip
martin

We cannot really answer that. Though if you post log from the working server, we can check what is different about it. But it will unlikely help you in any case.
Filip

No it isnt. It looks rather related to amount of communication (no files data).
But as I said, it works without a problem using other FTP Server.
So why is Windows FW blocking only some FTP Servers and some not? Is there any different type of communication with different servers?
martin

Isn't it related to the length of the session? Doesn't the firewall close the connection after a fixed amount of time?
Filip

No, it doesnt matter whether I check for existing or nonexisting folder.
Problem is I get WinSCP.SessionLocalException: 'Session has unexpectedly closed' always after specific number (in case of existing folder /backup2 it is always 393) of checks.
It looks like it depends on amount of information transferred, because if folder does not exist it takes more checks to fail than for existing folder (there is more data transferred for one check).
This only happens with FileZilla server and Windows firewall on. When I turn FW off during login phase it finishes fine (doesnt matter if I turn FW back during transfers and checks).
And also there is no problem with other FTP server (linux one), even with windows firewall on.
Session log attached.
Thanks, nice day
Filip
martin

Re: Getting Disconnected from server after many MLST commands

Do I understand correctly that you start getting 550 response from the server for existing files? And you are using FTP over TLS? I do not think that's possible. The firewall cannot modify the response from the server, when the connection is encrypted.

Please attach a full session log file showing the problem (using the latest version of WinSCP).
Filip

Getting Disconnected from server after many MLST commands

Hello,
I have a problem using WinSCP .NET.
As I thought it was rather server problem I asked at first here (Filezilla server support):
https://forum.filezilla-project.org/viewtopic.php?t=53978
As you can see, it turns out to be a Windows firewall problem, but question is why is not firewall blocking it when using other FTP server?
Can I do something about it from your client point of view?
Thank you,
Filip

Documentation

Support

Associations

Follow Us