Bro always crashes

[Vern Paxson]

Thanks for sending the trace.  The problem is that either you have
split routing, in which the monitor isn't seeing both sides of most
connections, or the packet filter is dropping a whole lot of packets,
so that effectively the monitor again doesn't see both sides.

So Bro sees patterns like:

	A.1234 -> B.80  SYN
	...
	A.1234 -> B.80  FIN

without seeing a SYN-ack from B.80 in between.  This then leads to
Bro holding state for the half-established connection after it sees
A.1234 -> B.80.

That's arguably a bug, it should just flush the connection after it sees
the half-close.  The patch below makes it does this, and then instead of
requiring 100+ MB to process the file you sent me, it needs about 20 MB.

Give it a try and let me know how well it works.

		Vern


*** TCP.cc-	Thu May  6 16:49:13 1999
--- TCP.cc	Thu May  6 16:50:26 1999
***************
*** 1711,1718 ****
  			// connection has likely terminated.
  			if ( (orig->did_close && resp->did_close) ||
  			     (orig->state == TCP_RESET ||
! 			      resp->state == TCP_RESET) )
! 				{ // Either both closed, or one RST.
  				// The Timer has Ref()'d us and won't Unref()
  				// us until we return, so it's safe to have
  				// the session remove and Unref() us here.
--- 1711,1720 ----
  			// connection has likely terminated.
  			if ( (orig->did_close && resp->did_close) ||
  			     (orig->state == TCP_RESET ||
! 			      resp->state == TCP_RESET) ||
! 			     (orig->state == TCP_INACTIVE ||
! 			      resp->state == TCP_INACTIVE) )
! 				{ // Either both closed, or one RST, or half-opened.
  				// The Timer has Ref()'d us and won't Unref()
  				// us until we return, so it's safe to have
  				// the session remove and Unref() us here.