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

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:

… 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:!searchin/security-onion-testing/kernel$20panic/security-onion-testing/H_21-0DGM6E/qnSt0BPA7lMJ

Thanks again for a great tool!


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.


Yes, it should be fine to do that but I really don’t know how that change in snap length affects pf_ring. It may not actually do anything (except apparently cause crashes!?).