Hi coco21,

Make sure:

1. Your Makefile/build script defines the `WOLFSSL_USER_SETTINGS` macro (CFLAGS="-DWOLFSSL_USER_SETTINGS"). This will make sure the user_settings.h configuration is included and the same build configuration is used.

2. You include <wolfssl/wolfcrypt/settings.h> in your application code prior to any other wolfSSL headers.

Thanks,
David Garske, wolfSSL

Hi pm_vnct,

You are on the right track. If you register IO callbacks using `wolfSSL_CTX_SetIORecv` and `wolfSSL_CTX_SetIOSend`, then return `WOLFSSL_CBIO_ERR_WANT_READ` or `WOLFSSL_CBIO_ERR_WANT_WRITE` it will go up to the original caller wolfSSL_connect, wolfSSL_read or wolfSSL_write. This allows you to check for the return code, do other work and call again.

Here is an example for using the callbacks with want read/write:
https://github.com/wolfSSL/wolfssl-exam … callback.c

Here is an example for non-blocking:
https://github.com/wolfSSL/wolfssl-exam … ing.c#L136

Thanks,
David Garske, wolfSSL

Hi harish.reddy,

We have a good AES CBC example here, which can be adopted to GCM:
https://github.com/wolfSSL/wolfssl-exam … -encrypt.c

Our AES GCM wolfCrypt test is here:
https://github.com/wolfSSL/wolfssl/blob … st.c#L7225

Thanks,
David Garske, wolfSSL

Hi Kit,

The call to generate an ECC shared secret uses an encrypted channel with requires a paired encryption key. The default wolfSSL examples use `atmel_get_enc_key_default`, which is all 0xFF's. You should override this function with your own implementation and key. This can be done at build-time using `ATECC_GET_ENC_KEY`.

If you'd like to use a different slot for the ephemeral key generation you can override at build time with macro `ATECC_SLOT_ECDHE_PRIV` or at runtime by registering a slot allocator using `atmel_set_slot_allocator`.

You can test if its the encryption key by replacing the `atcab_ecdh_enc` with `atcab_ecdh` in `atmel_ecc_create_pms`.

Also the ATECC chips have a watchdog that will occur if the chip isn't put into idle state when done. You'll notice calls to `atcab_idle` in our wolfcrypt/port/atmel/atmel.c to resolve this.

Feel free to email us directly at support@wolfssl.com with your user_settings.h and logs. These emails get directed into our ZenDesk system and I'll make sure and grab the incoming ticket.

Thanks,
David Garske, wolfSSL

Hi faberge,

Thanks for your interest in wolfSSL! It sounds like you are 99% of the way there.

The call to read 5 bytes is to get the TLS header, which indicates the total size of the TLS packet. So the next read will be the remainder of the TLS packet. Perhaps you can share a bit more about the code used in your read and write callbacks? You can find our default IO callback functions here: https://github.com/wolfSSL/wolfssl/blob … io.c#L194.

Make sure you are properly handling a non-blocking case, which you would need to return `WOLFSSL_CBIO_ERR_WANT_READ`.

Another common pitfall (depending on your transport layer) is some stacks require getting the entire packet in which case you'd need to cache the remainder of the TLS packet for the read after the 5 byte header.

If you still need help debugging this please provide debug logs, wireshark trace and code snippets for review. If you'd like to keep those private you can email us directly at support@wolfssl.com and reference this forum link.

Thanks,
David Garske, wolfSSL

Hi Paul,

We will look into supporting this feature. I've started an email thread with another engineer. Your code may be valid, but wolfSSL doesn't yet support the serial number as part of the multi-attrib.

Thanks,
David Garske, wolfSSL

Hi ePaul,

We've pushed an example for using large data with PKCS 7 sign/verify here:
https://github.com/wolfSSL/wolfTPM/pull/32

Thanks,
David Garske, wolfSSL

Hi Paul,

The CSR should not contain a serial number. The serial number is assigned by the CA when it gets signed.

I will however take a look at your example and see if there is an issue that needs fixed around CSR gen with serial number provided.

Thanks,
David Garske, wolfSSL

Hi ePaul,

Thanks for the bug report. I was able to reproduce your issue and identiy the cause. I've pushed a wolfSSL fix for this issue here (https://github.com/wolfSSL/wolfssl/pull/1805). It was a new issue that happened after we added some additional fields to support BusinessUnit.

I'm located in PDT (UTC -7).

Thanks,
David Garske, wolfSSL

Hi ePaul,

To build you'll need to use:

Thanks,
David Garske, wolfSSL

Hi AdoraKalb,

That sounds like an issue with not providing enough stack space to the FreeRTOS thread on the xTaskCreate. Try increasing the stack size for that task and let us know if that helps.

Thanks,
David Garske, wolfSSL