[prev in list] [next in list] [prev in thread] [next in thread] 

List:       snort-devel
Subject:    Re: [Snort-devel] DAQ dump: load-mode passive on dummy interface vs read-file
From:       Mike Cox <mike.cox52 () gmail ! com>
Date:       2016-03-01 14:53:12
Message-ID: CANXgGS+qDapxQkveeO_F2ksovXGDdADGOt2gzC4NCwPgbUEF1g () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


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.

-Mike Cox

On Mon, Feb 29, 2016 at 4:21 PM, abed mohammad kamaluddin <abedamu@gmail.com
> wrote:

> 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@gmail.com>
> > Subject: [Snort-devel] DAQ dump: load-mode passive on dummy interface
> >         vs      read-file
> > To: "snort-devel@lists.sourceforge.net"
> >         <snort-devel@lists.sourceforge.net>
> > 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
> Snort-devel@lists.sourceforge.net
> 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!
>

[Attachment #5 (text/html)]

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



------------------------------------------------------------------------------
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
Snort-devel@lists.sourceforge.net
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!

[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic