[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