[Bro] Adjusting Bro snaplen caused multiple Security Onion systems to sporadically kernel panic

[Kevin Branch]

Seth,

Is it still OK to use "redef snaplen = *N*;" in my local.bro file if I want
to drop Bro's default snaplen to save PF_RING memory?  If so, how low would
you say "*N*" can be set to safely when jumbo frames are not involved?  I
got burned with sporadic kernel panics when I set N to *1514*.  I'd sure
appreciate your input.

Kevin

On Tue, Aug 4, 2015 at 10:18 AM, Kevin Branch <kevin at branchnetconsulting.com
> wrote:

> Hi Seth,
>
> Since getting involved with Security Onion over a year ago, I have really
> grown to appreciate the value that Bro brings to the NSM scene.  Thanks to
> you and the rest of the Bro community for your work on this!
>
> Not long ago I noticed that my Bro instances were eating up way more
> memory than necessary for my non-jumbo-frame environment because of the
> default snaplen of 8192, so based on what I saw in your comment here a
> couple of years ago:
>
> https://groups.google.com/d/msg/security-onion/qDU23hx6Q5g/xFeRDJbi9LsJ
>
> ... I added "redef snaplen = 1514;" to my local.bro file on 6 different
> Security Onion systems and reclaimed a heap of memory.  At first it seemed
> to work great but after a short while three completely separate systems
> start throwing kernel panics.  I finally traced it down to the snaplen
> change in Bro and upon raising the snaplen from 1514 to 1600, all kernel
> panics completely stopped.
>
> I am looking for your recommendation as to how low should be considered
> "safe" to change the Bro snaplen to for non-jumbo-frame environments, as
> well as to confirm that the old redef method I used to do this is still
> what should be used with modern Bro.
>
> I brought up my kernel panic issues on the Security Onion support list and
> am hoping to report back to them how changing Bro's snaplen can be safely
> used to save memory on systems where numerous Bro instances and/or large
> PF_RINGs are in use.  Here is that thread for your reference:
>
>
> https://groups.google.com/forum/#!searchin/security-onion-testing/kernel$20panic/security-onion-testing/H_21-0DGM6E/qnSt0BPA7lMJ
>
>
> Thanks again for a great tool!
> Kevin
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20150811/320245a3/attachment.html