[Snort-users] beginners,pls help. A puzzle about StoreStreamPkt() in spp_stream4.c
mkettler at ...4108...
Wed Jul 23 09:43:27 EDT 2003
At 09:05 AM 7/23/2003 +0800, =?gb2312?B?1Pgg0KHBog==?= wrote:
> I think there's something wrong when snort tries to reassemble TCP
> stream in StoreStreamPkt() function in spp_stream4.c. In
> StoreStreamPkt(), if it finds out the packet we just receive
> is un-ack'd, then it looks for this packet in the tree like this:
> returned = (CStreamPacketData *) s->dataPtr->SptFind((ItemPtr)spd);
> The reason for removing the old packet in the tree is that
> retransmitted segments can include more or less data than the original.
> But the point is it's not enough just using removing and inserting
> mechanism. In "TCP/IP Illustrated Volume 2: The Implementation" Stevens
> gave an example of data out of order in chapter 27 "TCP Function"(
> exactly in 27.9.2 "TCP_REASS Function") like this: there're already two
> segments existing, one containing octets from 4 to 8, the other
> containing octets from 10 to15. Then the new segments arrives and it
> containes octets from 7 to 10. See, there're repeated octets in all these
> three segments. How can StoreStreamPkt() deal with this case by just
> using removing and inserting mechanism--no old one in the tree so just
> insert the new one into the tree or an old one already there just remove
> it and inset the new one?
I think that the over-lap case is handled in BuildPacket(), so that
StoreStreamPkt doesn't have to care about over-lapping segments. But I'm
not a snort-devel, so you'll have to really read the code to get an idea of
how it's done...
however at casual glance it doesn't seem to be an issue if there's
duplication due to overlap in the stream, because it all gets re-assembled
into a single "packet" before it's passed off to the snort rules anyway.
I think the only reason there's any deletion of exact duplicates is just to
avoid wasting memory...
More information about the Snort-users