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.
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
- SYN followed immediately by RST, ACK: the destination host is reachable but nothing is accepting the connection on that port, or a device is actively rejecting it.
- RST after application data: an endpoint or intermediary aborted an established connection. Look at the last request, response and idle interval.
- RST after a long idle period: an application timeout, stateful firewall timeout or stale pooled connection is plausible.
- RST after retransmissions: connectivity trouble may have exhausted an application or TCP timeout.
- RST with unusual TTL, IP ID or timing: compare it with ordinary packets from the alleged sender; an intermediary may have injected it.
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
- Filter
tcp.flags.reset == 1. - Choose a reset and isolate its TCP stream.
- Identify the apparent sender.
- Inspect handshake, last data and timing.
- Correlate with application and firewall logs.
With PCAPNG Analyzer
- Upload or mount the capture.
- Review the TCP Flags chart for RST volume.
- Open the packet list and filter TCP flags for
RST. - 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