SheldonC,

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

Glad to hear you got it figured out.  One of the items on our task list is to update our embedded SSL library in OpenWrt to 2.0.

- Chris

Could you tell me what RSA key size you are using?  Also, is your CA file you are loading a single certificate, or a cert chain?

Thanks,
Chris

Hi,

Have you tried our most current version of CyaSSL (CyaSSL 2.0) to see if you still get the same error?  You can download it from here: http://yassl.com/yaSSL/Download.html.

Regards,
Chris

Hi Deepak,

We haven't implemented the above 3 functions because they're not needed in CyaSSL (but you can find placeholders for them in ssl.c).  For CyaSSL thread safety, please look at section VI of our "CyaSSL Additional Features" document (http://yassl.com/yaSSL/Docs_CyaSSL_Addi … tures.html).  Unlike OpenSSL, CyaSSL avoids using global data, static data, and the sharing of objects.

CyaSSL doesn't support the above functions.  RAND_add and setting tmp_dh are handled internally by CyaSSL.

CyaSSL provides SSLv23_client_method() and SSLv23_server_method() to use for this.

CyaSSL's OpenSSL compatibility layer is not fully complete.  Instead we provide a subset of the most commonly-used functions from OpenSSL to allow for ease of porting CyaSSL embedded SSL into existing OpenSSL projects (about 200 out of their 4000 functions).  Very often, even though CyaSSL doesn't have the exact function you might be looking for from OpenSSL, it should have similar functionality.

Our OpenSSL Compatibility layer is expanded as we encounter new porting efforts.  The comments you see about GoAhead are just indications those functions were brought to our attention during that port.

Regards,
Chris

Ok, thanks for letting us know.  We'll add that to our documentation.

- Chris

Thanks, we'll look into getting these cleared up.

- Chris

Hi,

Yes, you can use the CBIORecv/CBIOSend function pointers to point to your own custom I/O functions (you can use the EmbedSend() and EmbedReceive() functions as templates and guides).  You would then be able to hand off the data buffer to one of your other protocols from within your custom send function and bring it back to wolfSSL with your custom receive function.

Why do you want to use DTLS?

Regards,
Chris

topher,

Sounds like an interesting embedded SSL project.  What kind of server are you creating?  Currently, getSerialNumber() functionality isn't on our list, but if you have a need for it, we can work with you to add the functionality.

Regards,
Chris

Hi,

wolfSSL does all verification internally (signature, date, domain name).  The X509_get_serialNumber() function is part of wolfSSL's OpenSSL Compatibility layer, and is currently just a stub that always returns 0.

Why do you need the serial number?

Regards,
Chris

Sam,

Would you mind explaining a little more?

Thanks,
Chris

Hi,

Thanks for the bug submission, we've made the fix and checked it in. Bugs can either be submitted here in our forums or by opening a GitHub issue on our wolfSSL GitHub project page (https://github.com/wolfSSL/wolfssl).

What project are you working on?

Regards,
Chris