[Bro] Using BRO for measuring TCP flow bandwidth

[sridhar basam]

Below is the gist of what i was suggesting. You need to clean it up so that
you catch the pre connection established phase and connection close case etc
but you get the idea.

global conn_print: table[conn_id] of time;
global print_delay = 1 sec;

event connection_established(c: connection)
{
  conn_print[c$id] = network_time();
}

event new_packet (c: connection,p: pkt_hdr)
{
  if ( network_time() >= print_delay + conn_print[c$id] ) {
       print network_time(), c$id, c$orig$size, c$resp$size;
       conn_print[c$id] = network_time();
  }
}

 Sridhar



On Mon, Aug 30, 2010 at 5:20 AM, Harkeerat Bedi <hsbedi at memphis.edu> wrote:

> Thank you Sridhar for your feedback and time. I am still working on this
> problem. To recall, in my case BRO seemed to be behaving differently when
> reading from a live interface or a TCPDUMP.
>
> My previous experiment setup was as follows.
>
> Setup1:
> Node1 (Client) <------>   Node2 (running BRO) < ------ > Node3 (Server)
>
> Node1 (the client) was sending TCP traffic to Node3 (the server) via Node2
> (which is running BRO). And the output of BRO on this live traffic was not
> as expected. However, if I ran BRO on the TCPDUMP of the same traffic the
> output was as expected. (As shown in my previous email).
>
> Now, as I was experimenting, I noticed that if
> I rearrange the experiment as follows:
>
> Setup2:
> Node1 (Client) <------> Node2 (Server + running BRO)
>
> I obtain the results as I wanted even on live traffic. I am able to obtain
> the periodically updated duration and sizes which then I use to calculate
> the bitrate.
>
> I was wondering, is the difference in behavior observed by BRO related to
> its location in the network?
> (In Setup1 it was an intermediate node, where as in Setup2 it is the
> terminal node.)
> Kindly provide your feedback if this makes any sense of gives any clues.
>
> Regarding your suggestion, I understand what you are implying, however I am
> not sure how to do it. Is it possible for you to provide me with a snippet
> of code so that I can follow it?
>
> Thank you in advance.
>
> Regards,
> Harkeerat Bedi
>
>
>
> On Mon, Aug 23, 2010 at 5:02 AM, sridhar basam <sridhar.basam at gmail.com>wrote:
>
>> 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
>>
>
>


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