Recv error 10054

Operating system call recv failed (error no. 10054)

How to analyze network disconnections shown in system log (BC transaction SM21) ?

System log (transaction SM21) shows network disconnections, e.g.

• Q04 Connection to user 2642 (EXTRACAO), terminal 38 (iguacucp125) lost
• Delete session 001 after error 061
• Operating system call recv failed (error no. 10054)

First at all, consider that a «network disconnection» in the system log (transaction SM21) or in a developer trace is not always meaningful; a typical case is an operating system 10061 error while trying to connect e.g. to the gateway of an SAP system that crashed; obviously, while trying to contact the sapgwXX service of the remote host, the connection cannot be established as the gateway is not running there. In case that still it makes sense to analyze the disconnection, there are several possibilities to analyze the errors:

SAP software: SAPgui and kernel

• Make sure that you are using the latest SAPGUI available.
• Make sure that your current SAP kernel is up-to-date (at least not older than half a year) in your SAP application servers.
• This is the starting point to eliminate that error. There are other possible causes that are to be checked if the issue persists after updating to the latest kernel and GUI patches, namely:
• A user with authorization for transaction SM04 can delete a session of any user; this will generate that message in the syslog and tracefiles.
• If a user is already logged in the system and he logs again with the same user, then he will get a pop up window with three options
• Continue with this logon and end any other logon (then his previous session in the system will be ended, and the information message «Delete session XXX after error 061» will be issued)
• Continue this log on without ending other logo
• Terminate this logon
• Another possibility are problems with the SAPGUI. In this case you should see some error messages after activating the frontend-trace.

Operating System support level: workstations and server(s)

Ensure that your systems are patched to the highest support pack, as well as the network card drivers, etc.
Check your hostname configuration (‘hosts’ files in the workstations, etc.).

Parametrization of SAP system

Sometimes disconnections are not a failure, but a feature offered by the SAP software to avoid the waste of resources due to disconnections caused by users closing the SAPgui without the proper log off, etc. The lines below explain how this mechanism works.

The kernel regularly checks whether a session is still in use and any session that is no longer in use is removed; the check is very simple: if the frontend has not sent any data to the application server for «rdisp/keepalive» seconds, the application server sends a short «ping» message to the frontend. The frontend should answer within the next 40 seconds with «pong», otherwise the application server assumes that the link is dead and releases all resources to the corresponding user. An error line “DP_CONN_DEAD» then appears in the trace file dev_disp. This usually occurs when a user switches off their PC without carrying out the shutdown procedure. A value of «rdisp/keepalive = 0» means that no check occurs.

If the parameter «rdisp/gui_auto_logout» is set, the timeout also applies to HTTP sessions as well as GUI sessions.

Networking tests

There are several situations that can cause a partner not to respond; if none of the above paragraphs can explain your issue, possibly one of the following will fit for your case:

• Workstation issue: a «hardware» issue (e.g. network card broken, but also an old NI driver, an outdated operating system, etc.), a local firewall or antivirus prevents the communication to flow, a OS restriction to the program (the SAPgui in our case) prevents the program to use the network (e.g. User Account Control in the Windows Vista or Server 2008), the program is not running, etc.
• Networking issue: a firewall placed between both parties prevents the communication, a hardware issue (e.g. a damaged cable, node, EM interferences, etc.)
• Server issue (similar to the workstation issue)

Then, the key here will be to determine which is the root cause of this issue. Of course, we will support you closely in case that the a bug in the SAP software is the cause; but please understand that we need to work very closely to you as we do not know your network configuration. It is convenient that you involve here your local networking team.

To further analyze the cause for the frontend not to respond, schedule a detailed network analysis between your application server and the workstation failing until this issue arises again (if ever) or, at least, for some days (even weeks, depending on the periodicity of this subject). This way we will decide if networking issues can be discarded as the root cause of this matter.

NIPING tool is located in the executables directory on any SAP server. You can fetch the latest version of NIPING from the Service Marketplace or, if it is not possible, you can copy the binary from your server binaries directory.

