Bug (?) in TCP_Contents

Zeek
1

When Bro sees an ACK for a packet before the packet
itself (packet reordering), it considers that it already
delivered the packet to the upper protocols, because
it's acked. (see TCP_Contents.cc, line 272).

I was wondering whether this is the intended behavior
or it's a bug.

Note, that's *not* packet reordering in the sense of a network phenomenon.
Causality requires that acknowledgments come *after* the packets they
acknowledge!

So it's intended behavior. It only becomes a problem in traces for which
causality is broken. Unfortunately, this can happen due to reading from
multiple NICs which have large buffers. If this is a problem in your
environment, you can use packet_sort_window to sort the packets based
on timestamps (assuming your NICs timestamp them correctly - if not,
then all is lost ...).

    Vern

2

Greetings,

bro-pub-0.9a4a$ make
...
g++ -I. -I.. -Ilibedit -O -c main.cc
In file included from PacketFilter.h:9,
                 from Sessions.h:29,
                 from RuleMatcher.h:12,
                 from main.cc:54:
PrefixTable.h:48: error: struct PrefixTable::iterator redeclared with different
access
main.cc: In function `int main(int, char**)':
main.cc:319: error: array bound forbidden after parenthesized type-id
main.cc:319: note: try removing the parentheses around the type-id
*** Error code 1

bro-pub-0.9a4a$ gcc --version
gcc (GCC) 3.4.2 [FreeBSD] 20040728

bro-pub-0.9a4a$ uname -v
FreeBSD 5.3-BETA7 #0: Sat Oct 2 21:01:00 UTC 2004