Stunnel error 10054 reading data from server

An application may receive the «10054» error when the application receives data from a connection on a computer that is running Windows 7 or Windows Server 2008 R2 if a TDI filter driver is installed

Symptoms

Consider the following scenario:

You have a computer that is running Windows 7 or Windows Server 2008 R2.

A Transport Driver Interface (TDI) filter driver is installed on the computer. For example, a TDI filter driver is installed when you install McAfee VirusScan.

An application opens a TCP listening port to receive connections.

In this scenario, the application may receive the following error message:

WSAECONNRESET (10054) Connection reset by peer.
A existing connection was forcibly closed by the remote host.

This issue occurs because the TCP/IP driver does not close an incomplete TCP connection. Instead, the TCP/IP driver sends a notification that the TCP/IP driver is ready to receive data when the incomplete TCP connection is created. Therefore, the application receives an instance of the 10054 error that indicates that a connection is reset when the application receives data from the connection.

Resolution

To resolve this issue, install this hotfix.

Note This hotfix temporarily resolves this issue for application vendors before they migrate their implementation to Windows Filtering Platform (WFP). These application vendors use the TDI filter driver or the TDI extension driver (TDX) on a computer that is running Windows 7 or Windows Server 2008 R2.

Hotfix information

A supported hotfix is available from Microsoft. However, this hotfix is intended to correct only the problem that is described in this article. Apply this hotfix only to systems that are experiencing the problem described in this article. This hotfix might receive additional testing. Therefore, if you are not severely affected by this problem, we recommend that you wait for the next software update that contains this hotfix.

If the hotfix is available for download, there is a «Hotfix download available» section at the top of this Knowledge Base article. If this section does not appear, contact Microsoft Customer Service and Support to obtain the hotfix.

Note If additional issues occur or if any troubleshooting is required, you might have to create a separate service request. The usual support costs will apply to additional support questions and issues that do not qualify for this specific hotfix. For a complete list of Microsoft Customer Service and Support telephone numbers or to create a separate service request, visit the following Microsoft Web site:

http://support.microsoft.com/contactus/?ws=supportNote The «Hotfix download available» form displays the languages for which the hotfix is available. If you do not see your language, it is because a hotfix is not available for that language.

Prerequisites

To apply this hotfix, you must be running Windows 7 or Windows Server 2008 R2.

Registry information

Important This section, method, or task contains steps that tell you how to modify the registry. However, serious problems might occur if you modify the registry incorrectly. Therefore, make sure that you follow these steps carefully. For added protection, back up the registry before you modify it. Then, you can restore the registry if a problem occurs. For more information about how to back up and restore the registry, click the following article number to view the article in the Microsoft Knowledge Base:

322756 How to back up and restore the registry in WindowsTo enable the hotfix in this package, follow these steps:

In Registry Editor, locate the following registry subkey:

If you are running a 32-bit operating system, perform the following step:

Right-click the Parameters registry subkey, point to New, and then click DWORD Value.If you are running a 64-bit operating system, perform the following step:

Right-click the Parameters registry subkey, point to New, and then click DWORD (32-bit) Value.

Rename the new registry entry to TdxPrematureConnectIndDisabled and set the value to 1.

Restart requirement

You may have to restart the computer after you apply this hotfix.

Hotfix replacement information

This hotfix does not replace a previously released hotfix.

File information

The global version of this hotfix installs files that have the attributes that are listed in the following tables. The dates and the times for these files are listed in Coordinated Universal Time (UTC). The dates and the times for these files on your local computer are displayed in your local time together with your current daylight saving time (DST) bias. Additionally, the dates and the times may change when you perform certain operations on the files.

Windows 7 and Windows Server 2008 R2 file information notes

Important Windows 7 hotfixes and Windows Server 2008 R2 hotfixes are included in the same packages. However, hotfixes on the Hotfix Request page are listed under both operating systems. To request the hotfix package that applies to one or both operating systems, select the hotfix that is listed under «Windows 7/Windows Server 2008 R2» on the page. Always refer to the «Applies To» section in articles to determine the actual operating system that each hotfix applies to.

The MANIFEST files (.manifest) and the MUM files (.mum) that are installed for each environment are listed separately in the «Additional file information for Windows Server 2008 R2 and for Windows 7» section. MUM and MANIFEST files, and the associated security catalog (.cat) files, are extremely important to maintain the state of the updated components. The security catalog files, for which the attributes are not listed, are signed with a Microsoft digital signature.

Источник

OpenSSL errno 10054,connection refused, whilst trying to connect to our server

