[Bro-Dev] TCP Reassembler question

Vern Paxson vern at icir.org
Wed Dec 22 18:20:55 PST 2010


> I have some questions regarding the TCP resassembler. I have a midstream
> NFS connection (i.e., no handshake) with tons of data.  The NFS analyzer can
> handle gaps and partial connections

Are you sure it does okay with those?  It's layered on top of the RPC
handler, and I would think that that will make it brittle to missing
byte-stream elements.

> * When I look at the packet level, I see data packets all the time, but
>   the analyzer's DeliverStreams stops being called somewhere half
>   through the trace.

If it's a huge trace, then I'm guessing you may be encountering wrap-round with:

        if ( seq_delta(start_block->seq, last_reassem_seq) > 0 ||
             seq_delta(start_block->upper, last_reassem_seq) <= 0 )
                return;

Or have you already converted all of those variables to 64-bit?

Alternatively, you may be running into the behavior I sketch in response
to your next question:

> * I don't get any calls to Undelivered() either (actually I get some,
>   at the very end of the trace, but the delivery stops way way earlier.

This sounds like skip_deliveries is getting set.  This can happen due
to the following logic:

        if ( Endpoint()->NoDataAcked() && tcp_max_above_hole_without_any_acks &&
             NumUndeliveredBytes() > tcp_max_above_hole_without_any_acks ) 
                {
                tcp_analyzer->Weird("above_hole_data_without_any_acks");
                ClearBlocks();
                skip_deliveries = 1;
                }
            
        if ( tcp_excessive_data_without_further_acks &&
             NumUndeliveredBytes() > tcp_excessive_data_without_further_acks )
                {
                tcp_analyzer->Weird("excessive_data_without_further_acks");
                ClearBlocks();
                skip_deliveries = 1;
                }

So it could be that you have enough loss at some point that you're tripping
over one of these thresholds.

> * I *don't* get content_gap and ack above hole message,
>   because the connections doesn't have a handshake. Can I force that
>   somehow? (So that I can debug where the gaps happen).

Changing this would require source-code edits, because it's wired in as:

	if ( content_gap &&
	     endpoint->state == TCP_ENDPOINT_ESTABLISHED &&
	     peer->state == TCP_ENDPOINT_ESTABLISHED )

(there's a comment before this explaining false positives that can result
for non-established connections, though I think it's reasonable giving
users an option to abide these possibilities)

		Vern


More information about the bro-dev mailing list