[Bro] Using BRO for measuring TCP flow bandwidth

[Harkeerat Bedi]

Thank you Sridhar, Vern and Justin for your time and support. It is highly
appreciated. I was finally able to get the output I required - that is,
scheduled updates on the size and duration variables of the connection
object on live traffic.

I had tried -f filter option for TCP (-f tcp) earlier when it was suggested,
but it did not help then.

The trick was to use the -f filter option for either IP or TCP along with
the definition of an event handler like new_packet or tcp_packet in the
policy file. Using just the event handler without the filter, or just the
filter without the event handler did not work.

As Vern mentioned, the updates on the variables are driven by the generation
of the events, therefore even by defining an empty new_packet or tcp_packet
event handler, the connection object was getting updated and I was able to
get the desired output.

Thank you all once again, as without your support it would not have been
possible.

Thanks,
Harkeerat Bedi


On Mon, Aug 30, 2010 at 3:08 PM, sridhar basam <sridhar.basam at gmail.com>wrote:

> 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/20100903/96f6c2b4/attachment.html