We are running a git server over https and didn’t have any trouble connecting because we all used visual studio to do so. Now someone wants to use the standard git bash and it fails to connect with the following error output.

I tried some different ciphersuites, nothing worked. Then it came to me that it might be that git doesn’t support ECDSA certificates yet. So I exchanged the ECDSA certificate for one with RSA. That also didn’t work.

Then I tried connecting with OpenSSL s_client with the following command:

This is the output from running the command:

I searched google for the error number 10054 and found it means connection refused. We use IIS 8.5 to supply the https endpoint for the git server. I can connect to the web environment through all webbrowsers and we can use the git server through the visual studio git interface. So I don’t think it’s a firewall issue. I’d like to know if anyone has experienced this problem before and if they could help us out here?

2 Answers 2

10054 is not connection refused, but connection reset by peer. This means, that a TCP connection was successfully established (s_client indicates CONNECTED) but when sending more data from the client to the server the server closed the connection without reading all the data (and send TCP RST back).

While this could be a firewall issue it could also indicate a problem at the server configuration, that is the server accepts the client but then cannot continue because of an invalid configuration. Such invalid configurations might be a missing permissions for the requested data, certificate without usable private key or others. I would suggest that you have a look at the server logs for more information.

I’ve also seen TCP RST with servers, load balancers or firewalls which do not understand current TLS versions and simply close the connection. Browsers work around this issue by transparently retrying with a lower TLS version. You might try if openssl s_client -ssl3 works against this server and you receive a certificate.

Источник

Ошибка Windows Sockets 10054

Причины возникновения
Причины этой ошибки разняться по своей «природе», но их объединяето то, что уже существующее (т.е. ранее установленое) соединение с клиентом разрывает сервер.

1. С версии 8.1.11 включен циклический перезапуск процессов, по наступлению интервала происходит автоматический перезапуск рабочих процессов rphost.

2. В некоторых случаях причиной ошибки могут стать утечки памяти.

3. Действия администратора в консоли (команда удалить пользователя)

4. Процесс rphost на серверном компьютере завершился аварийно

5. Ошибочное принятие высокой интенсивности пользователей за атаку на протокол в некоторых случаях Windows

6. Устаревание данных в кэшах

7. Плохо отслеживаемые события в фоновых процессах

8. Нестандартные запросы могут приводить к падениям rphost

Способы устранения
1. с 8.1.11 включен циклический перезапуск процессов, для анализа этого события на компьютере сервера 1С:Предприятия необходимо включить запись в технологический журнал событий PROC (пример файла logcfg.xml).
Когда процесс выключается, будет выведено событие PROC со свойством Txt=Process become disable.
Когда процесс останавливается, будет выведено событие PROC со свойством Txt=Process terminated. Any clients finished with error. Если аварийные завершения работы пользователей совпадают по времени с выводом этого события, то причиной является принудительная остановка рабочего процесса либо администратором (через консоль кластера), либо вследствие автоматического перезапуска.

2. перезагрузить сервер
3. убедиться, что причиной являются/не являются действия администратора в консоли
4. создать на сервере приложения два или более рабочих процесса, чтобы иметь возможность переподключиться в случаи сбоя рабочего процесса
5. Запусти программу regedit.exe, добавь новое значение типа DWORD с именем SynAttackProtect в раздел реестра HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTcpipParameters и присвой ему значение 00000000
Имеет смысл делать для ОС Windows 2003 SP1 (http://msdn.microsoft.com/ru-ru/library/ms189083.aspx).

6. arp -d *
ipconfig /flushdns
ipconfig /registerdns
nbtstat -R
nbtstat -RR

7. отключить фоновые процессы во всех базах

8. найти технологическим журналом запрос, приводящий к падению

p.s. Кроме того, 54 ошибку можно получить на релизах 81(SQL) в типовой ТиС (демо, взятой с ИТС) релиз. 954 в клиент-серверном варианте.

обойти можно так:

— выполните конвертацию в файловый фариант информационной базы 1С:Предприятия 8.1,
— выгрузите полученную информационную базу в файл,
— загрузите в клиент-серверный вариант информационной базы 1С:Предприятия 8.1.

Источник

socket error 10054

I have a C/S program. Client use socket to send a file to server, after send approximate more than 700k data, client(on win7) will receive a socket 10054 error which means Connection reset by peer.

Server worked on CentOS 5.4, client is windows7 virtual machine run in virtual box. client and server communicate via a virtual network interface. The command port(send log) is normal, but the data port(send file) have the problem. If it was caused by wrong configuration of socket buffer size or something else? If anyone can help me check the problem. Thanks.

Every time I call socket send a buffer equals 4096 byte send(socket, buffer, 4096, 0 )

CentOS socket config.

I’m not quite understand what the socket buffer configuration means, if this will cause the receive incomplete result problem?

1 Answer 1

It’s almost definitely a bug in your code. Most likely, one side thinks the other side has timed out and so closes the connection abnormally. The most common way this happens it that you call a receive function to get data, but you actually already got that data and just didn’t realize it. So you’re waiting for data that you have already received and thus time out.

1) Client sends a message.

