Dropping all packets, but not crashed?

I noticed today while reviewing my notice.log that one worker thread has been consistently dropping all packets that it received…The status indicated that it was running, and a restart of the worker did not indicate that anything was crashed or that it exited oddly…After using broctl to restart the worker, no more notices…

I imagine it’s too late to gather more info about this now, but if the situation should present itself again, how would I gather the most debug information to try to find out why? Are there settings I should turn on now, or commands I should run at the time? strace, gdb, etc?

Is it too late to get more info about why this was happening?

I also just happened to visit the securityonion page and notice this at the top:

“An issue was recently discovered in Bro 2.1 when monitoring multiple interfaces with PF_RING that could result in traffic loss. This issue is targeted for resolution in Bro 2.2. In the meantime, if you’re monitoring multiple interfaces with Bro, please disable Bro’s PF_RING load balancing as follows:”

This could perhaps describe my situation…Anyone have any more specifics on this?

Cheers,

Jesse

We saw a very similar thing here - there ended up being an issue with
PF_RING < 5.5.2 where corrupted VLAN tagged packets caused the exact
situation you describe. We were seeing this 2-3 times a day.

I upgraded the PF_RING to 5.2.2 and the issue went away. This problem
is listed in the ChangeLog as well.

cheers,
scott

Thanks Scott!

I’m due for an upgrade on PF_RING so knowing this might be related is more fuel to the fire.

Cheers,

Jesse

Hi Jesse,

Regarding the note reported in the securityonion page, that issue would happen only when using PF_RING and multiple input interfaces. The issue comes because currently Bro does not support multiple PF_RING clusters (it supports configuring one single PF_RING cluster). If you are running a single interface, then this would not be your problem, otherwise, this could be a cause of packet drops.

Seth filed a ticket (Ticket #943) so this issue is being tracked already.

Cheers,

Jordi