Operating System settings

The following are some typical errors for Microsoft Windows platforms:

• 10048 (WSAEADDRINUSE, SI_EPORT_INUSE) => Only one usage of each socket address (protocol/network address/port) is normally permitted.
• 10054 (WSAECONNRESET, SI_ECONN_BROKEN) => An existing connection was forcibly closed by the remote host.
• 10055 (WSAENOBUFS) => An operation on a socket could not be performed because the system lacked sufficient buffer space or because a queue was full.
• 10061 (WSAECONNREFUSED) => No connection could be made because the destination computer actively refused it, e.g. in the remote TCP port there is no server program running.

Sometimes these are due to insufficient settings for your operating system due to your particular requirements. This would be the case e.g. if a Java application needs to create a high amount of threads in a very short period of time, everyone with one or more TCP/IP connections; then you should extend the default values for the registry keys MaxUserPort and TCPTimedWaitDelay, otherwise you will get aforementioned error 10055.

Also, we have found a lot of issues with some new features as the Scalable Networking Pack aka. SNP (TCP Chimney Offload feature, RSS, and NetDMA). In particular, we always recommend to disable the «TCP Chimney Offload» feature option on your NIC. In order to do so, you can run from a command prompt “netsh int ip set chimney DISABLED”; run “netsh int ip show chimney” in order to know its current status. Then, reboot the system (it is mandatory!).

Even the “Media Sensing” feature can cause some troubles. Note that this feature is disabled by default in a Windows Server 2003-based server cluster, and so the DisableDHCPMediaSense registry entry has no effect.

Источник

Recv failed with error 10054

When I run a simple winsock program it returns the following error.

recv failed: 10054

Can some one help me to rectify this error? I also activated another udp sender application to inject udp packets into 127.0.0.1 10. Then I wanted to read the packets at port 10 from the code shown below. Is it something workable. Sorry for my little knowledge about how Winsock work.

Winsock program is as follows.

Best Regards
erhct

I might be able to help because I’m learning the same stuff except with TCP but I can’t read what u wrote.

Thanks kbw for the reply!

May be my understanding is wrong. I dont have a server side. I want to basically listen to port 10 and get the datagrams into a buffer. I have a separate program to inject udp packets to 127.0.0.1 port 10. Is this possible with this code or do I have to try something else.

I re-posted the code with proper indentation (pls see the beginning of this discussion). Please help.

Looking forward to your help.

May be my understanding is wrong. I dont have a server side. I want to basically listen to port 10 and get the datagrams into a buffer. I have a separate program to inject udp packets to 127.0.0.1 port 10.

You have a TCP client. If you want to receive UDP traffic, you’ll need to write a client that uses UDP, not TCP.

It is possible to have multiple UDP clients write to any given server:port combination, and the listener can receive those packet. You have to:
1. create a UDP socket
2. bind to the interface:port (probably INADDR_ANY:10 in your case)
3. use recvfrom to listen to receive packets. The function will tell you what socket address it received the packet from.

UDP is much easier to use than TCP, but you should be aware that UDP is «unreliable». It’ll work perfectly on a subnet, but you’ll need error correction if you’re running on a potentially busy LAN or a WAN.

Thanks kbw!
It worked after the modification you proposed. But the program exits after it received the first datagram. How I can make sure it does not exit till I receive all the packets from that port. The code is shown below,

Источник

Recv failed with error 10054

Часовой пояс: UTC + 3 часа

Правила форума

ВНИМАНИЕ! Прежде чем задавать вопрос, ознакомьтесь со ссылками ниже:

Вопросы по отличиям версий SAP, Add-On, EHP — сюда
Вопросы по SAP Front End (SAPlogon, SAPgui, guiXT и т.д.) — сюда
Вопросы по LSMW — сюда
Вопросы по архивации в SAP — сюда
Вопросы по SAP GRC — сюда
Вопросы по SAP Business Workplace (почте SAP) и SAP Office — сюда
Вопросы по miniSAP (SAP mini basis) — сюда
Вопросы по SAP HANA — сюда
Вопросы по лицензированию продуктов SAP — сюда

