Dan,
Thanks for the explanation. I see what you were doing now - just correcting the value of sslBytes to what it was prior to the core dump.
Let me explain a little bit about how AdjustSequence() works. For this explanation, assume that we're expecting sequence 1,000, our incoming sequence is 800, with length = 700. So, when we enter AdjustSequence():
expected = 1000
real = 800
Here we test if the sequence we just got is before what we are currently expecting. We may have already processed it (or some of it).
if (real + *sslBytes > *expected)
Here we catch the case where the sniffer has already consumed some of the front of the packet. In this example case, the overlap would be 200 (1000 - 800).
*sslFrame += overlap;
*sslBytes -= overlap;
As a result, we increment the frame pointer at offset 'real' by the overlap amount. We also decrease the length (sslBytes) by the overlap. This puts the frame pointer at 1,000 (the expected), and the sslBytes (length) at 500.
if (reassemblyList) {
word32 newEnd = *expected + *sslBytes;
if (newEnd > reassemblyList->begin)
Before just going ahead and processing bytes 1,000 - 1,500, we check to see whether the sniffer already has any of those bytes on the reassembly list. Let's say for this example that the reassembly list already has bytes 1,200 - 1,500.
We detect this case by checking whether newEnd (1,500) is ahead of the beginning of the reassembly list.
*sslBytes -= newEnd - reassemblyList->begin;
If so, we remove the bytes we already have on the reassembly list. In this example's case this would be:
500 -= 1500 - 1200, which is 200. This means we have to process bytes 1,000 through 1,200 and then the reassembly list can take over.
if (newEnd > reassemblyList->end)
The sniffer also does a check to catch the case where it has gotten some bytes which are past the end of the reassembly list - thus not on it yet. In this case, the end of the packet gets placed on the reassembly list.
Hopefully this helps clear things up a little.
- Chris