Socket error 10054 connection reset by peer как исправить

I receive the ftp socket error 10054 when I try to connect to FTP for an upload. Please fix this problem.

That was a recent support ticket received from one of our customers as part of our Dedicated Support Services.

This FTP error occurs when the existing remote connection is forcibly closed by the remote host.

Today, let’s see the top 6 reasons for the ftp socket error 10054 and how our Support Engineers fix them.

FTP socket error 10054 – A Brief explanation

A socket is the endpoint of client-server communication.

FTP socket error 10054 indicates that the remote host has forcibly terminated or reset the existing connection of the FTP client. And, users see the complete error message as shown below.

Upload failed.
Socket Error # 10054
Connection reset by peer.

This broken connection can be at the FTP server side or at the user’s side. So, our Support Engineers primarily check the server logs to determine if this is a network error at the client side or at the server side.

FTP socket error 10054 – Reasons & Solutions

Now, let’s see the main causes of this error and how our Support Engineers rule out each possibility to fix this problem.

1) Remote server issues

FTP socket error 10054 can occur due to the problems at the remote server end. This error usually occurs during the following scenarios.

• The remote host is suddenly rebooted or restarted.
• Network interface of the remote server is disabled.
• User’s account on the remote server is disabled or restricted.
• Too many users logged on to the server.

How we fix?

Firstly, our Support Experts check the availability of the remote host using the ping command.

ping test.remotehost.com

In addition to that, we check the uptime of the server to verify that a reboot has been initiated on the server.

uptime

Thus, we can confirm whether the server reboot created problems for the user. Moreover, we ensure that the network settings on the server are intact and the FTP user is allowed to connect to the remote host.

2) Invalid FTP host

Once we’ve confirmed that there are no issues at the remote host, we then check the FTP client settings. And, one of the common reasons for this error is the use of invalid FTP host address.

Users should enter the hostname details in the FTP host field to initiate a connection. For example, customers usually give it as ftp.servername.com or servername.com.

However, a typo in the FTP hostname or missing hostname field can result in this error. Even a single additional space in the FTP hostname can create problems.

How we fix?

Firstly our Support Experts confirm the DNS connectivity of the FTP host using the dig command.

dig ftp.servername.com

Further, we double check and confirm that customer is using the correct FTP host address in their FTP client.

3) Firewall restrictions

Similarly, firewalls can act up and break the FTP connection. Moreover, Antivirus or Antispyware tools can act as a second layer firewall and close the connections. Even the firewalls at the ISP end, firewall on a router can block connections through FTP ports.

How we fix?

In such cases, we ask the customers to temporarily disable the security applications such as Windows firewall, Antivirus, etc. one by one on their system. This helps us to identify the application that’s exactly creating problems and fix it’s settings.

Likewise, to resolve the firewall issues at the network level, our Support Engineers ask the customers to disable gateways and routers to establish a direct connection. Thus, we can verify if the problem lies at the intermediate level. Once we’ve confirmed that the problem is with the intermediate devices, we ask the customers to work with their ISPs to configure ISP firewall to allow connections to FTP ports.

[Messed up firewall rules on your server? Click here and get one of our Server Experts to fix your firewall rules.]

4) Issues with File transfer mode

File transfer can happen in 2 types – Active and Passive mode, and most of the FTP clients use Passive mode by default. However, some remote servers accept the connections only in Active mode or PORT mode resulting in this error.

How we fix?

The steps to enable Active mode differs based on the FTP client software used by the customers.

So, our Dedicated Engineers get the FTP client details from the users, and help them navigate the settings and enable Active mode. For example, we enable Active mode in Filezilla from Site Manager > Transfer settings > Transfer mode.

5) Connection timeout issues

Ftp socket error 10054 occurs when users try to upload relatively large files which conflict with the internal timeout settings of the FTP client. In other words, when user uploads a large file, the upload process may fail if it’s not completed within the predefined connection timeout limit.

How we fix?

In such cases, we recommend users to increase the connection timeout settings in their FTP client. For example, we increase the connection timeout limit from Edit > Settings > Connection > Timeout > Timeout in seconds.

Alternatively, in some cases we disable this timeout value by making it’s value as 0.

6) Advanced FTP client settings

Some of the FTP clients such as CuteFTP use advanced configurations which may not be compatible with the remote server you’re connecting. For example, some remote servers may be configured to allow only a limited number of connections or sessions. However, some users configure their FTP client to set large number of concurrent file transfers. In such cases, remote server terminates the connection and result in ftp socket error 10054.

Similarly, users set large values for send and receive buffer sizes in their FTP client settings. However, this may conflict with the remote server values and causes problems.

How we fix?

