wrong size computation

Zeek
1

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...

Hmmm, this appears to be specific to brolite.bro. If I run on the trace
with mt.bro, it flags the sizes as "? ?", which seems fine in this case.
We'll look into it further.

    Vern

2

But if I turn on signature detection i.e. if I run

$bro -r to-brolist_anonym.pcap mt brolite-sigs

then I get AGAIN the same error... so what's up?

  Vince

Vern Paxson wrote:

3

It turns out that this comes down to the same thing -- in both cases
capture_filter sees a redef for tcp port 80. The problem can be stripped
down to just running

  $bro -r to-brolist_anonym.pcap tcp

with or without an additional

  redef capture_filters += { ["sig-http"] = "tcp port 80" };

The difference is that this redef causes Bro to see the second packet in
the trace (the pure ack), whereas leaving out the redef makes Bro only
use the capture filter given in tcp.bro, namely

  tcp[13] & 7 != 0

which is TCP SYN/FIN/RSTs only:

$ tcpdump -nn -r ~/to-brolist_anonym.pcap "tcp[13] & 7 != 0"
  reading from file /home/cpk25/to-brolist_anonym.pcap, link-type RAW (Raw IP)
  23:22:53.698694 IP 10.0.0.10.49331 > 10.1.1.10.80: S 2810067555:2810067555(0) win 8192 <mss 1460,nop,wscale 0,nop,nop,timestamp 590446704 0>
  23:22:54.757565 IP 10.0.0.10.49331 > 10.1.1.10.80: R 3696545253:3696545253(0) win 0

The difference in Bro's processing is that the presence of the ACK lets
it believe that it has actually seen the traffic (if I read TCP.cc
around 915 right).

It comes down to connection tracking semantics -- with a flow this
broken it's basically anyone's guess how big the connection was (without
counting real bytes, of course).

Cheers,
Christian.