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!