martin wrote:

Are you using the firewall on a client or a server? I assume that on the client, right?

Yes. I'm using the firewall on a client.

martin wrote:

Anyway, WinSCP is not using any special technique to find a free port to open.

Thank you for your information.

martin wrote:

It actually does not open any port in passive mode. It just opens an outbound connection to the FTP server, that obviously gets a local port assigned. But that's done automatically by an operating system.

I think so.

SOURCENEXT CORP. promised to investigate.
I will contact you, as soon as a result is known.

I appreciate your cooperation.

Are you using the firewall on a client or a server? I assume that on the client, right?
Anyway, WinSCP is not using any special technique to find a free port to open. It actually does not open any port in passive mode. It just opens an outbound connection to the FTP server, that obviously gets a local port assigned. But that's done automatically by an operating system.

Thank you always.

It turned out that this phenomenon is related to the firewall of "super security zero" (https://www.sourcenext.com/product/security/zero-super-security/ (Japanese)) of the security software of SOURCENEXT CORP.
This software is the software based on "Bitdefender Internet Security" of a bit defender company.
If a setup of stealth mode of this software is turned ON, the fault phenomenon of WinSCP will occur, and if a setup is turned OFF, a fault phenomenon will not occur.
Stealth mode makes its own PC not visible from other PCs.
SOURCENEXT CORP had said "In stealth mode, it do not return a ping response. And it blocks " Windows Network Discovery"".

SOURCENEXT CORP had said "This Windows Network Discovery is being used for some FTP software. It is because the random and open port which can be used may be looked for. If stealth mode is that of "ON" setup, the FTP may not operate normally in this way."

However, if setup (<invalid link removed by admin> TC=windows-7 (Japanese)) of the control panel of Windows is "WindowsNetwork Discovery is not effective.", the fault phenomenon of WinSCP did not occur.

Would you teach me the following things about FTP upload in the passive mode of WinSCP?

• Is WinSCP using "Windows Network Discovery"?
  
• Is operation changed by whether setup of "Network Discovery" of Windows of WinSCP is effective, or it is invalid?
  

Thank you for your consideration.

Thank you for your reply.

I consulted with the rental server contractor and investigated the cause succeedingly.

• Reappearance Existence in Another PC
  
  With another PC (notebook PC of Windows 7 32bit), I tried on WinSCP (Ver5.5.4).
  As a result, fault occurred.
  
  For this reason, I think that it is not a problem peculiar to client PC.
  
  
• Reappearance Existence in Another FTP Software
  
  With PC (desktop PC of Windows 7 Ultimate 64bit) currently used usually, I tried on FFFTP (Ver1.98g2) again.
  As a result, fault did not occur.
  
  With PC (desktop PC of Windows 7 Ultimate 64bit) currently used usually, I tried on FileZilla (Ver3.8.1).
  As a result, fault occurred.
  
  For this reason, since it generates also in Filezilla although it does not generate in FFFTP, it is not likely to be a soft bug peculiar to WinSCP, either.
  
  
• About TIME_WAIT
  
  In addition, when it tried on FFFTP, it checked by netstat -n, but so many TIME_WAIT status remained that it could not display on a command prompt.
  
  As a result, it is not the cause of this fault that the thing of TIME_WAIT status remains.
  About this, I think that it is right what you were said.
  I am sorry.
  

These results were reported to the rental server contractor.
I will report immediately after getting a reply.

Thank you for your consideration.

Well that's normal, isn't it? TCP connect remain in TIME_WAIT state few minutes after it is closed, to keep the local port reserved to avoid mixing stray data.

To the trial, the file of three was uploaded by WinSCP.

Then, when checked by the netstat -n command, it turned out that the following session remainder occur.

192.168.1. XX: The Local IP Address of the Client.
210.XXX.XXX.XX : The Global IP Address of the Server.

Thank you for your consideration.

heiji wrote:

Would you confirm whether a session is disconected normally when a large number of files were uploaded by WinSCP?

I believe it is.

I am sorry that my reply is slow.

Then, I had tried to contact the company which has administered the server.

According to investigation of the company which has administered the server, the following things are considered to be the causes.
When I upload files, the number of sessions has reached the upper limit of the firewall of the server.
By the firewall of the server, the number of sessions per 1IP is restricted to 256 as measures over the attacks (DOS attack etc.) from overseas.

The following thing is a guess.
When I upload files, the connected session is not disconnected normally but remains.
As the result, many sessions have been connected and reach to 256 of upper limit.
If it is right, we can explain that a problem occurs by WinSCP without a problem occurring by FFFTP.

Would you confirm whether a session is disconected normally when a large number of files were uploaded by WinSCP?
Furthermore, please tell me the means to confirm whether the session remainder occurs.

Thank you for your consideration.

heiji wrote:

Before the connection initiation (three-way handshaking) of a data connection is completed, does WinSCP send STOR command through the control connection?

No. WinSCP connects only after sending the STOR command.

Sorry.

I attached Figure.

I want you to check the following things.

Before the connection initiation (three-way handshaking) of a data connection is completed, does WinSCP send STOR command through the control connection?

Can this be checked with the log file of WinSCP?

Thank you for your consideration.

Sorry, I do not understand what you want me to check.

Thank you.
As I mentioned in the previous post, I think that a possibility that packet size is the cause is low.

Before the connection initiation (three-way handshaking) of a data connection is completed, isn't the STOR command transmitted through the control connection at WinSCP?
When timeout occurs, the response ( 150 Opening BINARY mode data connection for (file name)) to the STOR command has not received from a server.

Can this be checked with the log file of WinSCP?

Thank you for your consideration.

WinSCP does not control IP packet size at all. It is leaves that on OS.

We announce you subsequent results of an investigation.

In the server of the course which poses a problem, it turned out that a response is returned to ping to 996Byte, and a response is not returned to ping of 997 or more Byte in the time of usual.

So, it was changed to 576 minimum from 1500 the default MTU setting in my router, but had no effect.

For this reason, even if I have a setup of MTU offered by WinSCP, I think that a possibility that a problem will be unsolvable is high.

In FFFTP which is major FTP client software in Japan, it is in the situation by which it is not carved why doesn't a problem occur but it generates in WinSCP.

I am happy when you can keep under review.

Thank you for your reply.

MTU value of the WinSCP (Maximum Transmission Unit) What bytes?
If it is fixed, do you have any plans in the future, provided the settings to the variable?

In case you're wondering, in FFFTP is a FTP client software major in Japan, there is information and is in accordance with the setting of the OS.

Windows7 MTU default1500
　　netsh interface ipv4 set subinterface "xxxxxxxx" mtu = 1448 store = persistent

Thanks for your investigation. I really helps. Unfortunately, WinSCP does not have such setting.

There was an interim report of the results of an investigation from the communication career (career A) which I have made a contract of.
It is said that the problem arose when ping of the packet which exceeds 1024Byte was performed to the server which the communication career (career B) of a course manages.
However, it is said that the reply from the career B was a reply "such regulation is not carried out and has no problem" when the career A asked the career B.
For this reason, it is in a situation without the measure which the career A adopts.

Is it possible to add the setting item which restricts the maximum packet length in the case of FTP by WinSCP?

I am pleased if this information is useful.

Thank you for your consideration.

The WinSCPXXXXtrace.log file was attached.

WinSCP23CCtrace.log(= WinSCP23CCtrace_1.log + WinSCP23CCtrace_2.log) :
It logged in by FTP, many files were uploaded and a timeout error occurs.

WinSCP1E04trace.log
After the above-mentioned timeout error occurs and the server of the course to the rental server of the object of FTP will become status of no response, it becomes impossible by carrying out FTP login.

Thank you for your consideration.

Please forgive in awkward English.

Thanks for the log.
I have sent you an email with a debug version of WinSCP to address you have used to register on this forum.

The English WinSCP log file was attached.
Thank you for your consideration.

Can you please switch WinSCP to English before generating a log file?

WinSCP: Timeout occurs in upload of files of Passive Mode.（It occurs, whenever it uploads many files. ）

WinSCP.log
ex) Timeout occurs 2014-05-05 10:26:31.731

When this timeout occurs, the server of the course to the rental server of the object of FTP will become status of no response about 30 minutes.
IP address of the server of the course is 154.34.240.206 and "Yahoo" which is this server's administrator is "Softbank" which is a major Japanese telecommunications service operator.

20140505_2.txt
ex) line.37 : time out of "tracert"
line.128 : time out of "ping"

Although it may be felt as a server's problem, judging from the above-mentioned contents, a problem does not occur in case of FFFTP which is a major FTP client software in Japan. (Reference: FFFTP.log)

Can you check whether there is any problem in the action after WinSCP receives "227 Entering Passive Mode" just to make sure?

Thank you for your consideration.