# delayed bro operation **URL:** \ **Category:** Zeek\ **Created:** [April 24, 2015, 9:16am UTC](https://community.zeek.org/t/delayed-bro-operation/3569 "2015-04-24T09:16:11Z")\ **Posts on this page:** 10\ **Page:** 1
**Author:** ![Franky](https://avatars.discourse-cdn.com/v4/letter/f/958977/32.png) [@Franky](https://community.zeek.org/u/Franky)\ **Post date:** [April 24, 2015, 9:16am UTC](https://community.zeek.org/t/delayed-bro-operation/3569/1 "2015-04-24T09:16:11Z")
Hi. A policy forces me to run bro in a separate network. So the captured PCAPs are transfered to the bro network for logging purposes. How would I handle delays in feeding bro with the PCAPS? Would connections spanning multiple PCAPs be a problem? My first idea is to crank up all the timeouts like this: redef tcp\_inactivity\_timeout = 5 days; redef udp\_inactivity\_timeout = 5 days; redef icmp\_inactivity\_timeout = 5 days; redef default\_file\_timeout\_interval = 5 days; What performance penalty will I suffer? I guess the RAM usage will grow, because connections, which were not cleanly terminated, would hang around for a long time. Are there any examples for this kind of setup? How would you search for this? Have a nice weekend! Franky ---
**Author:** ![Seth\_Hall3](https://avatars.discourse-cdn.com/v4/letter/s/d6d6ee/32.png) [@Seth\_Hall3](https://community.zeek.org/u/Seth_Hall3)\ **Post date:** [April 24, 2015, 2:23pm UTC](https://community.zeek.org/t/delayed-bro-operation/3569/2 "2015-04-24T14:23:50Z")
> A policy forces me to run bro in a separate network. So the captured PCAPs are > transfered to the bro network for logging purposes. How would I handle delays > in feeding bro with the PCAPS? Would connections spanning multiple PCAPs be a > problem? This is a problem that PacketBricks[1] will be able to solve eventually. It’s not there yet, but eventually you’ll be able to create a load balancing architecture with persistent Bro/Snort/Suricata/etc processes and tell PacketBricks to read PCAPs as you get them in place (and, yes, I did just say clustered PCAP processing!). Unfortunately this scenario is not quite ready in PacketBricks. > redef tcp\_inactivity\_timeout = 5 days; > redef udp\_inactivity\_timeout = 5 days; > redef icmp\_inactivity\_timeout = 5 days; > redef default\_file\_timeout\_interval = 5 days; You could always try, but I get the sense you won’t be terribly happy with the result. 1. [GitHub - bro/packet-bricks: A netmap-based packet layer for distributing and filtering traffic.](https://github.com/bro/packet-bricks)   .Seth ---
**Author:** ![Franky](https://avatars.discourse-cdn.com/v4/letter/f/958977/32.png) [@Franky](https://community.zeek.org/u/Franky)\ **Post date:** [April 27, 2015, 7:29am UTC](https://community.zeek.org/t/delayed-bro-operation/3569/3 "2015-04-27T07:29:43Z")
Hi. ---
**Author:** ![Franky](https://avatars.discourse-cdn.com/v4/letter/f/958977/32.png) [@Franky](https://community.zeek.org/u/Franky)\ **Post date:** [July 7, 2015, 12:11pm UTC](https://community.zeek.org/t/delayed-bro-operation/3569/4 "2015-07-07T12:11:11Z")
Hi, just as a follow up: I experimented with a patched version of tcpslice which opens pcaps and sends them to a fifo. When there are no more pcaps, it blocks, but keeps the fifo open. Bro reading from that fifo will also block until data is sent. With this setup I get the same results as if I merged the pcaps before processing them with bro. So my worries about timers in bro were uncalled-for. If anyone is interested in this, just drop me a mail. Franky ---
**Author:** ![Seth\_Hall3](https://avatars.discourse-cdn.com/v4/letter/s/d6d6ee/32.png) [@Seth\_Hall3](https://community.zeek.org/u/Seth_Hall3)\ **Post date:** [July 7, 2015, 2:15pm UTC](https://community.zeek.org/t/delayed-bro-operation/3569/5 "2015-07-07T14:15:05Z")
Hah! That’s an interesting approach.   .Seth ---
**Author:** ![dataolle](https://avatars.discourse-cdn.com/v4/letter/d/53a042/32.png) [@dataolle](https://community.zeek.org/u/dataolle)\ **Post date:** [July 16, 2015, 10:19am UTC](https://community.zeek.org/t/delayed-bro-operation/3569/6 "2015-07-16T10:19:27Z")
sounds intreresting. Would it be possible for you to make that tcpslice patch available? Thanks! //Kristoffer ---
**Author:** ![Jim\_Mellander](https://avatars.discourse-cdn.com/v4/letter/j/e47c2d/32.png) [@Jim\_Mellander](https://community.zeek.org/u/Jim_Mellander)\ **Post date:** [July 17, 2015, 3:54am UTC](https://community.zeek.org/t/delayed-bro-operation/3569/7 "2015-07-17T03:54:37Z")
I addressed a similar problem by writing a little C program that takes pcaps and pushes them onto a virtual network interface, for bro to monitor… Now let me see if I can find that code. ---
**Author:** ![Franky](https://avatars.discourse-cdn.com/v4/letter/f/958977/32.png) [@Franky](https://community.zeek.org/u/Franky)\ **Post date:** [July 20, 2015, 12:37pm UTC](https://community.zeek.org/t/delayed-bro-operation/3569/8 "2015-07-20T12:37:58Z")
Hi Jim! > I addressed a similar problem by writing a little C program that takes pcaps and pushes them onto a virtual network interface, for bro to monitor… Now let me see if I can find that code. we thought about that, but the disadvantage is, that all the timestamps get lost. Also we had a lot of problems with lost packets. Franky ---
**Author:** ![Jim\_Mellander](https://avatars.discourse-cdn.com/v4/letter/j/e47c2d/32.png) [@Jim\_Mellander](https://community.zeek.org/u/Jim_Mellander)\ **Post date:** [July 21, 2015, 5:01am UTC](https://community.zeek.org/t/delayed-bro-operation/3569/9 "2015-07-21T05:01:41Z")
Hi Frank: My application was a bit different - was receiving live pcaps from a multitude of sensors, and pushing them all in realtime onto the virtual interface, so the timestamp offset was negligible - this was also fairly low bandwidth - obviously, different applications require different tools. ---
**Author:** ![system](https://canada1.discourse-cdn.com/flex011/uploads/zeek/original/1X/f09d732bc2cc7c7cc7e35db67cf4e1d5233ce7a7.png) [@system](https://community.zeek.org/u/system)\ **Post date:** [May 6, 2022, 3:42pm UTC](https://community.zeek.org/t/delayed-bro-operation/3569/10 "2022-05-06T15:42:37Z")