Operating system call recv failed (error no. 10054)

Автор	Сообщение
alexivara
Младший специалист Зарегистрирован: Пт, авг 29 2008, 12:36 Сообщения: 71 Откуда: Москва	Кто-нибудь сталкивался с такой руганью в логах? При этом все продолжает работать. 100% появляются такие ошибки когда останавливаю инстанцию. И периодически когда работают в системе. Вот пример лога: Wed Nov 26 11:01:06 2008 ***LOG Q0I=> NiIRead: recv (10054: WSAECONNRESET: Connection reset by peer) [nixxi.cpp 4424] *** ERROR => NiIRead: SiRecv failed for hdl 5 / sock 332 (SI_ECONN_BROKEN/10054; I4; ST; 172.16.3.26:2788) [nixxi.cpp 4424] Wed Nov 26 11:01:21 2008 ***LOG Q0I=> NiIRead: recv (10054: WSAECONNRESET: Connection reset by peer) [nixxi.cpp 4424] *** ERROR => NiIRead: SiRecv failed for hdl 3 / sock 356 (SI_ECONN_BROKEN/10054; I4; ST; 127.0.0.1:2368) [nixxi.cpp 4424] ***LOG Q0I=> NiIRead: recv (10054: WSAECONNRESET: Connection reset by peer) [nixxi.cpp 4424] *** ERROR => NiIRead: SiRecv failed for hdl 8 / sock 280 (SI_ECONN_BROKEN/10054; I4; ST; 127.0.0.1:2404) [nixxi.cpp 4424] ***LOG Q0I=> NiIRead: recv (10054: WSAECONNRESET: Connection reset by peer) [nixxi.cpp 4424] *** ERROR => NiIRead: SiRecv failed for hdl 2 / sock 368 (SI_ECONN_BROKEN/10054; I4; ST; 127.0.0.1:2367) [nixxi.cpp 4424] Wed Nov 26 11:01:22 2008 ***LOG S30=> GwStopGateway, gateway stopped () [gwxxrd.c 14655] И пример лога с другого сервера(идентичное железо) во время работы: Сеть проверял, ни одного пакета не теряется. Ноты которые уже прошерстил: Note 155147 — WinNT: Connection reset by peer Note 545177 — FAQ: Preliminary steps in analyzing RFC connections Note 500235 — Network Diagnosis with NIPING
Вернуться к началу

alexivara
Младший специалист Зарегистрирован: Пт, авг 29 2008, 12:36 Сообщения: 71 Откуда: Москва	такс, про первый пример суппорт уже ответил: The work processes have a TCP connection to the local gateway. This connection always uses the local host connection via the IP address 127.0.0.1. When the system shuts down the work processes simply close that connection which leads to the error messages in the gateway. If the gateway recognizes those disconnect depends on if the gateway shuts down faster than the work processes or not. So this is a race condition if the messages occur or not. Anyway when the messages appear during the stopping of the system they do not indicate a problem at all and can be ignored. Thanks and kind regards,»
Вернуться к началу

Часовой пояс: UTC + 3 часа

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей

Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

SAP форум.RU © 2000-. Михаил Вершков

Логотип © 2006 Андрей Горшков

Источник

How to analyze network disconnections shown in system log (BC transaction SM21) ?

System log (transaction SM21) shows network disconnections, e.g.

• Q04 Connection to user 2642 (EXTRACAO), terminal 38 (iguacucp125) lost
• Delete session 001 after error 061
• Operating system call recv failed (error no. 10054)

First at all, consider that a «network disconnection» in the system log (transaction SM21) or in a developer trace is not always meaningful; a typical case is an operating system 10061 error while trying to connect e.g. to the gateway of an SAP system that crashed; obviously, while trying to contact the sapgwXX service of the remote host, the connection cannot be established as the gateway is not running there. In case that still it makes sense to analyze the disconnection, there are several possibilities to analyze the errors:

