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

Mike Cox <[email protected]>
Newsgroups gmane.comp.security.ids.snort.devel
Message-ID <CANXgGSJSq57k=h9nJVkQWy8YsMFEzLyH1G4N2rGfQ+zXHC0CRw@mail.gmail.com>
Could this be related to PAWS?  Does pcap read mode ignore TCP Timestamp
Options?

Thanks.

-Mike Cox

On Thu, Feb 25, 2016 at 8:18 AM, Mike Cox <[email protected]> wrote:

> 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
>

------------------------------------------------------------------------------
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!
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.