[Bro] Strange Issue with Live Capture

[Andrew Benson]

I had them correct the issue, they were in fact sending us duplicates of
packets.

The issue still persists, though. I'm not sure what else to check?

Is there anything like a timeout that could be set that'd be causing it to
assuming the connection never completed?

I've just found out one of our other teams has been having a similar
problem, but with 2.3 only. They had discussed it with Liam, but never
found a resolution. It's weird I'm having the same issue with both 2.1 and
2.3

--
AndrewB
Knowing is Half the Battle.

On 26 January 2015 at 12:57, Andrew Benson <abenson at gmail.com> wrote:

> I just had an epiphany when thinking about your response: the site we're
> dealing with configured the SPAN incorrectly. Looking back through, I'm
> seeing *every* packet twice. I think they configured it to SPAN every port
> on that switch, including the SPAN. I'm going to have them fix that, maybe
> use the VLANs as the source as I had originally directed them.
>
> --
> AndrewB
> Knowing is Half the Battle.
>
> On 26 January 2015 at 12:38, Andrew Benson <abenson at gmail.com> wrote:
>
>> 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 else.
>>
>> --
>> AndrewB
>> 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/20150127/d105b821/attachment-0001.html