Checking TCP disconnection reason

Projects Networking, Protocols, and Devices
1

My code opens a TCP connection to a server and before doing something, in the main loop checks if the connection is still active.
For some obscure reasons (Server disconnects, timeout ?) I see the connection dropping.
Is there a way (Flag, status) to understand why the server disconnected?

Any help is much appreciated.
Thanks,
Max

The relevant part of the code follows:

void loop()
{
  ThisLoopTime=millis();
  ThisLoopStatus=digitalRead(KeyInPin);
  DebounceRoutine();
  KeyingActions();

  if (RadioTCPChannel.connected())
  {
    if ( (ThisLoopTime-LastPingTime) > PingTimeInterval)
    {
      LastPingTime = ThisLoopTime;
      RadioCommand = "C" + String(SEQ).trim() + "|ping ms_timestamp=" + String(millis()).trim()+".0000\n";
      RadioTCPChannel.write(RadioCommand.c_str(), RadioCommand.length());
      SEQ++;
    }
  }
  else
  {
    RadioTCPChannel.stop();
    digitalWrite(BuiltInLED, HIGH);
    if (TeensyDebug)
    {
      Serial.println("Loop: Radio disconnected");
      Serial.print("link Status: "); Serial.println(Ethernet.linkStatus());
      Serial.print("hardware Status: "); Serial.println(Ethernet.hardwareStatus());
      Serial.print("socket Status: "); Serial.println(String(Ethernet.socketStatus(St)));
    }
    
    ConnectionHandle="";
    ClientHandle="";
    FlexConnect();
    FlexInit();
  }

  LastLoopStatus=ThisLoopStatus;
}
/* END loop() */
2

the connection is just exchange of packets. if no packets arrive there is no way to know why.

3

Can you post all of your code? Just showing loop doesn't help me understand what library you are using for TCP.
What board are you using?
Where is the server?
If the server is on your PC then you could run wireshark on that PC which may give you some clues about why it is disconnecting.

4

Hi Dave,
Thank you for spending time on my post.
The actual board is a Teensy 4.1 using the NativeEthernet.

/* LIBRARIES INCLUSION */
#include <SD.h>
#include "NativeEthernet.h"
#include <Audio.h>

The server is a standalone device, I can use an old HUB to connect the devices and WireShark packets.
Unfortunately this disconnection is very random and I should collect a lot of traffic to analyze.
That's why I was thinking about adding some extra debug code for having messages on the console.

5

Unfortunately I've never used that board or that library. I had a quick look through the header file for the library, but I didn't spot any obvious way of finding out the cause of a disconnection.
I'm much more familiar with the old school bsd API, which I started using about 25-30 years ago. Although the various wrapper libraries are convenient, I often find myself wondering how on earth to do something using a wrapper library that I know how to do using the bsd API.
I assume you know you can set the capture filter in wireshark to only capture the TCP stream that you are interested in. IDK if you could filter further on the close event (FIN?, RST?)
[Edit added] I don't know if you were seeing the error going via a router. I've found that some routers bin the TCP connection if there's been no traffic on it for a while. I usually send an application level TCP message every minute just to stop the router thinking it can bin it. I think that only applies to connections outside the local network where the router keeps a mapping of which host / port is the actual host that is using the TCP connection

6

Thanks again for looking at the library.
At the moment there is not any router in between the server and the client, just a switch which I'll replace with an HUB for sniffing.
I'll post my findings or any other thoughts from my side.
Max

7

It appears I’ve identified the issue. As previously mentioned, the board is a Teensy 4.1, and the Ethernet library in use is NativeEthernet.h. In my application, the server sends status messages every second, with some being quite verbose. Since I wasn’t utilizing these messages in the client code, I wasn’t reading or flushing the buffer. When the buffer fills up, the library seems to trigger a disconnection—though I’m not certain if this is intended behavior or a side effect.

1 Like
8

Thanks for letting us know. I wouldn't have expected the TCP/IP stack / wrapper library to close the socket because it was full of data that hadn't been read.

9

In my experience, behaviour depends on whether the stack has been set up with sensible window choices as compared with the amount of buffer space available. If that's been done, then the expected behaviour would be for the peer to respond with a 'zero window notification' - not just stop responding.
However some of the very small implementations used on microcontroller demo boards (for example) cut a lot of corners in these areas.
As suggested, a Wireshark trace will help the OP find out which end is misbehaving

1 Like
10

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.