[Bro-Dev] connection_established behavior

[Seth Hall]

This is related to this ticket: http://tracker.icir.org/bro/ticket/285

I am fairly lost on this, hopefully someone will have insight into the behavior.  In the following snippet of code, there's a strange behavior (maybe intentional?) where a packet with SYN/ACK flags set and no other packets related to the connection are seen, the connection_established event will be generated.

====CODE====
			if ( peer->state == TCP_ENDPOINT_SYN_SENT )
				peer->SetState(TCP_ENDPOINT_ESTABLISHED);
			else if ( peer->state == TCP_ENDPOINT_INACTIVE )
				{
				// If we were to ignore SYNs and
				// only instantiate state on SYN
				// acks, then we'd do:
				//    peer->SetState(TCP_ENDPOINT_ESTABLISHED);
				// here.
				Weird("unsolicited_SYN_response");
				}

			endpoint->SetState(TCP_ENDPOINT_ESTABLISHED);
====END CODE====

This only seems to be true when the connection compressor is disabled though.  The connection compressor *seems* to prevent this effect.  I'll include steps to reproduce the problem here and I'll attach the example tracefile to this email...

===POLICY SCRIPT (test.bro)===
@load conn
event connection_established(c: connection)
	{
	print fmt("gah! there shouldn't be a connection established (%s)", id_string(c$id));
	}
===END POLICY SCRIPT===

Here's the output with a connection established that shouldn't happen:
[seth at Blake build (master)]$ ./src/bro -C -f "ip"  -r connection_established-problem.trace test use_connection_compressor=F
1285716061.336160 weird: unsolicited_SYN_response
gah! there shouldn't be a connection established (128.146.242.61/3072 > 121.254.178.6/http)

Here's the (lack of) output with the connection compressor enabled:
[seth at Blake build (master)]$ ./src/bro -C -f "ip"  -r connection_established-problem.trace test use_connection_compressor=T
[seth at Blake build (master)]$ 

I also disabled the checksum validation because the TCP header has an invalid checksum in the packet for some reason.

Sorry for the long email, but any thoughts on the behavior of the sans connection compressor behavior?

  .Seth

-------------- next part --------------
A non-text attachment was scrubbed...
Name: connection_established-problem.trace
Type: application/octet-stream
Size: 100 bytes
Desc: not available
Url : http://mailman.icsi.berkeley.edu/pipermail/bro-dev/attachments/20101214/84bf1bbc/attachment.obj