[Bro] Using BRO for measuring TCP flow bandwidth

[Harkeerat Bedi]

Thank you Vern for your feedback. I am still working on this problem. I
tested your suggestion of using "-f tcp", but I could not see any
difference.

This post is divided in three parts:

1. I have one basic question regarding the way BRO works. My confusion is as
follows:

Which is the main event handler in BRO that "usually" updates the
c$duration, c$orig$size and c$resp$size variables of the connection object?

In my case I believe, the event handler for updating the duration and sizes
for the connection when a new packet is observed is not being called when
BRO is reading from live traffic. However, it is being called with BRO reads
from TCPDUMP.

2. Regarding your suggestion on my use and invocation of the
connection_established event, I have made some changes to my policy file and
attached the same to this mail. Can you kindly provide your feedback on
this.
I do not schedule the connection_established event anymore, I have defined
another event (conn_bitrate_updater), which I schedule from the
connection_established event. I have also tried to define the semantics of
future execution of this event.

3. Regarding your last comment: "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"
Can you suggest how can I address this scenario?

Kindly provide your feedback regarding the above.

Thank you,

Regards,
Harkeerat Bedi


On Sun, Aug 22, 2010 at 5: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
> _______________________________________________
> Bro mailing list
> bro at bro-ids.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/bro
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20100830/54fa9270/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ex2e.bro
Type: application/octet-stream
Size: 1196 bytes
Desc: not available
Url : http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20100830/54fa9270/attachment.obj