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

[Kevin Branch]

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/20150804/2b387c61/attachment.html