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.
Upload the capture and PCAPNG Analyzer’s Network health separates connections refused with a reset from all other resets, lists the destinations that never answered, and rates TCP good, warning or poor. Any conversation then opens as a stream, so you can see the last data each side sent before the reset.
See network health in a sample report →Find every reset
In Wireshark, use:
tcp.flags.reset == 1To 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 == 443On 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.flagsWireshark 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 42Then 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.dstportA 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 the capture.
- Read the TCP connections section of Network health: refused connections, all resets and unanswered destinations.
- Filter the packet list for RST, or follow the stream to see what came just before the reset.
Refused connection attempts (a SYN answered with a reset) are counted separately from other resets, and the destinations that never answered are listed. As with Wireshark, the packets can’t say which device generated a reset: a firewall, load balancer or intrusion-prevention system can inject one using an endpoint’s addresses.
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 tiersDownload free