The resulting filtered packet stream is then handed up to the next layer, the Bro ``event engine.'' This layer first performs several integrity checks to assure that the packet headers are well-formed. If these checks fail, then Bro generates an event indicating the problem and discards the packet.
If the checks succeed, then the event engine looks up the connection state associated with the tuple of the two IP addresses and the two TCP or UDP port numbers, creating new state if none already exists. It then dispatches the packet to a handler for the corresponding connection (described shortly). Bro maintains a tcpdump trace file associated with the traffic it sees. The connection handler indicates upon return whether the engine should record the entire packet to the trace file, just its header, or nothing at all. This triage trades off the completeness of the traffic trace versus its size and time spent generating the trace. Generally, Bro records full packets if it analyzed the entire packet; just the header if it only analyzed the packet for SYN/FIN/RST computations; and skips recording the packet if it did not do any processing on it.
We now give an overview of general processing done for TCP and UDP packets. In both cases, the processing ends with invoking a handler to process the data payload of the packet. For applications known to Bro, this results in further analysis, as discussed in § 6. For other applications, analysis ends at this point.
TCP processing. For each TCP packet, the connection handler (a C++ virtual function) verifies that the entire TCP header is present and validates the TCP checksum over the packet header and payload. If successful, it then tests whether the TCP header includes any of the SYN/FIN/RST control flags, and if so adjusts the connection's state accordingly. Finally, it processes any data acknowledgement present in the header, and then invokes a handler to process the payload data, if any.
Different changes in the connection's state generate different events. When the initial SYN packet requesting a connection is seen, the event engine schedules a timer for T seconds in the future (presently, five minutes); if the timer expires and the connection has not changed state, then the engine generates a connection_attempt event. If before that time, however, the other connection endpoint replies with a correct SYN acknowledgement packet, then the engine immediately generates a connection_established event, and cancels the connection attempt timer. On the other hand, if the endpoint replies with a RST packet, then the connection attempt has been rejected, and the engine generates connection_rejected. Similarly, if a connection terminates via a normal FIN exchange, then the engine generates connection_finished. It also generates several other events reflecting more unusual ways in which connections can terminate.
UDP processing.
UDP processing is similar but simpler, since there is no connection state,
except in one regard. If host A sends a UDP packet to host B with a
source port of 
and a destination port of 
, then Bro considers
A as having initiated a ``request'' to B, and establishes
pseudo-connection state associated with that request. If B subsequently
sends a UDP packet to A with a source port of and destination
, then Bro considers this packet to reflect a ``reply'' to the
request. The handlers (virtual functions) for the UDP payload data can
then readily distinguish between requests and replies for the usual case
when UDP traffic follows that pattern. The default handlers for UDP
requests and replies simply generate udp_request and
udp_reply events.