SAP software: SAPgui and kernel

• Make sure that you are using the latest SAPGUI available.
• Make sure that your current SAP kernel is up-to-date (at least not older than half a year) in your SAP application servers.
• This is the starting point to eliminate that error. There are other possible causes that are to be checked if the issue persists after updating to the latest kernel and GUI patches, namely:
• A user with authorization for transaction SM04 can delete a session of any user; this will generate that message in the syslog and tracefiles.
• If a user is already logged in the system and he logs again with the same user, then he will get a pop up window with three options
• Continue with this logon and end any other logon (then his previous session in the system will be ended, and the information message «Delete session XXX after error 061» will be issued)
• Continue this log on without ending other logo
• Terminate this logon
• Another possibility are problems with the SAPGUI. In this case you should see some error messages after activating the frontend-trace.

Operating System support level: workstations and server(s)

    Ensure that your systems are patched to the highest support pack, as well as the network card drivers, etc.
    Check your hostname configuration (‘hosts’ files in the workstations, etc.).   

Parametrization of SAP system

Sometimes disconnections are not a failure, but a feature offered by the SAP software to avoid the waste of resources due to disconnections caused by users closing the SAPgui without the proper log off, etc. The lines below explain how this mechanism works.

The kernel regularly checks whether a session is still in use and any session that is no longer in use is removed; the check is very simple: if the frontend has not sent any data to the application server for «rdisp/keepalive» seconds, the application server sends a short «ping» message to the frontend. The frontend should answer within the next 40 seconds with «pong», otherwise the application server assumes that the link is dead and releases all resources to the corresponding user. An error line “DP_CONN_DEAD» then appears in the trace file dev_disp. This usually occurs when a user switches off their PC without carrying out the shutdown procedure. A value of «rdisp/keepalive = 0» means that no check occurs.

If the parameter «rdisp/gui_auto_logout» is set, the timeout also applies to HTTP sessions as well as GUI sessions.

Networking tests

There are several situations that can cause a partner not to respond; if none of the above paragraphs can explain your issue, possibly one of the following will fit for your case:

• Workstation issue: a «hardware» issue (e.g. network card broken, but also an old NI driver, an outdated operating system, etc.), a local firewall or antivirus prevents the communication to flow, a OS restriction to the program (the SAPgui in our case) prevents the program to use the network (e.g. User Account Control in the Windows Vista or Server 2008), the program is not running, etc.
   
• Networking issue: a firewall placed between both parties prevents the communication, a hardware issue (e.g. a damaged cable, node, EM interferences, etc.)
   
• Server issue (similar to the workstation issue)

Then, the key here will be to determine which is the root cause of this issue. Of course, we will support you closely in case that the a bug in the SAP software is the cause; but please understand that we need to work very closely to you as we do not know your network configuration. It is convenient that you involve here your local networking team.

To further analyze the cause for the frontend not to respond, schedule a detailed network analysis between your application server and the workstation failing until this issue arises again (if ever) or, at least, for some days (even weeks, depending on the periodicity of this subject). This way we will decide if networking issues can be discarded as the root cause of this matter.

NIPING tool is located in the executables directory on any SAP server. You can fetch the latest version of NIPING from the Service Marketplace or, if it is not possible, you can copy the binary from your server binaries directory.

Operating System settings

The following are some typical errors for Microsoft Windows platforms:

• 10048 (WSAEADDRINUSE, SI_EPORT_INUSE) => Only one usage of each socket address (protocol/network address/port) is normally permitted.
   
• 10054 (WSAECONNRESET, SI_ECONN_BROKEN) => An existing connection was forcibly closed by the remote host.
   
• 10055 (WSAENOBUFS) => An operation on a socket could not be performed because the system lacked sufficient buffer space or because a queue was full.
   
• 10061 (WSAECONNREFUSED) => No connection could be made because the destination computer actively refused it, e.g. in the remote TCP port there is no server program running.

