[Bro] Using BRO for measuring TCP flow bandwidth

[Harkeerat Bedi]

Thank you for this Sridhar. Allow me to work on this.

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/20100831/223e4ea4/attachment.html