<html dir="ltr">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css" id="owaParaStyle"></style>
</head>
<body fpstyle="1" ocsi="0">
<div style="direction: ltr;font-family: Tahoma;color: #000000;font-size: 10pt;">John,
<div><br>
</div>
<div>Thanks for the detailed info.  I'll have a look and get back to you.</div>
<div><br>
</div>
<div>Russ</div>
<div><br>
<div style="font-family: Times New Roman; color: #000000; font-size: 16px">
<hr tabindex="-1">
<div id="divRpF697699" style="direction: ltr; "><font face="Tahoma" size="2" color="#000000"><b>From:</b> John Eure [john.eure@...2499...]<br>
<b>Sent:</b> Thursday, January 30, 2014 10:51 PM<br>
<b>To:</b> snort-devel@lists.sourceforge.net<br>
<b>Subject:</b> [Snort-devel] 2 questions about Stream5 handling of missing data<br>
</font><br>
</div>
<div></div>
<div>
<div dir="ltr">
<div class="gmail_default" style="font-family:verdana,sans-serif">Hello,<br>
<br>
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 (2.9.6.0), 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.<br>
<br>
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.<br>
<br>
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?<br>
<br>
<br>
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.  :)<br>
<br>
</div>
<div class="gmail_default" style="font-family:verdana,sans-serif">Thanks,<br>
John Eure<br>
</div>
<div class="gmail_default" style="font-family:verdana,sans-serif"><br>
</div>
</div>
</div>
</div>
</div>
</div>
</body>
</html>