Inet inet error read errno 10054

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.

E: WNET/wnet_error: ReadFile end-of-file errno = 109 (win)
E: INET/inet_error: send errno = 10054 (win)
E: Inet/inet_error: send errno=104 (unix)
D: Обрыв клиентского соединения. WNET — по NetBEUI, INET — по TCP/IP.
S: Для начала надо сделать upgrade на максимально последнюю версию IB (например для 5.x это 5.6, для 6.x это 6.0.1.6 или 6.5, для Firebird — релиз v1 и так далее) . Затем убедиться, что на сервере, если это NT (или W2K), стоит самый последний Service Pack. Если клиенты — NT (или W2K) Workstation, то на них поставить тот же сервиспак, что и на сервере. Если клиенты — Windows 95/98, то скачать с www.microsoft.com самые последние обновления для netbeui и tcp/ip.

Вообще при работе по tcp/ip таких ошибок должно быть существенно меньше, чем по netbeui.

Собственно, слово WNET в сообщении об ошибке означает ошибку при работе по протоколу по netbeui (строка вида \serverc:dirdata.gdb), а INET — по протоколу tcp (строка вида server:c:dirdata.gdb).

Если ошибки 109 или 10054 продолжают появляться, то нужно искать дефектное сетевое оборудование — хаб, свитчер, или сетевую карту. Теоретически в этом может помочь использование какого-либо SNIFFER, но методика пока неизвестна. Также см. утилиту ibconsvc.zip, которая заносит информацию о коннектах и дисконнектах (только tcp) прямо в interbase.log, что позволяет отследить станции или хабы, генерирующие ошибку 10054.

Еще один вариант, который иногда помогает устранить обрывы коннектов — изменение параметров CONNECTION_TIMEOUT и DUMMY_PACKET_INTERVAL в IBCONFIG (или isc_config на UNIX) на значения, отличные от умолчательных, например 170 и 50 соответственно. В некоторых случаях на UNIX помогает ус

Последнее обновление – 21.11.2001.

Ошибки идут под буквой E (error), описание ошибки – D (description), возможное решение проблемы – как S (solution).

Описания ошибок приведены на момент существования IB 7.0. Часть ошибок могут проявляться только в предыдущх версиях (6.x, FB,Yaffil, 5.6, 5.5, 5.1, 5.0).

E: internal gds software consistency check (partner index description not found (175))

D: "пропал" индекс первичного или вторичного ключа.
D: построен уникальный индекс по полю, по которому уже есть FK (т. е. неуникальный индекс).

S: Теоретически "пропавший" индекс можно обнаружить при помощи запроса

Constraint без индекса (пустое поле REALINDEX) и окажется "битым". Его нужно попытаться удалить. Если удалить constraint не удается, то следует попытаться создать индекс, имя которого указано в столбце REFINDEXNAME. Уникальность индекса должна соответствовать типу constraint – уникальный для первичного ключа, и неуникальный для вторичного.

Если же речь идет о лишнем (уникальном) индексе, то один из индексов рекомендуется удалить.

E: gds__free: attempt to release bad block
E: gds__alloc: memory pool corrupted

D: какие-то проблемы с памятью, или некорректно работающей UDF.

S: Решение проблемы неизвестно.
S: В более ранних версиях IB (4.2 и ниже) эта ошибка была известна как баг 8349, проявлявшийся при больших размерах файла сортировки. Т. е. при наличии запросов, обрабатывающих большие объемы данных, и имеющих сортировку ORDER BY без соответствующего индекса.

Кроме того, ошибка может появляться в multithread-приложениях из-за закрытия соединения не в том thread, в котором оно было открыто.

E: WNET/wnet_error: ReadFile end-of-file errno = 109 (win)
E: INET/inet_error: send errno = 10054 (win)
E: Inet/inet_error: send errno=104 (unix)

D: обрыв клиентского соединения. WNET – по NetBEUI, INET – по TCP/IP.

