[Bro] Using BRO for measuring TCP flow bandwidth

sridhar basam sridhar.basam at gmail.com
Mon Aug 23 03:02:32 PDT 2010


Sorry, i don't know why you are seeing a difference between the live and
offline trace.

Here is something i have used in the past to look at similar things you are
trying to get at. I expanded the connection structure to include a last
recorded timestamp. Then use the new_packet or tcp_packet event to compare
network_time to the last recorded time (or connection close) to do the
printing vs the timer event.

 Sridhar

On Sun, Aug 22, 2010 at 6:38 PM, Vern Paxson <vern at icir.org> wrote:

> > My question is why does BRO appear to behave differently when reading
> from a
> > tcpdump or an interface. Kindly advice.
>
> It's not clear to me just why you're seeing the difference.  The symptoms
> suggest that the live run is using a different packet filter (in
> particular,
> the default SYN/FIN/RST-only filter), and thus after the connection is
> established, there's no input to update things further.  However, if so
> then you should have that same effect running on the trace.
>
> You could test for this by running with a filter "-f tcp", which will
> capture all TCP packets.
>
> Note that your script misuses the connection_established event.  It's not
> meant to be generated at the script-level, and the semantics of executing
> it again 5 seconds in the future are undefined.  (Also, timing for
> executing
> such scheduled events is actually driven by the arrival of traffic, so
> that would be another potential difference between the live execution vs.
> the trace one.  But again I don't offhand see why it would lead to
> different
> results.)
>
>                Vern
>



-- 
Sridhar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20100823/efe2d046/attachment.html 


More information about the Bro mailing list