1

I'm working on a C# application, handling TCP sockets.

I have a server application (Hercules) on the remote machine, trying to keep a socket open.
I have my application on my machine, subscribing to that open socket.

I'm using Microsoft's TCPViewer to follow what's happening.

After some minutes, I see the socket turning from an established into a time wait state, and then the socket connection drops.

I've been looking on both computers' event viewer for event ID 4227 in all general locations (Windows Logs/Application, /Security, /Setup, /System and /Forwarded Events) but I found nothing.

What should I do in order to know which machine is actually closing the TCP socket and why?

Improve this question
6
  • You need to take a traffic capture using windump - a windows port of tcpdump, then use wireshark to see who was first to send FIN. Commented Dec 21, 2022 at 10:51
  • @drookie: Thanks for your quick reply. I know the ports which are used in both connections, I have started a Wireshark capture, having following filter: tcp && (ip.addr==10.2.13.144 && ip.addr==10.1.6.160). How will I be able to recognise the "FIN"? Will it appear in the Protocol column or in another column? Or will my capture simply stop continuing? (Keep in mind that I have a remote desktop connection to that machine) Commented Dec 21, 2022 at 11:04
  • @Dominique: see wiki.wireshark.org/TCP-4-times-close.md for how to use Wireshark to find out about connection close and interpret the output. You then need to check which sides sends the FIN first - this side is closing the connection. As for why the side closes the connection - this can not be seen from the packet capture but you need to understand the application protocol spoken between these systems to understand if this is normal behavior and if not check for implementation bugs or error messages etc Commented Dec 21, 2022 at 11:40
  • @SteffenUllrich: Thanks for your quick reply. I'm currently testing TCP sockets and I would like to understand why they get closed after a while. Your URL is very helpful for that, but I seem having some problems with Wireshark: I have modified my filter into tcp && (ip.addr==10.2.13.244 && ip.addr==10.1.6.160) && tcp.flags.fin but although I've added the tcp.flags.fin flags, I keep seeing TCP packets where that flag is not set. Just for confirmation: the TCP FIN flag, that's the one I should be looking for, right? Commented Dec 21, 2022 at 12:18
  • @Dominique: yes, FIN is the one you are looking for. Try tcp.flags.fin==1 Commented Dec 21, 2022 at 12:28

1 Answer 1

Reset to default
1

What should I do in order to know which machine is actually closing the TCP socket

In order to find out which side closes the connection you need to do a packet capture. See https://wiki.wireshark.org/TCP-4-times-close.md how a connection close looks in Wireshark. The party who sends the initial FIN is the one which closed the connection.

... and why?

This is impossible to say just by looking at the traffic. A connection might get closed because the application layer protocol expects or allows it to do. It might get closed because either client or server crash. It might be closed by a party due to a violation of the protocol, i.e. if the other side behaves differently than expected ... So in order to find out the reason you need to understand the application protocol, look at log files, check if processes are running etc.

Improve this answer
2
  • Do you know how I can find out which application is sending that TCP FIN command? I know which application is starting the connection, but is it possible that another application, or another part of the Docker application, is actually closing the socket? Commented Dec 21, 2022 at 14:18
  • 1
    @Dominique: unless you have some really weird setup (like deep packet inspection firewalls fiddling with the traffic) the connection is established and closed by the same application. Of course, this application might also be some reverse proxy which sits in front of your backend, but from the perspective of the client the connection is then established with the reverse proxy, not the backend. Commented Dec 21, 2022 at 14:25

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.