[Snort-devel] 2 questions about Stream5 handling of missing data

Russ Combs (rucombs) rucombs at ...3461...
Fri Jan 31 11:04:16 EST 2014


Thanks for the detailed info.  I'll have a look and get back to you.


From: John Eure [john.eure at ...2499...]
Sent: Thursday, January 30, 2014 10:51 PM
To: snort-devel at lists.sourceforge.net
Subject: [Snort-devel] 2 questions about Stream5 handling of missing data


I've been using snort to do some custom traffic inspection for a client, and have written a few plugins, including a preprocessor plugin that uses Stream5's Protocol Aware Flushing (PAF).  I've been testing out the new release (, and encountered a behavior that I hadn't seen before, and I'd like to find out whether it's a bug, or whether it's something I should be expecting.

Normally, every time my preprocessor plugin sees a packet, the Packet struct has been zeroed out (up to the ip_options field) and then filled with new data, so I get a clean struct each time.  In this release, Stream5 got some improvements in how it handles missing data.  (Thank you, Sourcefire!)  But when that new handling is triggered, I'm seeing packets that haven't been completely zeroed out.  Specifically, it's the Stream5 rebuilt pseudo-packet that is generated after the gap in the data, which hasn't been zeroed out before the new data was added.

I've been using a bit field (the preproc_reassembly_pkt_bits field) in the Packet struct to mark packets as having been accepted or rejected by my preprocessor, and so I was surprised to find that the bit field wasn't reset in between packets.  Is this normal behavior that I should be expecting?

Also, I've got a second, more general question, for Sourcefire.  After Stream5 detects missing data on a stream, PAF gets "reset", and the flush policy gets set to  STREAM_FLPOLICY_FOOTPRINT, and never goes back to STREAM_FLPOLICY_PROTOCOL again.  So far, I've been able to work around this, but I'd much rather have a solid fix in place.  So I was wondering, is this on your roadmap for future development?  At the very least, now you know there's at least one person interested in that feature.  :)

John Eure

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.snort.org/pipermail/snort-devel/attachments/20140131/495318d9/attachment.html>

More information about the Snort-devel mailing list