TCP reset is an abrupt closure of the session. It causes the resources allocated to the connection to be immediately released and all other information about the connection is erased.
The Netdata Agent monitors the average number of sent TCP RESETS over the last 10 seconds. This can indicate a port scan or that a service running on the system has crashed. Additionally, it’s a result of a high number of sent TCP RESETS. Furthermore, it can also indicate a SYN reset attack.
See more about TCP Resets
TCP uses a three-way handshake to establish a reliable connection. The connection is full duplex, and both sides synchronize (SYN) and acknowledge (ACK) each other. The exchange of these four flags is performed in three steps: SYN, SYN-ACK, and ACK
When an unexpected TCP packet arrives at a host, that host usually responds by sending a reset packet back on the same connection. A reset packet is one with no payload and with the RST bit set in the TCP header flags. There are a few circumstances in which a TCP packet might not be expected.
The most common cases are:
A TCP packet received on a port that is not open.
An aborting connection
Half opened connections
Time wait assassination
Listening endpoint Queue is Full
A TCP Buffer Overflow
Basically, A TCP Reset usually occurs when a system receives data which doesn’t agree with its view of the connection.
When your system cannot establish a connection it will retry by default
Try using Wireshark to inspect the network packets.
Wireshark is a free and open-source packet analyzer. It is used for network troubleshooting, analysis, software and communications protocol development.
Since you might won’t be able to probe your traffic with wireshark in your host machine, You can export it in a dump file and analyze it in a second iteration.
Try to export the traffic in your host with
root@netdata # tcpdump -i any 'tcp[tcpflags] & (tcp-rst) == (tcp-rst)' -s 65535 -w output.pcap
You must stop the capture after a certain observation period (60s up to 5 minutes). This command
will create a dump file which can be interpreted by Wireshark that contains all the TCP packets with
RST flag set.
Copy this file in your workstation and examine it with Wireshark.
Identify which application sends TCP resets
Inspect the packet flow with a packet sniffer like Wireshark. You can consult the General
approach troubleshooting action in the current guide.
Check the instances of
RSTevents of the TCP protocol. Wireshark also displays the ports on
which the two systems tried to establish the TCP connection, (XXXXXX → XXXXXX).
To check which application is using this port, run the following code:
root@netdata # lsof -i:XXXXXX -P -n