[Snort-devel] DAQ dump: load-mode passive on dummy interface vs read-file

abed mohammad kamaluddin abedamu at ...2499...
Mon Feb 29 16:21:18 EST 2016


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




More information about the Snort-devel mailing list