Announcement

Collapse
No announcement yet.

TCP socket breaks

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • TCP socket breaks

    Hello,

    we are using XPort Pro with Evolution OS V5.2.0.0R22. Our application provides a TCP socket communication to a PC. Communication is done in independently both directions (RX/TX).

    The communication works quite well for some time (hours, days, weeks). But there are sporadic communication problems. We have finally accomplished to monitor such a communication problem.

    Here a network trace:
    Code:
    20:21:46.030	PC -> XPP	TCP	56493?2345 [ACK] Seq=33132 Ack=2811389087 Win=63054 Len=0
    20:21:50.587	PC -> XPP	TCP	56493?2345 [PSH, ACK] Seq=33132 Ack=2811389087 Win=63054 Len=16
    20:21:50.730	XPP -> PC	TCP	2345?56493 [PSH, ACK] Seq=2811389087 Ack=33148 Win=64240 Len=6
    20:21:50.788	PC -> XPP	TCP	56493?2345 [ACK] Seq=33148 Ack=2811389093 Win=63048 Len=0
    
    20:21:50.833	XPP -> PC	TCP	2345?56493 [PSH, ACK] Seq=2811389093 Ack=33148 Win=64240 Len=22
    20:21:50.882	PC -> XPP	TCP	56493?2345 [ACK] Seq=33148 Ack=2811389115 Win=63026 Len=0
    
    20:21:51.350	PC -> XPP	TCP	56493?2345 [PSH, ACK] Seq=33148 Ack=2811389115 Win=63026 Len=4
    20:21:51.646	PC -> XPP	TCP	[TCP Retransmission] 56493?2345 [PSH, ACK] Seq=33148 Ack=2811389115 Win=63026 Len=4
    20:21:52.255	PC -> XPP	TCP	[TCP Retransmission] 56493?2345 [PSH, ACK] Seq=33148 Ack=2811389115 Win=63026 Len=4
    
    20:21:52.830	XPP -> PC	TCP	2345?56493 [PSH, ACK] Seq=2811389115 Ack=33148 Win=64240 Len=22
    20:21:52.879	PC -> XPP	TCP	56493?2345 [ACK] Seq=33152 Ack=2811389137 Win=63004 Len=0
    
    20:21:52.930	XPP -> PC	TCP	2345?56493 [PSH, ACK] Seq=2811389137 Ack=33148 Win=64240 Len=22
    20:21:52.988	PC -> XPP	TCP	56493?2345 [ACK] Seq=33152 Ack=2811389159 Win=62982 Len=0
    
    20:21:53.472	PC -> XPP	TCP	[TCP Retransmission] 56493?2345 [PSH, ACK] Seq=33148 Ack=2811389159 Win=62982 Len=4
    
    20:21:53.980	XPP -> PC	TCP	2345?56493 [PSH, ACK] Seq=2811389159 Ack=33148 Win=64240 Len=22
    20:21:54.033	PC -> XPP	TCP	56493?2345 [ACK] Seq=33152 Ack=2811389181 Win=62960 Len=0
    
    20:21:54.130	XPP -> PC	TCP	2345?56493 [PSH, ACK] Seq=2811389181 Ack=33148 Win=64240 Len=22
    20:21:54.189	PC -> XPP	TCP	56493?2345 [ACK] Seq=33152 Ack=2811389203 Win=62938 Len=0
    
    20:21:55.874	PC -> XPP	TCP	[TCP Retransmission] 56493?2345 [PSH, ACK] Seq=33148 Ack=2811389203 Win=62938 Len=4
    
    20:21:58.930	XPP -> PC	TCP	2345?56493 [PSH, ACK] Seq=2811389203 Ack=33148 Win=64240 Len=22
    20:21:58.978	PC -> XPP	TCP	56493?2345 [ACK] Seq=33152 Ack=2811389225 Win=62916 Len=0
    
    20:22:00.679	PC -> XPP	TCP	[TCP Retransmission] 56493?2345 [PSH, ACK] Seq=33148 Ack=2811389225 Win=62916 Len=4
    
    20:22:10.289	PC -> XPP	TCP	56493?2345 [RST, ACK] Seq=33152 Ack=2811389225 Win=0 Len=0
    
    20:22:10.291	XPP -> PC	Syslog	USER.ERR:     00 132:36:08 XPP tcp.c: tcpClientReceive() network error -1 -114
    The last entry shows the syslog message that is created by the application as a reaction to the recv() call. The "-1" is the return value from the function and "-114" (ECONNRESET - connection reset by peer) is the errno.

    I am not a TCP specialist. Maybe you can find out more from the network trace. I guess, XPP has enough space in the RX buffer (win > 0), but XPP does not acknowledge the transmission of four bytes (sequence number stays 33148), although there are five retransmissions. There is no traffic on our testing network and the PC CPU load is nearly idle.

    Could you please check if this is a problem of the XPP TCP stack and a known issue? Do you have an idea what causes this behaviour? Can you please tell me where I can find a change log/user release notes for Evolution SDK V5.2.0.5B13? Please let me know if you need further information.
    Last edited by TESK; 12-10-2015, 10:16 AM.

  • #2
    Here's the release notes for 5.2.0.1R5 which is the last stable release:
    http://ts.lantronix.com/ftp/XPort-Pr...ease_Notes.txt

    You can download the SDK for this release here:
    http://forums.lantronix.com/showthread.php?t=868

    Also as you mentioned, there's the Beta of the SDK that is version 5.2.0.5B13:
    http://forums.lantronix.com/showthread.php?t=1079

    I don't have release notes for it, but I do know it has a lot of bug fixes, so I would try compiling your application with it.

    Mariano

    Comment


    • #3
      Thank you for your fast response.

      I checked the release notes for V5.2.0.1R5, but I did not see a clue regarding the TCP problem. It is hard to monitor this problem, because the test device may work for days or weeks until it shows the problem. I could try V5.2.0.5B13, but how long do I have to wait to be sure...?

      Can you please ask somebody for the differences between V5.2.0.1R2 and V5.2.0.5B13? Or could you please check if it is a known problem that will be solved in V5.4.x?

      Did you take a look at the network traces? Might this be a problem of the TCP stack or what else could cause this behaviour?

      Comment


      • #4
        Here another occurrence (this time in the opposite direction from XPP to PC):

        Code:
        16:51:40.821	XPP -> PC	TCP	2345 -> 55022 [PSH, ACK] Seq=4071503423 Ack=306733 Win=64240 Len=22
        16:51:40.878	PC -> XPP	TCP	55022 -> 2345 [ACK] Seq=306733 Ack=4071503445 Win=64597 Len=0
        16:51:41.330	PC -> XPP	TCP	55022 -> 2345 [PSH, ACK] Seq=306733 Ack=4071503445 Win=64597 Len=4
        16:51:41.419	XPP -> PC	TCP	2345 -> 55022 [PSH, ACK] Seq=4071503445 Ack=306737 Win=64240 Len=22
        16:51:41.471	PC -> XPP	TCP	55022 -> 2345 [ACK] Seq=306737 Ack=4071503467 Win=64575 Len=0
        16:51:42.419	XPP -> PC	TCP	[TCP Retransmission] 2345 -> 55022 [PSH, ACK] Seq=4071503445 Ack=306737 Win=64240 Len=22
        16:51:42.419	PC -> XPP	TCP	[TCP Dup ACK 904632#1] 55022 -> 2345 [ACK] Seq=306737 Ack=4071503467 Win=64575 Len=0
        16:51:44.469	XPP -> PC	TCP	[TCP Retransmission] 2345 -> 55022 [PSH, ACK] Seq=4071503445 Ack=306737 Win=64240 Len=22
        16:51:44.469	PC -> XPP	TCP	[TCP Dup ACK 904632#2] 55022 -> 2345 [ACK] Seq=306737 Ack=4071503467 Win=64575 Len=0
        16:51:48.468	XPP -> PC	TCP	[TCP Retransmission] 2345 -> 55022 [PSH, ACK] Seq=4071503445 Ack=306737 Win=64240 Len=22
        16:51:48.468	PC -> XPP	TCP	[TCP Dup ACK 904632#3] 55022 -> 2345 [ACK] Seq=306737 Ack=4071503467 Win=64575 Len=0
        16:51:53.436	PC -> XPP	TCP	55022 -> 2345 [PSH, ACK] Seq=306737 Ack=4071503467 Win=64575 Len=15
        16:51:53.437	XPP -> PC	TCP	2345 -> 55022 [ACK] Seq=4071503467 Ack=306752 Win=64225 Len=22
        16:51:53.438	XPP -> PC	TCP	2345 -> 55022 [FIN, ACK] Seq=4071503489 Ack=306752 Win=64225 Len=0
        16:51:53.438	PC -> XPP	TCP	55022 -> 2345 [ACK] Seq=306752 Ack=4071503490 Win=64553 Len=0
        16:51:53.467	PC -> XPP	TCP	55022 -> 2345 [FIN, ACK] Seq=306752 Ack=4071503490 Win=64553 Len=0
        16:51:53.469	XPP -> PC	TCP	2345 -> 55022 [ACK] Seq=4071503490 Ack=306753 Win=64225 Len=0
        It seems as if the XPP does not see the packet(-s) with ACK=4071503467. At the end of the trace, the connection is closed by the XPP application after a send timeout.

        Can you please check, if it is a known problem? We are doing tests with different versions of Evolution OS (release and beta), but we want to be sure that this is fixed with one of these versions...

        Comment


        • #5
          And here the next occurence (this time from PC to XPP):

          Code:
          14:37:09.056	XPP -> PC	TCP	2345 -> 49702 [PSH, ACK] Seq=2982131 Ack=407627 Win=64240 Len=19
          14:37:09.256	PC -> XPP	TCP	49702 -> 2345 [ACK] Seq=407627 Ack=2982150 Win=63987 Len=0
          
          14:37:13.583	PC -> XPP	TCP	49702 -> 2345 [PSH, ACK] Seq=407627 Ack=2982150 Win=63987 Len=15
          14:37:13.654	XPP -> PC	TCP	2345 -> 49702 [PSH, ACK] Seq=2982150 Ack=407642 Win=64240 Len=6
          14:37:13.854	PC -> XPP	TCP	49702 -> 2345 [ACK] Seq=407642 Ack=2982156 Win=63981 Len=0
          
          14:37:13.906	XPP -> PC	TCP	2345 -> 49702 [PSH, ACK] Seq=2982156 Ack=407642 Win=64240 Len=19
          14:37:14.105	PC -> XPP	TCP	49702 -> 2345 [ACK] Seq=407642 Ack=2982175 Win=63962 Len=0
          
          14:37:14.406	PC -> XPP	TCP	49702 -> 2345 [PSH, ACK] Seq=407642 Ack=2982175 Win=63962 Len=4
          14:37:14.706	PC -> XPP	TCP	[TCP Retransmission] 49702 -> 2345 [PSH, ACK] Seq=407642 Ack=2982175 Win=63962 Len=4
          14:37:15.306	PC -> XPP	TCP	[TCP Retransmission] 49702 -> 2345 [PSH, ACK] Seq=407642 Ack=2982175 Win=63962 Len=4
          
          14:37:15.777	XPP -> PC	TCP	2345 -> 49702 [PSH, ACK] Seq=2982175 Ack=407642 Win=64240 Len=19
          14:37:15.977	PC -> XPP	TCP	49702 -> 2345 [ACK] Seq=407646 Ack=2982194 Win=63943 Len=0
          
          14:37:15.980	XPP -> PC	TCP	2345 -> 49702 [PSH, ACK] Seq=2982194 Ack=407642 Win=64240 Len=19
          14:37:16.179	PC -> XPP	TCP	49702 -> 2345 [ACK] Seq=407646 Ack=2982213 Win=63924 Len=0
          
          14:37:16.509	PC -> XPP	TCP	[TCP Retransmission] 49702 -> 2345 [PSH, ACK] Seq=407642 Ack=2982213 Win=63924 Len=4
          
          14:37:16.941	XPP -> PC	TCP	2345 -> 49702 [PSH, ACK] Seq=2982213 Ack=407642 Win=64240 Len=19
          14:37:17.140	PC -> XPP	TCP	49702 -> 2345 [ACK] Seq=407646 Ack=2982232 Win=63905 Len=0
          
          14:37:17.195	XPP -> PC	TCP	2345 -> 49702 [PSH, ACK] Seq=2982232 Ack=407642 Win=64240 Len=19
          14:37:17.394	PC -> XPP	TCP	49702 -> 2345 [ACK] Seq=407646 Ack=2982251 Win=63886 Len=0
          
          14:37:18.904	PC -> XPP	TCP	[TCP Retransmission] 49702 -> 2345 [PSH, ACK] Seq=407642 Ack=2982251 Win=63886 Len=4
          
          14:37:21.991	XPP -> PC	TCP	2345 -> 49702 [PSH, ACK] Seq=2982251 Ack=407642 Win=64240 Len=19
          14:37:22.191	PC -> XPP	TCP	49702 -> 2345 [ACK] Seq=407646 Ack=2982270 Win=63867 Len=0
          
          14:37:23.711	PC -> XPP	TCP	[TCP Retransmission] 49702 -> 2345 [PSH, ACK] Seq=407642 Ack=2982270 Win=63867 Len=4
          
          14:37:33.312	PC -> XPP	TCP	49702 -> 2345 [RST, ACK] Seq=407646 Ack=2982270 Win=0 Len=0
          14:37:33.320	XPP -> PC	TCP	2345 -> 49702 [FIN, PSH, ACK] Seq=2982270 Ack=407642 Win=64240 Len=0
          Socket is closed by the PC (send timeout). The XPP recv() function returns -1, the errno is -114 (connection reset by peer).

          We checked the application code. But we could not find a suspicious defect. The TCP receive buffer seems to be empty, but the XPP does not ACK the data. Any idea? Why does nobody answer to my questions in this thread as well as in other threads, too?

          Comment


          • #6
            Here the TCP statistic data from CLI for the trace above. Please let me know if you need more information.

            Code:
              Passive Connections Opened        : 18
              Connection Attempt Failures       : 0
              Connections Resetted              : 0
              Connections Currently Established : 5
              In Segments                       : 330703
              Out Segments                      : 264997
              Retransmitted Segments            : 3
              In Errors                         : 10
              Out Resets (RSTs)                 : 0
              In Resets (RSTs)                  : 1

            Comment


            • #7
              We reproduced this problem several times in the last weeks. Another interesting fact: When the XPP does not ACK the TCP packets and the PC sends an ARP request (request MAC of IP) in this period of time, the XPP answers the ARP request, but ignores the TCP packet.

              Does anyone has an idea? The monologue in this thread is a little bit boring...

              Comment


              • #8
                Have tried to reproduce the issue, Can you please share a detailed setup information and steps to reproduce the issue.

                Comment


                • #9
                  We used a simple application on the PC that sends 10 bytes to the XPP and waits for the (echo) answer. The network trace shows the last frames before the connection has been lost.

                  Code:
                  06:10:54.15	PC -> XPP	TCP	49550 -> 2345 [ACK] Seq=2216171 Ack=4289469374 Win=64185 Len=0
                  
                  06:10:54.32	PC -> XPP	TCP	49550 -> 2345 [PSH, ACK] Seq=2216171 Ack=4289469374 Win=64185 Len=10 "00221617\r\n"
                  06:10:54.34	XPP -> PC	Syslog	USER.DEBUG:     00 14:54:08 main.c: RX 00221617\r\n
                  06:10:54.34	XPP -> PC	TCP	2345 -> 49550 [PSH, ACK] Seq=4289469374 Ack=2216181 Win=64240 Len=10 "00221617\r\n"
                  06:10:54.34	XPP -> PC	Syslog	USER.DEBUG:     00 14:54:08 main.c: TX finished
                  06:10:54.35	PC -> XPP	TCP	49550 -> 2345 [ACK] Seq=2216181 Ack=4289469384 Win=64175 Len=0
                  
                  06:10:54.54	PC -> XPP	TCP	49550 -> 2345 [PSH, ACK] Seq=2216181 Ack=4289469384 Win=64175 Len=10 "00221618\r\n"
                  06:10:54.85	PC -> XPP	TCP	[TCP Retransmission] 49550 -> 2345 [PSH, ACK] Seq=2216181 Ack=4289469384 Win=64175 Len=10
                  06:10:55.46	PC -> XPP	TCP	[TCP Retransmission] 49550 -> 2345 [PSH, ACK] Seq=2216181 Ack=4289469384 Win=64175 Len=10
                  06:10:56.66	PC -> XPP	TCP	[TCP Retransmission] 49550 -> 2345 [PSH, ACK] Seq=2216181 Ack=4289469384 Win=64175 Len=10
                  06:10:59.06	PC -> XPP	TCP	[TCP Retransmission] 49550 -> 2345 [PSH, ACK] Seq=2216181 Ack=4289469384 Win=64175 Len=10
                  06:11:00.43	PC -> XPP	ARP	Who has XPP? Tell PC
                  06:11:00.43	XPP -> PC	ARP	XPP is at 00:80:a3:..:..:..
                  06:11:03.86	PC -> XPP	TCP	[TCP Retransmission] 49550 -> 2345 [PSH, ACK] Seq=2216181 Ack=4289469384 Win=64175 Len=10
                  06:11:13.47	PC -> XPP	TCP	49550 -> 2345 [RST, ACK] Seq=2216191 Ack=4289469384 Win=0 Len=0
                  06:11:13.49	XPP -> PC	Syslog	USER.ERR:     00 14:54:27 main.c: read failed -1 -114
                  06:11:13.49	XPP -> PC	Syslog	USER.NOTICE:     00 14:54:27 main.c: closed
                  The frame (TCP Seq=2216181) has been sent 6 times (5 repetitions) before the PC gave up and closed the socket. In this time (almost 20 seconds!), the XPP did not ACK the TCP transmission and also did not ACK the RST frame.
                  But it answered immediately to the ARP request and the syslog message "read failed" has been sent immediately after the reception of the RST frame.

                  So, we suspect the TCP stack of the XPP to not ACK frames. The problem showed up within 15 hours uptime (see syslog)! There was about 2 MB of payload data.

                  Here is the sample application (compiled with Evolution OS 5.2.0.5B13) that has been used on the test devices:

                  Code:
                  #include <evolution.h>
                  #include <evolution_libs.h>
                  #include <evolution_stdio.h>
                  #include <evolution_http.h>
                  #include <evolution_cli.h>
                  #include <evolution_socket.h>
                  #include <evolution_tlog.h>
                  #include <evolution_errno.h>
                  #include <startup.h>
                  
                  typedef int socket_t;
                  
                  static void mainTask(void);
                  static void handleClient(socket_t lClientSocket);
                  
                  
                  int SDKMain(struct command_line *commandLine, struct http_server *httpServer)
                  {
                    (void) commandLine;
                    (void) httpServer;
                  
                    (void) RunThread(100, mainTask, "Main Task", 8192);
                  
                    return 0;
                  }
                  
                  
                  static void mainTask(void)
                  {
                    socket_t lServerSocket, lClientSocket;
                    uint32_t lSocketMode;
                    struct sockaddr rClientAddr;
                    struct sockaddr_in rServerAddr;
                    int lClientAddrLen;
                  
                    DELAY_THREAD(0, DLY_SECS, 10); // delay start of thread
                    TLOG(TLOG_SEVERITY_INFO, "Starting main thread");
                  
                    // create nonblocking server socket --
                    lServerSocket = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);
                  
                    // nonblocking
                    lSocketMode = 1;
                    ioctlsocket(lServerSocket, FIONBIO, &lSocketMode);
                  
                    // bind server socket
                    memzero(&rServerAddr, sizeof(rServerAddr));
                    rServerAddr.sin_family = AF_INET;
                    rServerAddr.sin_addr.s_addr = htonl(INADDR_ANY);
                    rServerAddr.sin_port = htons(2345);
                  
                    (void) bind(lServerSocket, (struct sockaddr *) &rServerAddr, sizeof(rServerAddr));
                    (void) listen(lServerSocket, 3);
                  
                    while(true)
                    {
                      lClientAddrLen = sizeof(rClientAddr);
                      lClientSocket = accept(lServerSocket, &rClientAddr, &lClientAddrLen);
                      if (lClientSocket >= 0)
                      { // new connection
                        handleClient(lClientSocket);
                  
                        // blocking mode
                        lSocketMode = 0;
                        ioctlsocket(lClientSocket, FIONBIO, &lSocketMode);
                        closesocket(lClientSocket);
                      }
                      DELAY_THREAD(0, DLY_MSECS, 100);
                    }
                  }
                  
                  
                  static void handleClient(socket_t lClientSocket)
                  {
                    fd_set rSocketMask;
                    struct timeval rTimeout;
                    int lRes;
                    char chLog[50];
                    uint8_t bRx[100];
                    uint32_t lTimeout;
                  
                    while (true)
                    {
                      FD_ZERO(&rSocketMask);
                      FD_SET(lClientSocket, &rSocketMask);
                      memzero(&rTimeout, sizeof(rTimeout));
                      lRes = selectsocket((lClientSocket + 1), &rSocketMask, NULL, NULL, &rTimeout);
                      if (lRes < 0)
                      { // Socket-Fehler
                        (void) snprintf(chLog, sizeof(chLog), "selectsocket failed %d %d", lRes, errno);
                        TLOG(TLOG_SEVERITY_ERR, chLog);
                        break;
                      }
                  
                      if (lRes > 0)
                      { // receive new data
                        memzero(bRx, sizeof(bRx));
                        lRes = recv(lClientSocket, bRx, (sizeof(bRx) - 1), 0);
                        if (lRes < 0 || lRes > (int) sizeof(bRx))
                        {
                          (void) snprintf(chLog, sizeof(chLog), "read failed %d %d", lRes, errno);
                          TLOG(TLOG_SEVERITY_ERR, chLog);
                          break;
                        }
                        if (lRes == 0)
                        { // socket is closed
                          TLOG(TLOG_SEVERITY_NOTICE, "socket closed by client");
                          break;
                        }
                  
                        (void) snprintf(chLog, sizeof(chLog), "RX %s", bRx);
                        TLOG(TLOG_SEVERITY_DEBUG, chLog);
                  
                        // echo rx data
                        lRes = send(lClientSocket, bRx, lRes, 0);
                        if (lRes < 0)
                        {
                          (void) snprintf(chLog, sizeof(chLog), "send failed %d %d", lRes, errno);
                          TLOG(TLOG_SEVERITY_ERR, chLog);
                          break;
                        }
                  
                        // wait for send to be finished
                        lTimeout = OSTimemarkMS();
                        while (true)
                        {
                          if (OSElapsedTimeCurrentMS(lTimeout) > 30000)
                          {
                            TLOG(TLOG_SEVERITY_ERR, "send timeout");
                            break;
                          }
                  
                          FD_ZERO(&rSocketMask);
                          FD_SET(lClientSocket, &rSocketMask);
                          memzero(&rTimeout, sizeof(rTimeout));
                  
                          lRes = selectsocket((lClientSocket + 1), NULL, &rSocketMask, NULL, &rTimeout);
                          if (lRes > 0)
                          { // send finished
                            TLOG(TLOG_SEVERITY_DEBUG, "TX finished");
                            break;
                          }
                        }
                      }
                  
                      DELAY_THREAD(0, DLY_MSECS, 50);
                    }
                  }
                  Please let me know if you need more information.

                  Comment


                  • #10
                    Have you tried the V5.4.0.0R7 SDK posted on this forum?
                    Please do, and report back.
                    I do not see anything immediately wrong with your code. I would have suspected to see a FIN in your trace - but if the device does not ACK the retransmission, aborting the connection is not rare.
                    Also, is the socket available for a new inbound connection at this time, or is it blocked? Does the XPP reboot during this period?

                    Comment


                    • #11
                      I repeated the test with V5.4.0.0R7 three times with the same result (see below).

                      The XPP device does not reboot (at least I did not receive syslog messages). After the connection is broken, the server socket is available for a new connection. But there was a (human) reaction time of several minutes/hours before the next socket connection was established. I do not know if it is possible immediately after this event.

                      The network trace with V5.4.0.0R7:
                      Code:
                      00:48:28.69	PC -> XPP	TCP	57608 -> 2345 [PSH, ACK] Seq=1361381 Ack=1361381 Win=63580 Len=10 "00136138\r\n"
                      00:48:28.72	XPP -> PC	Syslog	USER.DEBUG:     00 33:42:52 main.c: RX 00136138\r\n
                      00:48:28.72	XPP -> PC	TCP	2345 -> 57608 [PSH, ACK] Seq=1361381 Ack=1361391 Win=64240 Len=10 "00136138\r\n"
                      00:48:28.72	XPP -> PC	Syslog	USER.DEBUG:     00 33:42:52 main.c: TX finished
                      00:48:28.78	PC -> XPP	TCP	57608 -> 2345 [ACK] Seq=1361391 Ack=1361391 Win=63570 Len=0
                      
                      00:48:28.91	PC -> XPP	TCP	57608 -> 2345 [PSH, ACK] Seq=1361391 Ack=1361391 Win=63570 Len=10 "00136139\r\n"
                      00:48:28.92	XPP -> PC	Syslog	USER.DEBUG:     00 33:42:53 main.c: RX 00136139\r\n
                      00:48:28.92	XPP -> PC	TCP	2345 -> 57608 [PSH, ACK] Seq=1361391 Ack=1361401 Win=64240 Len=10 "00136139\r\n"
                      00:48:28.92	XPP -> PC	Syslog	USER.DEBUG:     00 33:42:53 main.c: TX finished
                      00:48:28.97	PC -> XPP	TCP	57608 -> 2345 [ACK] Seq=1361401 Ack=1361401 Win=63560 Len=0
                      
                      00:48:29.13	PC -> XPP	TCP	57608 -> 2345 [PSH, ACK] Seq=1361401 Ack=1361401 Win=63560 Len=10 "00136140\r\n"
                      00:48:29.44	PC -> XPP	TCP	[TCP Retransmission] 57608 -> 2345 [PSH, ACK] Seq=1361401 Ack=1361401 Win=63560 Len=10 "00136140\r\n"
                      00:48:30.05	PC -> XPP	TCP	[TCP Retransmission] 57608 -> 2345 [PSH, ACK] Seq=1361401 Ack=1361401 Win=63560 Len=10 "00136140\r\n"
                      00:48:31.25	PC -> XPP	TCP	[TCP Retransmission] 57608 -> 2345 [PSH, ACK] Seq=1361401 Ack=1361401 Win=63560 Len=10 "00136140\r\n"
                      00:48:32.98	PC -> XPP	ARP	Who has XPP? Tell PC
                      00:48:32.98	XPP -> PC	ARP	XPP is at 00:80:a3:..:..:..
                      00:48:33.65	PC -> XPP	TCP	[TCP Retransmission] 57608 -> 2345 [PSH, ACK] Seq=1361401 Ack=1361401 Win=63560 Len=10 "00136140\r\n"
                      00:48:38.46	PC -> XPP	TCP	[TCP Retransmission] 57608 -> 2345 [PSH, ACK] Seq=1361401 Ack=1361401 Win=63560 Len=10 "00136140\r\n"
                      00:48:48.06	PC -> XPP	TCP	57608 -> 2345 [RST, ACK] Seq=1361411 Ack=1361401 Win=0 Len=0
                      00:48:48.07	XPP -> PC	Syslog	USER.ERR:     00 33:43:12 main.c: read failed -1 -114
                      What do you mean by "aborting the connection is not rare"?

                      Comment


                      • #12
                        [Seems my reply got lost...]
                        Connection abort - only as it applies to the network peer not responding. Why bother sending a FIN or RST if the connection is already lost. (Not important)

                        Please zip and send me direct garrym@lantronix.com the unfiltered sniffer trace showing the connection startup through the problem, including 1 - 2 minutes following the problem.

                        Does this problem exist in the standard firmware - ala, without your task running?

                        Comment

                        Working...
                        X