Introduction
When using Wireshark for network analysis, there are many cases in which we see TCP Resets (Display filter: tcp.flags.reset==1). Is it a problem? This is what we will talk about in this article.
Shortly explained, in regular operation, TCP opens connection in 3 packets: the connection initiator sends a packet with a SYN=”1” flag, get back a SYN=”1” and ACK=”1” from the receiver, the sender sends a packet with ACK=”1” and the connection opens.
Closing a connection in an orderly fashion, the party initiating the closure sends a message to the other party – I want to close the link, finish what you are still doing and let me know (FIN=”1”, ACK=”1”), the receiving party finishes processing the information still in it and replies: I finished (FIN=”1”), and then the same process happens in the other direction as well.
From here we see that three packets are required to open a connection and four packets are usually required to close the connection (there are cases in which the connection is closed slightly differently, we’ll get to it in another article). We see this in the next figure.
What are TCP Resets?
TCP Reset is intended for a situation where one of the parties wants to close the connection immediately, and not in an orderly manner by double FIN-ACK. The disadvantage is of course an unordered closure of a process, compared to the advantage which is the speed and savings in the transmitted packets.
A reset can be part of a normal process. If for example, you open a news site, you will see that at the opening of the home page, several dozen links will open (sometimes many dozens). When the page upload is complete, if all the links were closed normally, i.e. 4 packets to close each link, we would get hundreds of packets just for closing the page. For this reason, many websites will send resets on the connections opened to them after they sent all webpage information to the client, and this is a normal server behavior.
What can get wrong?
What are the abnormal conditions in which TCP resets are sent? In these situations, one party detects that something is wrong, and sends a reset to the other party. What is that “something” wrong? Let’s see.
Case one:
If you see that an SYN sent from the client receives a reset from the other side, it is probably someone blocking the attempt to open the connection, usually a Firewall. In the following example, we see that a computer with 10.0.0.3 tries to open Connection to 82.80.120.135 and for each SYN Which it sends is received back RST-ACK, i.e. Reset.
Case two:
One party finds a link problem (in TCP Connection) and sends a reset to the other party. A problem can have several things.
In the following screenshot, we see an example of a reset response of computer number 10.0.0.7, which is the Client that opened the link. We see here FTP communication, opened from Client 10.0.0.7 to Server 15.192.45.26. If we skip to Packet number 2057, we see the Client’s command – CWD (Change Working Directory). The server responds with a CWD Command Successful, then the Client sends a LIST command (ls in Linux), and for some reason immediately after it in the 2063 packet asks to close the link. The server that for some reason did not receive the request at this time, sends a reply in Packet number 2065, and the client who does not understand how it gets a reply after sending FIN-ACK, sends reset in packet number 2066.
Case three:
In this example, we see that client 10.0.0.4 continuously sends TCP resets to the server 93.184.221.240 (this is a web server that accepts packets on port 80). When we look at the time column, we see that resets are sent in short time intervals – 38µSec from the previous packet in packet 22075, 29µSec from the previous packet in packet 22076, and so on. We see also that although the server should stop sending packets to the client after it receives a reset, the server keeps sending them. From here we can assume that packets were captured on the client-side (10.0.0.4) and they did not arrive at the server – therefore the server keeps sending packets on this connection although resets were sent to it. Looks like packet losses on the connection between them.
There are many other cases in which we will see resets – we will talk about them in another article and of course you can attend one of our Wireshark courses.
