Re: DAQ dump: load-mode passive on dummy interface vs read-file

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 <[email protected]>
> Subject: [Snort-devel] DAQ dump: load-mode passive on dummy interface
>         vs      read-file
> To: "[email protected]"
>         <[email protected]>
> Message-ID:
>         <CANXgGSLh0WGj0XRAwDqkvQC1r1XgujZ5fLumi21nYrjXDVGhtQ@mail.gmail.com>
> 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 --load-mode=read-file
> --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 interface,
> 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 on
> 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 of
> 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 dummy
> 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 different
> 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,
> 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 had
> any insight or dealt with this before.
>
> I'm testing on Snort 2.9.7.5 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!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
Snort-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/snort-devel
Archive:
http://sourceforge.net/mailarchive/forum.php?forum_name=snort-devel

Please visit http://blog.snort.org for the latest news about Snort!