[Snort-devel] DAQ dump: load-mode passive on dummy interface vs read-file
mike.cox52 at ...2499...
Tue Mar 1 09:53:12 EST 2016
Thanks. I probably should have mentioned it in the initial email but I'm
replaying at 100 Mbps and tried at 10 Mbps with the same results.
On Mon, Feb 29, 2016 at 4:21 PM, abed mohammad kamaluddin <abedamu at ...2499...
> Generally this should happen if packets are sent at a rate higher than
> what snort can process, or the packet ordering is messes up resulting
> in lots of TCP discards. In your case since there are no drops, the
> ordering should be the issue. One way to get consistent results using
> tcpreplay is to replay at very low rates ( using pps or M option) -
> this works for us.
> Abed M K
> > Message: 2
> > Date: Thu, 25 Feb 2016 08:18:11 -0500
> > From: Mike Cox <mike.cox52 at ...2499...>
> > Subject: [Snort-devel] DAQ dump: load-mode passive on dummy interface
> > vs read-file
> > To: "snort-devel at lists.sourceforge.net"
> > <snort-devel at lists.sourceforge.net>
> > Message-ID:
> > <
> CANXgGSLh0WGj0XRAwDqkvQC1r1XgujZ5fLumi21nYrjXDVGhtQ at ...2500...>
> > Content-Type: text/plain; charset="utf-8"
> > When I run a pcap thru snort using the dump DAQ and
> > '--load-mode=read-file', everything works great.
> > snort -Q --daq dump --daq-dir /usr/lib/daq/ --daq-var
> > --pcap-list="my.pcap" -k none ...
> > But when I try to have Snort listen on a dummy interface (that is set to
> > promiscuous mode) and then use tcpreplay to send traffic to that
> > Stream6 has all kinds of issues:
> > snort -Q --daq dump --daq-dir /usr/lib/daq/ --daq-var --load-mode=passive
> > -i dummy0 -k none ...
> > (The rest of this email discusses the dummy0/tcpreplay scenario and I'm
> > replaying at a low(ish) rate and confirming no packet drops in Snort nor
> > the interface.)
> > When the pcap replay is done, Snort is left in a state with a lot of
> > unflushed data. Looking at the stats when Snort exits, there are a lot
> > TCP discards. Turning on some debugging messages shows a number of these
> > errors:
> > Pkt ack is out of bounds, bailing!
> > bad sequence number, bailing
> > bad timestamp, bailing
> > I also see some of these (example):
> > packet PAWS timestamp way too far ahead oflast packet 1456349637 0...
> > Note the '0' at the end which is the value of talker->ts_last_pkt
> > (timestamp of last packet seen -- not the TCP Options timestamp but epoch
> > of when Snort saw the packet).
> > I also see a lot of "one offs" like this:
> > out of order segment (tdb->seq: 0xC3F899C l->r_nxt_ack: 0xC3F899D!
> > So my questions is, what is different with having Snort listen on the
> > interface vs reading the pcap file? Every time I run the same pcap with
> > tcpreplay, I don't get the same issues from the same segments and
> > segments end up being queued and not flushed. I'm also unable to reduce
> > the issue to a single stream or a small pcap (if I carve out a single
> > stream or portion that was exhibiting issues in the larger pcap and run
> > it does fine). This looks to be Stream6 thing and turning on/off PAF,
> > normalize, running in inline-test mode, etc. produces the same results.
> > For some reason the segments aren't being processed properly resulting in
> > TCP discards and ultimately unflushed data.
> > This may not be a Snort thing but something strange about the dummy
> > interface and/or the dump DAQ but I thought I'd ask here in case anyone
> > any insight or dealt with this before.
> > I'm testing on Snort 18.104.22.168 and DAQ 2.0.5 on CentOS 7 64-bit.
> > Thanks!
> > -Mike Cox
> > -------------- next part --------------
> > An HTML attachment was scrubbed...
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> Snort-devel mailing list
> Snort-devel at lists.sourceforge.net
> Please visit http://blog.snort.org for the latest news about Snort!
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Snort-devel