Thanks for the confirmation! Yeah, I know those knobs help increase performance, but we intentionally disable NIC offloading features to ensure that the sniffing processes get the pure network traffic with no reassembly or other manipulation by the NIC. This helps to ensure that the sensor sees and interprets the traffic the same way the end host does. For more info, please see: http://securityonion.blogspot.com/2011/10/when-is-full-packet-capture-not-full.html?m=1
Thanks, Doug On Tuesday, December 25, 2012, Daniel Borkmann wrote: > On Mon, Dec 24, 2012 at 4:28 PM, Doug Burks > <[email protected]<javascript:;>> > wrote: > > We recently discovered an issue with the default scatter-gather I/O: > > > https://groups.google.com/d/topic/security-onion-testing/OuD7xt7nQuI/discussion > > > > Questions: > > > > - Is it expected behavior for the default scatter-gather mode to wait > > several minutes before writing packets to disk if on a low-traffic > > network? > > > > - We're working around this by setting the "-c" option to disable > > scatter-gather mode when running on low-traffic networks. Is this the > > best workaround? > > Yes, if you're expecting a low traffic volume, then using normal > read(2)/write(2) operation (-c) are totally fine and the best way to > do it. > > Scatter-gather is for normal - higher volumes of traffic where a > syscall is avoided until a batch of packets have been collected. > > > - Is scatter-gather mode dependent on scatter-gather being enabled on > > the NIC? We currently disable NIC offloading features like this: > > post-up for i in rx tx sg tso ufo gso gro lro; do ethtool -K $IFACE $i > off; done > > No, it's not dependent, it's a normal Linux/Unix syscall facility. For > low traffic, you probably don't need tso, gso et al. For high traffic > volumes, it might be better in terms of performance to turns those > knobs on. > > -- > > > -- Doug Burks http://securityonion.blogspot.com --