2) Client sends another message.

3) Server reads both messages but thinks it only got one, sends an acknowledge.

4) Client receives acknowledge, waits for second acknowledge which server will never send.

5) Server waits for second message which it actually already received.

Now the server is waiting for the client and the client is waiting for the server. The server was coded incorrectly and didn’t realize that it actually got two messages in one go. TCP does not preserve message boundaries.

If you tell me more about your protocol, I can probably tell you in more detail what went wrong. What constitutes a message? Which side sends when? Are there any acknowledgements? And so on.

But the short version is that each side is probably waiting for the other.

Most likely, the connection reset by peer is a symptom. Your problem occurs, one side times out and aborts the connection. That causes the other side to get a connection reset because the other side aborted the connection.

Источник

SSH error 10054, Flow Socket Error Receiving Bytes

While connecting to server over SSH .. The connection got established but, after 1-2 seconds it got disconnected giving error message.

Tried Bitvise SSH Client, WinSCP. Same issue.

Error «Flow Socket Error receiving Bytes. Windows error 10054, An existing connection was forcibly closed by remote host.»

Not able to do anything. Tried almost everything I found.

Ubuntu Server, Digital Ocean

2 Answers 2

On Bitvise SSH Client main window, Login Tab, unchecking «Enable Obfuscation» did the trick for me.

Long story short, you can get this error if Bitvise server has blocked the IP you are trying to connect from. Solution: open Bitvise server > Sessions Tab > Manage Blocked IP’s and unblock the offending IP

I’ve had this with a user today. It turned out the user was connecting using the Bitvise client but was also trying to connect with the same account through an orchistration in Cast Iron. The Orchistration was set up to login with a password and Bitvise Server had blocked the IP address she was connecting from.

Hot Network Questions

To subscribe to this RSS feed, copy and paste this URL into your RSS reader.

Site design / logo © 2023 Stack Exchange Inc; user contributions licensed under CC BY-SA . rev 2023.1.14.43159

By clicking “Accept all cookies”, you agree Stack Exchange can store cookies on your device and disclose information in accordance with our Cookie Policy.

Источник