Sometimes these are due to insufficient settings for your operating system due to your particular requirements. This would be the case e.g. if a Java application needs to create a high amount of threads in a very short period of time, everyone with one or more TCP/IP connections; then you should extend the default values for the registry keys MaxUserPort and TCPTimedWaitDelay, otherwise you will get aforementioned error 10055.

Also, we have found a lot of issues with some new features as the Scalable Networking Pack aka. SNP (TCP Chimney Offload feature, RSS, and NetDMA). In particular, we always recommend to disable the «TCP Chimney Offload» feature option on your NIC. In order to do so, you can run from a command prompt “netsh int ip set chimney DISABLED”; run “netsh int ip show chimney” in order to know its current status. Then, reboot the system (it is mandatory!).

Even the “Media Sensing” feature can cause some troubles. Note that this feature is disabled by default in a Windows Server 2003-based server cluster, and so the DisableDHCPMediaSense registry entry has no effect.

Hi All,

I am facing the above problem after the updation of kernel , igs and JVM in PI 7.1

The java is not coming up.

The disp+work is having the error

(10054: WSAECONNRESET: Connection reset by peer)

J2EE server info

start = TRUE

state = STARTED

pid = 4792

argv[0] = F:usrsapPS3DVEBMGS00exejstart.EXE

argv[1] = F:usrsapPS3DVEBMGS00exejstart.EXE

argv[2] = pf=F:usrsapPS3SYSprofilePS3_DVEBMGS00_hydhtc165182d

argv[3] = -DSAPSTART=1

argv[4] = -DCONNECT_PORT=64952

argv[5] = -DSAPSYSTEM=00

argv[6] = -DSAPSYSTEMNAME=PS3

argv[7] = -DSAPMYNAME=hydhtc165182d_PS3_00

argv[8] = -DSAPPROFILE=F:usrsapPS3SYSprofilePS3_DVEBMGS00_hydhtc165182d

argv[9] = -DFRFC_FALLBACK=ON

argv[10] = -DFRFC_FALLBACK_HOST=localhost

start_lazy = 0

start_control = SAP J2EE startup framework

DpJ2eeStart: j2ee state = STARTED

DpJ2eeLogin: j2ee state = CONNECTED

Fri Apr 03 13:05:33 2009

***LOG Q0I=> NiIRead: P=127.0.0.1:4802; L=0.0.0.0:64952: recv (10054: WSAECONNRESET: Connection reset by peer) [nixxi.cpp 4857]

• ERROR => NiIRead: SiRecv failed for hdl 33/sock 1216

(SI_ECONN_BROKEN/10054; I4; ST; P=127.0.0.1:4802; L=0.0.0.0:64952) [nixxi.cpp 4857]

DpJ2eeMsgProcess: j2ee state = CONNECTED (NIECONN_BROKEN)

DpIJ2eeShutdown: send SIGINT to SAP J2EE startup framework (pid=4792)

• ERROR => DpProcKill: kill failed [dpntdisp.c 396]

DpIJ2eeShutdown: j2ee state = SHUTDOWN

I have already checked note 155147 and 413330 but i dont think so i am facing network issues

The server was working fine until the applying of the kernels but once i applied the kernel pathches the java dint come up.

Any pointers would help

Rgds

Aditya

// Server.cpp : Defines the entry point for the console application.

//

#include «stdafx.h»

 //******************* SERVER PROG ****************

#include <winsock2.h>

#include <stdio.h>

#pragma comment(lib, «Ws2_32.lib»)

#define DEFAULT_BUFLEN 512

#define DEFAULT_PORT 27015

#define WIN32_LEAN_AND_MEAN

#include <windows.h>

#include <winsock2.h>

#include <ws2tcpip.h>

#include <stdlib.h>

#include <stdio.h>

// Need to link with Ws2_32.lib, Mswsock.lib, and Advapi32.lib

#pragma comment (lib, «Ws2_32.lib»)

#pragma comment (lib, «Mswsock.lib»)

