Romain Francoise wrote: > Robert Edmonds <edmo...@debian.org> writes: > > > for instance, a snapshot length of 1514 actually results in only a > > maximum of 1498 bytes being captured, so those who think they are > > doing "full packet capture" actually are not, thus breaking TCP > > stream reassembly and IP defragmentation, potentially blinding > > sensors that depend on libpcap. > > Sure it's possible, but quite unlikely. People who want to do "full > packet capture" usually set snaplen to 65535, which is the default > for tcpdump, ngrep, tcpflow, etc.
no, we don't. setting the snaplen to ~64K means the MMAP'd packet capture ring needs to allocate ~64K of unswappable kernel memory for each frame in the ring buffer. the default ring buffer size used in libpcap is 2 megabytes, which means only a tiny number of frames can be buffered with a 64K snaplen. generally 2 MB is a quite small buffer to use on a busy network even with a correctly tuned snapshot length, so one needs to increase the ring buffer size as well. snort sets the default snapshot length to 1514, so it is quite broken by this bug. -- Robert Edmonds edmo...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
