TCP connection logs are generated by tcp.bro.  The summaries are written
to stdout, one line per connection:

	start-time duration protocol orig-bytes resp-bytes \
	local-addr remote-addr state flags additional

	start-time: timestamp of when the connection's first packet was
		observed

	duration: time until connection finished, in seconds, or '?' if
		not determined

	protocol: TCP protocol, if well-known port; or portmapper request

	orig-bytes: total bytes sent by originator.  Computed from difference
		between starting and ending sequence numbers, so sometimes
		wrong (if wrong, the values tend to be erroneously large)

	resp-bytes: same for bytes sent by connection responder

	local-addr: IP address of local end of connection
	remote-addr: IP address of remote end of connection
		Note that these would make more sense as originator/responder,
		but for historical reasons they're defined in terms of
		"local" and "remote", where "local" is specified by the
		"local_nets" set in hot.bro.  To pull out the originator
		and responder addresses requires looking at the "flags"
		field to see whether the connection originated locally.

	state: final connection state (see below)

	flags: some characteristics of the connection.  The most important is
		the 'L' flag, which if present indicates that the connection
		was initiated by the local address (see above); otherwise
		it was initiated by the remote address.

	additional: protocol-specific additional information, such as the FTP
		session identifier, telnet user name, finger request, or
		portmapper results.

The scripts "hot-report" and "mon-report" (in the aux/scripts/ directory) 
generate readable versions of these connection summaries.  They include
a mnemonic indicating the connection's state.  Here is the list of
abbreviations used:

	Symbol	Name	Meaning
	------	-------	-------------------
	}	S0	Initial SYN seen, no reply seen ("unanswered")
	>	S1	Initial SYN handshake seen ("established")

	>	SF	Established and normal FIN handshake seen
			for termination.  Note that this is the same
			symbol as for state S1.  You can tell the two
			apart because for S1 there will not be any
			byte counts, while for SF there will be.

	[	REJ	Initial SYN elicited RST in reply ("rejected")

	}2	S2	Established and FIN from originator only seen
	}3	S3	Established and FIN from responder only seen

	>]	RSTO	Established, originator sent a RST to terminate
	>[	RSTR	Established, responder sent a RST to terminate

	}]	RSTOS0	Originator sent a SYN followed by a RST,
			we never saw a SYN ack from the responder
	<[	RSTRH	Responder sent a SYN ack followed by a RST,
			we never saw a SYN from the originator

	>h	SH	Originator sent a SYN followed by a FIN,
			we never saw a SYN ack from the responder
			(so "half" open)
	<h	SHR	Responder sent a SYN ack followed by a FIN,
			we never saw a SYN from the originator

	?>?	OTH	No SYN seen, just midstream traffic

The sundry weird states can arise from broken TCPs, but also from split
routing in which Bro just sees one side of a connection.

For UDP, if we see a request but no reply, that's state S0 ("}"); a request
followed by a reply is SF (">"); and a reply but no request is SHR ("<h").