Correct, sslFrame points to the current frame to process, whereas sslBytes is the data we haven't processed yet.

if (newEnd > reassemblyList->begin) {
    Trace(OVERLAP_REASSEMBLY_BEGIN_STR);
                    
        /* remove bytes already on reassembly list */
        *sslBytes -= newEnd - reassemblyList->begin;
}

To address the section you had in bold, shown above, newEnd is equal to the sequence number we expect plus the SSL bytes we need to consume. We check to see if newEnd is past the beginning of our first reassemblyList item.  If so, we might have frames that will be processed twice, so we want to remove those duplicates from being processed again (in sslBytes).

reassemblyList->end is not the same as *expected - they differ in purpose. The reassemblyList (a linked-list of pointers) caches packets which are out of order and can't be processed yet. reassemblyList->end is the end of the first item in the list, where *expected is the next sequence number we need to process.

if (newEnd > reassemblyList->end) {
    Trace(OVERLAP_REASSEMBLY_END_STR);
                    
    /* may be past reassembly list end (could have more on list)
       so try to add what's past the front->end */
    AddToReassembly(session->flags.side, reassemblyList->end +1,
        *sslFrame + reassemblyList->end - *expected + 1,
        newEnd - reassemblyList->end, session, error);
}

In the next block of code, shown above, we test whether newEnd is greater than the end of the first item in our reassemblyList. If it is, we may need to add that data into the reassemblyList (if it is not already there). This is done by the AddToReassembly function.

Does this help clear things up?

- Chris

static int AdjustSequence(...)


if(real < *expected){
    int overlap = *expected - real;
    *sslFrame += overlap;
    *sslBytes -= overlap;
}

if(reassemblyList) {
    word32 newEnd = *expected + *sslBytes*
  [b] if(newEnd > reassemblyList->begin){

        /* remove bytes already on reassembly list */
        *sslBytes -= newEnd - reassemblyList->begin;
    }[/b]

to my understanding, after performing the overlap shifting in the beginning of the function, the sslFrame pointer points exactly to where NEW data begins and the sslBytes holds the number of NEW bytes (that is, the number of bytes in the packet which were not previously handled).
I am not sure to we have to perform the part in BOLD. it says, to what i understand - check whether the newly arrived packet ENDS after the last treated data BEGINS.

I think I lack the understanding to why reassemblyList->end is not exactly like *expected...

thanks in advance,

SheldonC