[Bro] [EXTERNAL] Re: &expire_func functionality/verification with pcap

[Lamps, Jereme]

Pulling the thread a little more: 

I waited a few minutes after tcpthrowing the test.pcap and then tcpthrew a small pcap consisting of three pings. This was unfortunately not enough to trigger the connection_state_remove event for any of the other flows. I also tried creating a pcap that consisted of test.pcap followed by 3 pings 4 minutes later and running that through Bro with no luck. Do you think there is something additional going on underneath the hood? 

In the conn.log I can verify the “ts” jumped ~4minutes between the last flow from the first pcap and the starting flow the second pcap.

Best,

Jereme

On 10/31/17, 10:42 AM, "Seth Hall" <seth at corelight.com> wrote:

    
    
    On 31 Oct 2017, at 10:09, Lamps, Jereme wrote:
    
    >   *   Having Bro read in a 1GB test.pcap, waiting for minutes (with 
    > exit_only_after_terminate=T), then CTRL-C to exit
    >   *   Having Bro listen on a dummy interface and tcpthrow the 
    > test.pcap against it, waiting for minutes then CTRL-C to exit
    >
    > It seems to work for a subset of the connections but not all of them. 
    > My hunch is that Bro’s connection state table has no strict 
    > time-based removal process, so the connection_state_remove event will 
    > not be triggered unless I throw more data at it
    
    I believe that's correct.  The combination of the 
    exit_only_after_terminate setting and reading a pcap is not particularly 
    well supported because it's not needed for most circumstances.  It's 
    also conceptually hard to pull off cleanly because Bro's packet clock is 
    driven by incoming packet timestamps.  The reason you aren't seeing 
    those connections expire is because as far as Bro is concerned time has 
    stopped the moment that packets stop coming in.
    
       .Seth
    
    --
    Seth Hall * Corelight, Inc * www.corelight.com