Splunk App for Stream: Is there any detailed information on field meanings?

[Shisa]

Is there any detailed information about field meanings in the Splunk App for Stream?
I see the doc, but need more detailed information on the following.
http://docs.splunk.com/Documentation/StreamApp/6.1.0/DeployStreamApp/Whattypeofdatadoesthisappcollec...

On source=“stream:tcp”;
-Does “tcp_status=1” mean src_ip send RST packet to dest_ip on 3-way handshaking phase?
-What is the exact meaning of “tcp_status=2”
-When you use source=“stream:tcp”, why does “refused” not appear? In my test environment, "refused" only appears on app protocol like "stream:http".
-Is it right that “time_taken” means how long a Stream flow takes to complete?
-How do you calculate “missing_packets_out” and “missing_packets_in” values from the packet data?

Any information would be helpful to me, thank you.

[vshcherbakov_sp · Accepted solution]

Hello Shisa,

tcp_status=1 means that the server (dest_ip) sent RST packet in response to the SYN packet during TCP handshake

tcp_status=2 means that the TCP handshake request (SYN packet) was ignored, i.e. the SYN packet wasn't answered and the flow timed out

When you use source=“stream:tcp”, “refused” is not appeared? In my test environment, "refused" is only appeared on app protocol like "stream:http".

This is a bug: you're correct, the "refused" field is only set for HTTP protocol (oops..) I created STREAM-2529 ticket to track this bug. Is it critical for you to get the "refused" field working? BTW, the field description is also incorrect - it should read "1 if the flow was terminated with RST, 0 if not"

Is it right that “time_taken” means how long a Stream flow takes to complete?

Depends on the protocol: generally it means "how long an event has taken to complete" where an event can be a HTTP/DNS request/response, MySql query/server response, etc. or the whole flow (stream:tcp and stream:udp source types)

How do you calculate “missing_packets_out” and “missing_packets_in” values from the packet data

We increment missing_packets_in/out counts every time Stream's TCP reassembly engine encounters a gap in TCP sequence it cannot reassemble (i.e. too many packets with higher TCP sequence have arrived, etc.) in the corresponding (ingress/egress) TCP stream.