S: Для начала надо сделать upgrade на максимально последнюю версию IB (например, для 5.x это 5.6, для 6.x это 6.0.1.6 или 6.5, для Firebird – релиз v1 и так далее). Затем убедиться, что на сервере, если это NT (или W2K), стоит самый последний Service Pack. Если клиенты – NT (или W2K) Workstation, то на них поставить тот же сервиспак, что и на сервере. Если клиенты – Windows 95/98, то скачать с www.microsoft.com самые последние обновления для netbeui и tcp/ip.

Вообще при работе по tcp/ip таких ошибок должно быть существенно меньше, чем по netbeui.

Собственно, слово WNET в сообщении об ошибке означает ошибку при работе по протоколу по netbeui (строка вида \serverc:dirdata.gdb), а INET – по протоколу tcp (строка вида server:c:dirdata.gdb).

Если ошибки 109 или 10054 продолжают появляться, то нужно искать дефектное сетевое оборудование – хаб, свитчер, или сетевую карту. Теоретически в этом может помочь использование какого-либо SNIFFER, но методика пока неизвестна. Также см. утилиту ibconsvc.zip, которая заносит информацию о коннектах и дисконнектах (только tcp) прямо в interbase.log, что позволяет отследить станции или хабы, генерирующие ошибку 10054.

Еще один вариант, который иногда помогает устранить обрывы коннектов – изменение параметров CONNECTION_TIMEOUT и DUMMY_PACKET_INTERVAL в IBCONFIG (или isc_config на UNIX) на значения, отличные от умолчательных, например, 170 и 50 соответственно. В некоторых случаях на UNIX помогает установка connection_timeout в 0.

E: INET/inet_error: accept errno = 10093
E: INET/inet_error: read errno = 10038

D: ошибка при попытке инициализации подсистемы tcp/ip (NetBEUI), вызвана частыми появлениями ошибок 10054 (109). Как правило после этой ошибки сервер аварийно завершает работу. Для перезапуска сервера возможно требуется рестарт NT.

S: решение такое же, как и для ошибок 10054 или 109 (см. выше).

E: SCH_validate — not entered
E: SCH_validate — wrong thread

D: неверно работающая UDF

S: скорее всего, если функция написана на Delphi (Pascal), то в модуле не указано IsMultiThread:=True. Т. е. библиотека должна быть проинициализирована для безопасной работы с несколькими threads, поскольку сервер обращается к DLL UDF именно из разных threads.
Также следует избегать использования threadvars на серверах с двумя и более процессорами, т. к. в коде Delphi (по крайней мере 4) есть ошибки с использованием TLS. Вместо threadvars рекомендуются прямые вызовы функций работы с TLS в Win32.

E: Page 34672 is an orphan

D: возможно, что при операциях записи на диск сервер завершил работу аварийно или произошел сбой системы по питанию

S: Ничего не нужно делать. Осиротевшие страницы (orphan pages) будут использованы повторно для размещения новых данных.

E: internal gds software consistency check (error during savepoint backout (290))

E: internal gds Software consistency check (size of opt block exceeded (286))

E: internal gds software consistency check (invalid SEND request (167))

E: internal gds software consistency check (decompression overran buffer (179))

D: обычно ошибка возникает при попытке прямого копирования базы данных с одной платформы на другую, например, из-под NT на Netware.

S: перенос баз данных между платформами должен производиться только путем backup/restore. Если ошибка возникла при backup, то необходимо сделать проверку базы данных при помощи gfix с проверкой record fragments, и после этого опять попытаться сделать backup (возможно с опцией ignore checksum errors).

E: internal gds software consistency check (Too many savepoints (287))

D: возникает при большом количестве insert/update/delete (явном или косвенном, через триггеры) в одной длительной транзакции. Возможно влияние количества вызываемых триггеров и процедур в этой транзакции.

S: в компоненте соединения с БД (например, IBDatabase) нужно указать параметр isc_tpb_no_auto_undo. В этом случае сервер не будет пытаться сохранять все изменения через механизм savepoints. Делать это следует только для тех коннектов, где заранее известно, что количество изменений в одной из транзакций будет большим (явно или через триггеры, по количеству изменяемых записей – больше 10-100 тысяч).

E: internal gds software consistency check (wrong record length (183))

D: может возникнуть при UPDATE полей, по которым построен unique индекс.

S: ошибка исправлена в IB 5.6 (bugs N 60135, 60537).