[Snort-devel] Stream4 woes ??

Lawrence Reed Lawrence.Reed at ...1489...
Tue Mar 11 05:48:34 EST 2003

Just a thought....

When the ubi_trTraverse returns with bd.total_size != stream_size around 
line 3883 ( in spp_stream4.c v1.137 2003/03/03)  can we assume we have 
either missed a packet or have a "bad" stream?  If we do not process 
this packet would that eliminate the problem?  Is there any valid reason 
to be inside this if statement?  It seems like this piece of code is 
trying to "make up" for something gone awry,  a task that is impossible 
at this point in the processing.

/* walk the packet tree (in order) and rebuild the app layer data */
 (void)ubi_trTraverse(s->dataPtr, TraverseFunc, &bd);

    if(bd.total_size != stream_size)
        DEBUG_WRAP(DebugMessage(DEBUG_STREAM, "stream_size(%u) != 
bd.total_size(%u), "
                                "that's bad, m'kay?\n", stream_size, 

        stream_size = bd.total_size;

        stream_pkt->pkth->caplen = ETHERNET_HEADER_LEN + IP_HEADER_LEN +
            TCP_HEADER_LEN + stream_size;
        stream_pkt->pkth->len = stream_pkt->pkth->caplen;

        stream_pkt->iph->ip_len = htons( (u_short) (IP_HEADER_LEN +
                                                    TCP_HEADER_LEN + 
stream_size) );


Chris Green wrote:

>"Lawrence Reed" <Lawrence.Reed at ...1489...> writes:
>>Packet loss can probably cause this.  Are you dropping any packets?
>Just to clarify what he's refering to is snort having "holes" in the
>sequence numbers where it's has a dirty buffer that is used for
>holding the stream packet data.
>To test this, try seeing if adding a
>bzero(stream_pkt->pkt, 2048); to line 3584 of spp_stream4.c and
>running snort again.  If they all go away, it's packet loss. Try a
>smaller ruleset, increasing your memcaps, or CVS HEAD.

Larry Reed  Lawrence.Reed at ...1489...
NOAA IT Security Office
PGP Public Key:  http://search.keyserver.net:11371/pks/lookup?op=get&search=0x7A998772

More information about the Snort-devel mailing list