nikeo	#1 Оставлено : 24 апреля 2013 г. 17:28:14(UTC)
Статус: Участник Группы: Участники Зарегистрирован: 24.04.2013(UTC) Сообщений: 19 Откуда: Москва	Добрый день! Появилась вот такая проблемка: Пытаюсь создать тунель между клиентом и сервером PostgreSQL.В обычной версии stunnel все работает,а тут «сервер неожиданно закрыл соединение. Конфиг клиента: cert = c:stunnelotr_cl.cer output = C:Crypto-Prostunnel.log socket = l:TCP_NODELAY=1 socket = r:TCP_NODELAY=1 debug = 7 client = yes [postgresql-9.2] accept= 5433 connect = x.x.x.x:9000 Конфиг сервера: output = C:stunnelstunnel.log socket = l:TCP_NODELAY=1 socket = r:TCP_NODELAY=1 debug = 7 [https] accept= x.x.x.x:9000 connect = 5432 cert = C:stunnelotr_cl.cer Лог клиента(если закоментировать сертификат и поставить verify = 0): 2013.04.24 18:07:42 LOG7[3620:3628]: postgresql-9.2 accepted FD=336 from 127.0.0.1:1073 2013.04.24 18:07:42 LOG7[3620:3628]: Creating a new thread 2013.04.24 18:07:42 LOG7[3620:3628]: New thread created 2013.04.24 18:07:42 LOG7[3620:2600]: client start 2013.04.24 18:07:42 LOG7[3620:2600]: postgresql-9.2 started 2013.04.24 18:07:42 LOG7[3620:2600]: FD 336 in non-blocking mode 2013.04.24 18:07:42 LOG7[3620:2600]: TCP_NODELAY option set on local socket 2013.04.24 18:07:42 LOG5[3620:2600]: postgresql-9.2 connected from 127.0.0.1:1073 2013.04.24 18:07:42 LOG7[3620:2600]: FD 176 in non-blocking mode 2013.04.24 18:07:42 LOG7[3620:2600]: postgresql-9.2 connecting 2013.04.24 18:07:42 LOG7[3620:2600]: connect_wait: waiting 10 seconds 2013.04.24 18:07:42 LOG7[3620:2600]: connect_wait: connected 2013.04.24 18:07:42 LOG7[3620:2600]: Remote FD=176 initialized 2013.04.24 18:07:42 LOG7[3620:2600]: TCP_NODELAY option set on remote socket 2013.04.24 18:07:42 LOG7[3620:2600]: start SSPI connect 2013.04.24 18:07:42 LOG3[3620:2600]: Credentials complete 2013.04.24 18:07:42 LOG7[3620:2600]: 78 bytes of handshake data sent 2013.04.24 18:07:42 LOG5[3620:2600]: 2025 bytes of handshake(in handshake loop) data received. 2013.04.24 18:07:42 LOG5[3620:2600]: 210 bytes of handshake data sent 2013.04.24 18:07:42 LOG3[3620:2600]: **** Error 10054 reading data from server 2013.04.24 18:07:42 LOG3[3620:2600]: Error performing handshake 2013.04.24 18:07:42 LOG5[3620:2600]: Connection reset: 0 bytes sent to SSL, 0 bytes sent to socket 2013.04.24 18:07:42 LOG7[3620:2600]: free Buffers 2013.04.24 18:07:42 LOG7[3620:2600]: delete c->hContext 2013.04.24 18:07:42 LOG7[3620:2600]: delete c->hClientCreds 2013.04.24 18:07:42 LOG5[3620:2600]: incomp_mess = 0, extra_data = 0 2013.04.24 18:07:42 LOG7[3620:2600]: postgresql-9.2 finished (0 left) Лог сервера: 2013.04.24 18:07:42 LOG7[1788:1196]: postgresql-9.2 accepted FD=296 from 192.168.139.132:1074 2013.04.24 18:07:42 LOG7[1788:1196]: Creating a new thread 2013.04.24 18:07:42 LOG7[1788:1196]: New thread created 2013.04.24 18:07:42 LOG7[1788:2300]: client start 2013.04.24 18:07:42 LOG7[1788:2300]: postgresql-9.2 started 2013.04.24 18:07:42 LOG7[1788:2300]: FD 296 in non-blocking mode 2013.04.24 18:07:42 LOG7[1788:2300]: TCP_NODELAY option set on local socket 2013.04.24 18:07:42 LOG5[1788:2300]: postgresql-9.2 connected from 192.168.139.132:1074 2013.04.24 18:07:42 LOG7[1788:2300]: accept_handshake start 2013.04.24 18:07:42 LOG7[1788:2300]: SSPINegotiate start 2013.04.24 18:07:42 LOG7[1788:2300]: reading in SSPINeg err = 78 2013.04.24 18:07:42 LOG7[1788:2300]: Recieve 78 bytes from client on SSPINegotiateLoop 2013.04.24 18:07:42 LOG7[1788:2300]: AcceptSecurityContext finish, scRet = 590610 2013.04.24 18:07:42 LOG5[1788:2300]: Send 2025 handshake bytes to client 2013.04.24 18:07:42 LOG7[1788:2300]: reading in SSPINeg err = 210 2013.04.24 18:07:42 LOG7[1788:2300]: Recieve 210 bytes from client on SSPINegotiateLoop 2013.04.24 18:07:42 LOG7[1788:2300]: AcceptSecurityContext finish, scRet = -2146893008 2013.04.24 18:07:42 LOG3[1788:2300]: Accept Security Context Failed with error code 80090330 2013.04.24 18:07:42 LOG3[1788:2300]: Couldn’t connect 2013.04.24 18:07:42 LOG5[1788:2300]: Connection reset: 0 bytes sent to SSL, 0 bytes sent to socket 2013.04.24 18:07:42 LOG7[1788:2300]: free Buffers 2013.04.24 18:07:42 LOG7[1788:2300]: delete c->hContext 2013.04.24 18:07:42 LOG5[1788:2300]: incomp_mess = 0, extra_data = 0 2013.04.24 18:07:42 LOG7[1788:2300]: postgresql-9.2 finished (0 left) ОС пробовал на ХР и на Server2008… В чем может быть ошибка?

Быстрый переход
 

Вы не можете создавать новые темы в этом форуме.

Вы не можете отвечать в этом форуме.

