conn.log conn_state field or documentation is wrong


There is an issue where the conn.log conn_state field will contain RSTR, which according to the documentation means "Established, responder aborted."

The problem that I notice is that I see log entries where conn_state is RSTR, but conn_history does not contain an 'h'. Additionally, the resp_h is absolutely not running a service on resp_p and the orig_h is usually in the process of a tcp scan.

Here are the top frequencies of RSTR without an h over about a weeks worth of conn logs:

Compared to histories that did contain an h:

I don't have a pcap for this, but I believe many of the weird connections are related to scans or backscatter.

I'm not sure if the code is wrong or the documentation is wrong, but I don't see how a fin+reset connection could be classified as established.

Also, One thing that would be a nice documentation addition is the answer to this question:

Given a conn.log entry, how do determine if there was a connection established? I thought it would be if the state was in 'SF S1 S2 S3 RSTO RSTR', but RSTR is problematic...




Vern Paxson
February 10, 2016, 9:03 PM

Yeah, historically "RSTR" was defined as established-but-responder-aborted, but that dates way back to a time when "surely" every connection began with a handshake, and RSTR was the observation that that connection ended with a RST sent by the responder. I think the right fix for this ticket is to correct the documentation to state that it simply means that the entity that Bro determined/inferred was the responder sent a RST.

Johanna Amann
March 1, 2016, 10:10 PM

topic/johanna/bit-1535 updates the documentation of RSTR to "Responder sent a RST"


Robin Sommer


Justin Azoff



External issue ID



Affects versions