#pragma comment (lib, «AdvApi32.lib»)

#define DEFAULT_BUFLEN 512

#define DEFAULT_PORT «27015»

int __cdecl main(void)

{

    WSADATA wsaData;

    SOCKET ListenSocket = INVALID_SOCKET,

           ClientSocket = INVALID_SOCKET;

    struct addrinfo *result = NULL,

                    hints;

    char recvbuf[DEFAULT_BUFLEN];

    int iResult, iSendResult;

    int recvbuflen = DEFAULT_BUFLEN;

    // Initialize Winsock

    iResult = WSAStartup(MAKEWORD(2,2), &wsaData);

    if (iResult != 0) {

        printf(«WSAStartup failed with error: %dn», iResult);

        return 1;

    }

    ZeroMemory(&hints, sizeof(hints));

    hints.ai_family = AF_INET;

    hints.ai_socktype = SOCK_STREAM;

    hints.ai_protocol = IPPROTO_TCP;

    hints.ai_flags = AI_PASSIVE;

    // Resolve the server address and port

    iResult = getaddrinfo(NULL, DEFAULT_PORT, &hints, &result);

    if ( iResult != 0 ) {

        printf(«getaddrinfo failed with error: %dn», iResult);

        WSACleanup();

        return 1;

    }

    // Create a SOCKET for connecting to server

    ListenSocket = socket(result->ai_family, result->ai_socktype, result->ai_protocol);

    if (ListenSocket == INVALID_SOCKET) {

        printf(«socket failed with error: %ldn», WSAGetLastError());

        freeaddrinfo(result);

        WSACleanup();

        return 1;

    }

    // Setup the TCP listening socket

    iResult = bind( ListenSocket, result->ai_addr, (int)result->ai_addrlen);

    if (iResult == SOCKET_ERROR) {

        printf(«bind failed with error: %dn», WSAGetLastError());

        closesocket(ListenSocket);

        WSACleanup();

        return 1;

    }

    freeaddrinfo(result);

    iResult = listen(ListenSocket, SOMAXCONN);

    if (iResult == SOCKET_ERROR) {

        printf(«listen failed with error: %dn», WSAGetLastError());

        closesocket(ListenSocket);

        WSACleanup();

        return 1;

    }

    // Accept a client socket

    printf(«start accept:n»);

    ClientSocket = accept(ListenSocket, NULL, NULL);

    if (ClientSocket == INVALID_SOCKET) {

        printf(«accept failed with error: %dn», WSAGetLastError());

        closesocket(ListenSocket);

        WSACleanup();

        return 1;

    }

    printf(«end accept:n»);

    // No longer need server socket

    closesocket(ListenSocket);

    printf(«end accept:n»);

    printf(«start Receive:n»);

    // Receive until the peer shuts down the connection

    do {

        iResult = recv(ClientSocket, recvbuf, recvbuflen, 0);

        if (iResult > 0) {

            printf(«Bytes received: %dn», iResult);

        // Echo the buffer back to the sender

            iSendResult = send( ClientSocket, recvbuf, iResult, 0 );

            if (iSendResult == SOCKET_ERROR) {

                printf(«send failed with error: %dn», WSAGetLastError());

                closesocket(ClientSocket);

                WSACleanup();

                return 1;

            }

            printf(«Bytes sent: %dn», iSendResult);

        }

        else if (iResult == 0)

            printf(«Connection closing…n»);

        else  {

            printf(«recv failed with error: %dn», WSAGetLastError());

            closesocket(ClientSocket);

            WSACleanup();

            return 1;

        }

    } while (iResult > 0);

    // shutdown the connection since we’re done

    iResult = shutdown(ClientSocket, SD_SEND);

    if (iResult == SOCKET_ERROR) {

        printf(«shutdown failed with error: %dn», WSAGetLastError());

        closesocket(ClientSocket);

        WSACleanup();

        return 1;

    }

    // cleanup

    closesocket(ClientSocket);

    WSACleanup();

    return 0;

}