Detecting TCP resets with Wireshark and tshark

A TCP RST abruptly terminates or refuses a connection. Finding the flag is easy; explaining which endpoint generated it and why requires the packets around it.

By Stuart Mathieson6 minute readWireshark + tsharkUpdated 25 September 2026

Find every reset

In Wireshark, use:

tcp.flags.reset == 1

To focus on a host or service, combine it with another condition:

tcp.flags.reset == 1 && ip.addr == 10.20.30.40
tcp.flags.reset == 1 && tcp.port == 443

On the command line, print a compact reset inventory:

tshark -r capture.pcapng -Y "tcp.flags.reset == 1" \
  -T fields -E header=y \
  -e frame.number -e frame.time_relative \
  -e ip.src -e tcp.srcport -e ip.dst -e tcp.dstport \
  -e tcp.seq -e tcp.ack -e tcp.flags

Wireshark documents tcp.flags.reset and the related TCP fields in its TCP field reference.

Identify who sent the RST

The source address on the RST packet is the apparent sender. That does not always mean the endpoint application generated it: firewalls, load balancers and intrusion-prevention systems can inject resets using an endpoint's addresses.

Right-click the reset and apply Conversation Filter → TCP, or note its tcp.stream and filter:

tcp.stream eq 42

Then inspect the beginning and end of the conversation.

Recognise common reset patterns

RST does not carry a reason code.

The packet tells you the connection was reset, not which process, policy or human decision caused it. Application logs and captures from both sides are often needed for a firm conclusion.

Count resets by source

For a quick per-packet list suitable for aggregation:

tshark -r capture.pcapng -Y "tcp.flags.reset == 1" \
  -T fields -e ip.src -e tcp.srcport -e ip.dst -e tcp.dstport

A high total can be harmless if it comes from internet background scanning. Concentrate on resets involving important internal services, resets that follow valid application exchanges, or changes relative to a known-good capture.

Manual method vs PCAPNG Analyzer

Manual method

  1. Filter tcp.flags.reset == 1.
  2. Choose a reset and isolate its TCP stream.
  3. Identify the apparent sender.
  4. Inspect handshake, last data and timing.
  5. Correlate with application and firewall logs.

With PCAPNG Analyzer

  1. Upload or mount the capture.
  2. Review the TCP Flags chart for RST volume.
  3. Open the packet list and filter TCP flags for RST.
  4. Narrow by IP, port and time, then inspect decoded layers.

Find resets in a filterable capture report

Keep packet data on your own infrastructure while you inspect protocols, conversations, TCP flags and individual frames.

Compare tiersSelf-host it