[Bro] wrong size computation

[Vincenzo Falletta]

Here it is a sample... it is just an handshake but if you run

$bro -r to-brolist_anonym.pcap brolite

you will see in the conn.log file the BIG computation mistake...

Cheers,
	Vincenzo :-)


Ruoming Pang (庞若鸣) wrote:
>> As regards the way bro deals with the number of bytes transferred for
>> each connection, it seems that bro DOES NOT keep a variable in which
>> incrementally stores the sum of each packet size for all the packets
>> involved in that very connection, but instead does a certain computation
>>  (i wonder how...) involving only the first and the last packet in the
>> connection... Am I correct?
> 
> 
> Yes, for TCP connections Bro computes connection sizes based on TCP
> sequence numbers.
> 
>> I'm asking this question because I've found something very strange.
>> In bro's conn.log file there are lines like this:
>>
>> Dec  1 00:22:53 1.058870 A B http 49331 80 tcp 886477697 ? RSTOS0 L
>>
>> (yes it's correct, 800MB in 1 second) but if I look at the trace, this
>> is what I see:
>>
>>      A              B
>>    49331  -->    80 (SYN)        Seq=0,Ack=0
>>    49331  <--    80 (ACK)        Seq=0,Ack=0
>>    49331  -->    80 (RST)        Seq=0,Ack=188164531
>>
>> (Only 3 packets transferred...)
>>
>> Of course there's some bug in these hosts, but bro should not be
>> misleaded in computing the amount of bytes transferred inside a
>> connection. Could someone explain me what's happening here?
> 
> 
> This is weird. Could you please send me the trace file?
> 
> I think there are two separate issues here:
> 
> 1. How Bro comes up with the 800MB number and whether the ack sequence
> in the RST packet should be taken into computation. We need to look at
> the trace to find out.
> 
> 2. In general, Bro connection sizes can be incorrect in weird cases, and
> if you want accurate numbers in your measurements, my suggestions (and
> what we did in our measurements) are: (a) if you have all packets in
> your traces, there's a Bro script (Vern?) to sample packets very
> efficiently to estimate connection size, even in the case the sequence
> numbers wrap around a number of times, which then can be used to
> validate the connection size; (b) if all you have are SYN, FIN, and RST
> packets, you can make some assumption about the bandwidth of the link to
> check if the connection size makes sense.
> 
> Ruoming
> 
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: to-brolist_anonym.pcap
Type: application/octet-stream
Size: 212 bytes
Desc: not available
Url : http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20051207/3d8965d5/attachment.obj