[Snort-devel] Stream5 issue

Emiliano Fausto emiliano.fausto at ...2499...
Sat Mar 28 09:29:51 EDT 2015


Hello Arun,

I'd suggest you to read this article:
http://blog.securityonion.net/2011/10/when-is-full-packet-capture-not-full.html

I had similar troubles too some time ago because of it.

Also depending on what you are trying to capture, this option could also be
influencing the capture:

-k *checksum-mode*

Controls which packet checksums Snort computes and verifies. Valid checksum
modes include all, noip, notcp, noudp, noicmp, and none. This can be used
to eliminate packets that fail their checksums - caused either by network
faults or IDS evasion attempts

Maybe if  your checksum is known to fail, you may  put: "-k none"

Hope it helps!!

Regards,
Emiliano.

On Sat, Mar 28, 2015 at 1:34 AM, Arun Koshal <akoshal04 at ...2499...> wrote:

> Hi,
>
> I have written a dynamic preprocessor for inspecting some custom
> application. This dynamic preprocessor depends on stream5 preprocessor from
> getting the TCP stream. I am using snort in PCAP mode. I am facing
> following very strange problems -
>
> 1. The data in the rebuilt stream given by stream5 does not match with the
> TCP sequence number. For example - for a given TCP packet the sequence
> number in packet (pkt->tcp_header->sequence) is 507351850, but the data in
> pkt->payload is actually same as that of some old packet, having TCP
> sequence number 507343162. This scenario happens in case there are lot of
> packets getting dropped. I confirmed this with wireshark packet capture and
> I have observed multiple such instances. I also noticed that I am getting
> all the packets in the same buffer (pkt->payload remains same for all
> packets). So it seems like that I am getting a new packet with new header
> but old data. If I configure the pcap buffer_size as 512MB, the packets do
> not drop and this problem does not happen.
>
> 2. The second problem that I faced was with the pcap snap_len. In my
> setup, I had snort running with default pcap snap_len. I noticed that snort
> was not receiving packets having 1448 bytes data (1500 bytes, excluding
> Ethernet header). On reducing the MTU of the traffic generator from 1500 to
> 1484, Snort started receiving those packets. As a workaround, I increased
> the snap_len in sfdaq.c to 1546. Is this behaviour correct?
>
> It would be really great if someone can provide some inputs on these
> issues.
>
> Thanks and regards.
> Arun
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website,
> sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for
> all
> things parallel software development, from weekly thought leadership blogs
> to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Snort-devel mailing list
> Snort-devel at 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!
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.snort.org/pipermail/snort-devel/attachments/20150328/584d65e7/attachment.html>


More information about the Snort-devel mailing list