[Bro] Strange Issue with Live Capture

Andrew Benson abenson at gmail.com
Mon Jan 26 11:38:59 PST 2015

I think if it were getting multiple copies of each packet, it'd be logging
those as well. The dup3 on the card just duplicates the stream so each
process receives the same traffic. If a process attaches to the stream
(dag0:0, :2, and :4) that stream can't be attached from another process.

Looking back we had some time over the weekend when the traffic was a
little slower and it didn't have any errors. Likewise, we had a test at a
previous site (mockup of this one) that didn't have the issue, and we've
been using this setup for  a few years, this is just the first I've ever
seen this issue. It's just really weird.

I wonder how I could check to see if there's something causing bro to break
when talking to the card? It's just weird that I can't recreate it anywhere

Knowing is Half the Battle.

On 26 January 2015 at 12:23, Aaron Gee-Clough <lists at g-clef.net> wrote:

> Right, so if it works with the pcaps, then there's clearly a problem with
> bro's interaction with the card (hence my focusing on the load-balancing
> aspect). If you're not load-balancing but are duplicating, are you sure
> bro's not reading all three streams, and getting multiple copies of every
> packet?
> I don't have experience with the 7.5G4, so I'm not sure how dup3 works.
> aaron
> On 01/26/2015 02:14 PM, Andrew Benson wrote:
>> We are using the 7.5G4. We currently have it configured using dup3 to send
>> all the traffic three streams (snort, bro, and tcpdump), so we're not load
>> balancing between processes. I can verify against the pcaps that bro is
>> reading the packet. It shows the S0 for the handshake, and then OTH for
>> every packet after that. Every packet is accounted for.
>> --
>> AndrewB
>> Knowing is Half the Battle.
>> On 26 January 2015 at 10:21, Aaron Gee-Clough <lists at g-clef.net> wrote:
>>> If I were to bet, I'd guess it has something to do with how the Endace
>>> card is load-balancing packets across your bro workers. If the
>>> retransmission packets are ending up on different workers than the
>>> original session, then each worker will think it's got a new session,
>>> and log it accordingly.
>>> How do you have the Endace card configured? (for the 9.2X2 I have,
>>> n_tuple_select is the pertinent config option.)
>>> aaron
>>> On 01/26/2015 11:59 AM, Andrew Benson wrote:
>>>> We're currently using Endace DAG capture cards to feed directly to bro,
>>>> snort, and a rolling packet capture.
>>>> The network we're currently looking at has a high number of
>>> retransmissions
>>>> (at one point we counted 45% of traffic being retransmissions).
>>>> Bro is currently logging each packet as a separate connection in
>>> conn.log,
>>>> and is failing to run the protocol analyzers correctly (i.e. it'll
>>>> detect
>>>> it as FTP, but will only log the action, not the login, response).
>>>> What's weird is that if I run bro against the rolling pcap, it works
>>>> correctly. This problem only occurs when bro is listening to the device
>>>> directly.
>>>> This problem is still occurring with 2.3.1, so I'm at a loss. I enabled
>>> the
>>>> capture-loss module, and it's reporting 0%. The capture card doesn't
>>>> seem
>>>> to be dropping anything either.
>>>> Seen anything similar or have any suggestions for
>>>> troubleshooting/fixing?
>>>> --
>>>> AndrewB
>>>> Knowing is Half the Battle.
>>>> _______________________________________________
>>>> Bro mailing list
>>>> bro at bro-ids.org
>>>> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/bro
>>>>  _______________________________________________
>>> Bro mailing list
>>> bro at bro-ids.org
>>> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/bro
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20150126/74c6758e/attachment.html 

More information about the Bro mailing list