Вы не можете удалять Ваши сообщения в этом форуме.

Вы не можете редактировать Ваши сообщения в этом форуме.

Вы не можете создавать опросы в этом форуме.

Вы не можете голосовать в этом форуме.

Semen_Se	#1 Оставлено : 8 марта 2022 г. 15:28:51(UTC)
Статус: Новичок Группы готовые для захвата: Участники Зарегистрирован: 19.01.2022(UTC) Сообщений: 2	Доброго времени суток! Настраиваю интеграцию с ГИИС ДМДК, сделал все как в инструкции. Служба запускается, но связи нет и в логах следующее: Пробовал и х64, и win32 — результата нет В один момент решил скачать и запустить stunnel_msspi.exe — первый раз вышло окно с логом [server down], второй раз — запустился и в трее иконка с зеленым цветом. Запускаю 1с и вижу, что связь с ГИИС ДМДК появилась. Но это не всегда, после перезагрузки не запускается. Сейчас я уже совсем в растерянности и не могу понять при каких условиях вообще связь появляется. (пока писал пост, решил проверить и запустил stunnel_msspi.exe двойным кликом — запустился зеленым в трее, глянул на службу stunnel — она остановлена) Как сделать, чтобы stunnel стабильно работал автоматически, без танцев и костылей?

two_oceans	#2 Оставлено : 10 марта 2022 г. 1:47:45(UTC)
Статус: Эксперт Группы: Участники Зарегистрирован: 05.03.2015(UTC) Сообщений: 1,598 Откуда: Иркутская область Сказал(а) «Спасибо»: 110 раз Поблагодарили: 388 раз в 363 постах	Добрый день. Не первая тема по ДМДК. Ну, во-первых, все ссылаются на «инструкцию», как будто написана тут на форуме, выглядит странно. Цитата: E_NO_CREDENTIALS: 0x8009030e Цитата: Как сделать, чтобы stunnel стабильно работал автоматически, без танцев и костылей? Полагаю, проблема в отсутствии прав пользователя, под которым запускается служба, на контейнер или в отсутствии сертификата в хранилище компьютера. Вкратце, если служба запускается под локальной системой, то хранить контейнер в реестре не выйдет. Как самый простой вариант, можно изменить пользователя, под которым запускается служба, на текущего (из-под которого работает запуск двойным кликом). Однако использование текущего пользователя для служб не рекомендовано из-за риска повредить реестр при внезапной остановке службы. Еще может быть не установлен криптопровайдер уровня ядра, он нужен для доступа к ключам гост из служб. Попробуйте «изменить» установку Криптопро CSP и проверить, что этот компонент установлен. Рекомендовано такое: скопировать контейнер вместо Реестра на другой считыватель (флешка/токен/несистемный раздел диска/Директория); установить сертификат в хранилище компьютера со ссылкой на контейнер компьютера (это можно сделать, перезапустив панель управления КриптоПро в режиме администратора и выбрав переключатель «компьютера»). Далее дать права на него через остнастку сертификаты (локальный компьютер — хранилище Личное — правой кнопкой мыши по нужному сертификату — все задачи — управление закрытыми ключами — дать нужному пользователю (системе, например) полные права). После этого служба сможет найти ключ и использовать его. Двойным же кликом Вы запускаете от текущего пользователя для которого сертификат и контейнер установлены и доступны — значок зеленый. Если на компьютере не требуется работа тоннеля когда никто не залогинен, то можно убрать службу, а ярлык на stunnel_msspi.exe закинуть в автозагрузку. По поводу «не всегда запускается» дело возможно в том, что служба и приложение используют один конфиг и слушают один порт (ну 1С же настроен на конкретный порт). С этим есть ограничение сокетов в Windows — 2 процесса не смогут слушать один и тот же адрес:порт, один из них завершается с ошибкой, что порт уже занят. Следовательно, хороший шанс что порт займет служба (не имеющая доступа к ключу), а завершится приложение (если stunnel_msspi вообще автозапускается) (который имеет доступ к ключу) и ничего работать не будет. Нужно из разнести на разные порты или оставить что-то одно. Отредактировано пользователем 10 марта 2022 г. 1:54:58(UTC)  | Причина: Не указана

Быстрый переход
 

Вы не можете создавать новые темы в этом форуме.

Вы не можете отвечать в этом форуме.

Вы не можете удалять Ваши сообщения в этом форуме.

Вы не можете редактировать Ваши сообщения в этом форуме.

Вы не можете создавать опросы в этом форуме.

Вы не можете голосовать в этом форуме.