[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