In such cases, our Dedicated Engineers help the customers navigate the FTP client settings and limit the number of concurrent connections. For example, on CuteFTP client, we change this parameter from Tools > Global options > Connection > Per site max concurrent transfers >Transfer.

Moreover, we tweak the send and receive buffer size values accordingly. For instance, we change the buffer size from Tools > Global options > Transfer in CuteFTP.

[Need help in resolving your FTP issue? Our Support Experts can help you here.]

Conclusion

In short, ftp socket error 10054 can occur due to remote server issues, firewall restrictions, and more. Today, we’ve discussed the top 6 reasons for this error and how our Dedicated Engineers fix them.

var google_conversion_label = “owonCMyG5nEQ0aD71QM”;

I am working on a Windows (Microsoft Visual C++ 2005) application that uses several processes
running on different hosts in an intranet.

Processes communicate with each other using TCP/IP. Different processes can be on the
same host or on different hosts (i.e. the communication can be both within the same
host or between different hosts).

We have currently a bug that appears irregularly. The communication seems to work
for a while, then it stops working. Then it works again for some time.

When the communication does not work, we get an error (apparently while a process
was trying to send data). The call looks like this:

send(socket, (char *) data, (int) data_size, 0);

By inspecting the error code we get from

WSAGetLastError()

we see that it is an error 10054. Here is what I found in the Microsoft documentation
(see here):

WSAECONNRESET
10054

Connection reset by peer.

An existing connection was forcibly closed by the remote host. This normally
results if the peer application on the remote host is suddenly stopped, the
host is rebooted, the host or remote network interface is disabled, or the
remote host uses a hard close (see setsockopt for more information on the
SO_LINGER option on the remote socket). This error may also result if a
connection was broken due to keep-alive activity detecting a failure while
one or more operations are in progress. Operations that were in progress
fail with WSAENETRESET. Subsequent operations fail with WSAECONNRESET.

So, as far as I understand, the connection was interrupted by the receiving process.
In some cases this error is (AFAIK) correct: one process has terminated and
is therefore not reachable. In other cases both the sender and receiver are running
and logging activity, but they cannot communicate due to the above error (the error
is reported in the logs).

My questions.

• What does the SO_LINGER option mean?
• What is a keep-alive activity and how can it break a connection?
• How is it possible to avoid this problem or recover from it?

Regarding the last question. The first solution we tried (actually, it is rather a
workaround) was resending the message when the error occurs. Unfortunately, the
same error occurs over and over again for a while (a few minutes). So this is not
a solution.

At the moment we do not understand if we have a software problem or a configuration
issue: maybe we should check something in the windows registry?

One hypothesis was that the OS runs out of ephemeral ports (in case connections are
closed but ports are not released because of TcpTimedWaitDelay), but by analyzing
this issue we think that there should be plenty of them: the problem occurs even
if messages are not sent too frequently between processes. However, we still are not
100% sure that we can exclude this: can ephemeral ports get lost in some way (???)

Another detail that might help is that sending and receiving occurs in each process
concurrently in separate threads: are there any shared data structures in the
TCP/IP libraries that might get corrupted?

What is also very strange is that the problem occurs irregularly: communication works
OK for a few minutes, then it does not work for a few minutes, then it works again.

Thank you for any ideas and suggestions.

EDIT

Thanks for the hints confirming that the only possible explanation was a connection closed error. By further analysis of the problem, we found out that the server-side process of the connection had crashed / had been terminated and had been restarted. So there was a new server process running and listening on the correct port, but the client had not detected this and was still trying to use the old connection. We now have a mechanism to detect such situations and reset the connection on the client side.

Я так понял, что вы, дама, под вендой решились на sendmail… 🙂 Не вопрос!
Чисто для пробы. 🙂 Взял фейк sendmail отсюда: http : // www . glob . com . au / sendmail /
Сделал конфиг:
[sendmail]
smtp_server=smtp.mail.ru
smtp_port=2525 (или просто 25 – не критично, работает и там, и там)
smtp_ssl=auto
default_domain=mail.ru
error_logfile=error.log
debug_logfile=debug.log
auth_username=ЛОГИН@mail.ru
auth_password=ПАРОЛЬ
pop3_server=pop.mail.ru
pop3_username=ЛОГИН@mail.ru
pop3_password=ПАРОЛЬ
force_sender=ЛОГИН@mail.ru
hostname=mail.ru
Письмишко такое:
From: ЛОГИН@mail.ru
To: КОМУ-ТО@mail.ru
Subject: Срочное Письмо!

Содержание срочного письма

И оно так и дошло. 🙂
У вас, наверное, прикол или в самом sendmail-е, или в капризах провайдера. Поменяйте утилиту. . Потому что если её брать отсюда http : // webi . ru / webi_files / sendmail_ssl . html, то в аккурат 10054 выходит. При тех же условиях.