Context
Often we may need to analyze TCP dumps. The following provide the Wireshark Filters for such a case were TCP Connection reset are observed.Method
1) Set the following filter in your Wireshare prior to loading the TCP dump file:(tcp.flags.fin == 1 || tcp.flags.reset == 1 || tcp.flags.syn == 1) && tcp.port == 4333
This will show you all the session setups and teardowns with resets. This is a good starting point to the analysis.
2) Add a column to your display – Custom, using the field tcp.stream – this will enable you to sort the column to group the above to see all the steps for a connection bunched together.
3) Looks for packers where a there is a FIN from the server followed by a RST some time later.
4) Grab the tcp.stream value and do this filter: tcp.stream == <stream_number>
5) You may see an encrypted alert if using TLS. This may simply means that a close_notify was received. ‘tls.content_type == 21’ – the ‘TLS Alert’ message that we are seeing arrive before the session is torn down
Example 1 - Normal FIN-ACK followed by reset.
This is a normal tear down scenario of a typical session shutdown initiated by the client. The Reset is a normal response when an endpoint has already declared a FIN on the connection.
Example 2 - scenario and interpretations:
-No comms for a long period from the start of the capture – i.e., the connection was opened, but no data has been sent
-Client sends a block of data after being idle for 60+ seconds, commonly 31 bytes of payload
-Server sends a FIN to close the TCP connection
-Client ACKs the FIN but does not FIN in reply
-Another 14-22 seconds later, the client sends a block of data
-The server reacts by sending a RST
-Client sends a block of data after being idle for 60+ seconds, commonly 31 bytes of payload
-Server sends a FIN to close the TCP connection
-Client ACKs the FIN but does not FIN in reply
-Another 14-22 seconds later, the client sends a block of data
-The server reacts by sending a RST
Interpretation:
So, while a TCP reset is part of the sequence in this case, it’s a proper response, and the root issue is actually that the client is opening a connection and then never speaking over it.
So, while a TCP reset is part of the sequence in this case, it’s a proper response, and the root issue is actually that the client is opening a connection and then never speaking over it.
Notes
Quick filters that can be bookmarked in Wiresharks:- "TCP setup / teardown" (tcp.flags.fin == 1 || tcp.flags.reset == 1 || tcp.flags.syn == 1)
- "Slow host / TCP window exhaustion" tcp.analysis.zero_window || tcp.analysis.window_full
- "L1 failures / packet loss" tcp.analysis.duplicate_ack
- "L1 failures / packet loss" tcp.analysis.out_of_order
- "L1 failures / packet loss" tcp.analysis.retransmission
- "Asymmetric routing / multi-NIC" tcp.analysis.ack_lost_segment
You can also filter by IP ranges like: ip.addr == 10.1.2.3/24 and TCP ports: tcp.port == 4333
and specify ip.src / ip.dst or tcp.srcport / tcp.dstport
It is also helpful to sort by tcp.stream to group TCP setup/teardown activities, then drill into specific streams with a filter for tcp.stream == 999