Hi Robert,

I've pushed fixes for this issue to a PR here:
https://github.com/wolfSSL/wolfssl/pull/3874

The `devCtx` is meant for symmetric algorithms. Do you have a need for it with asymmetric ones like ECC or RSA?

Thanks,
David Garske, wolfSSL

Hi Robert,

Thanks for the excellent feedback. I did the crypto callback implementation and the devCtx was added a bit later and possibly not consistent across all algorithms (as you have seen). I will work on a fix for and post a link. Also there is some work in progress to fix the HMAC devId's.

In the future feel free to send us a direct email to support@wolfssl.com, which goes into our ZenDesk system.

Thanks,
David Garske, wolfSSL

Hi Tom,

It looks like the build error is in the example code `IDE/XilinxSDK/wolfssl_example.c`. For now you can wrap those in `#ifndef NO_ASN_TIME` to get past that error. I haven't used that Zynq target (mainly the UltraScale+). I think you would have the best success if you create a new project using the Vitis wizard and then add the wolfSSL project.

Here are the important steps after you create a blank project:
1) Exclude all the wolfSSL directories except "src/*.c", "wolfcrypt/src/*.c" and "IDE/XilinxSDK/*.c".
2) Add include paths to the wolfssl-root/wolfssl directory and the IDE/XilinxSDK directory.
3) Add the pre-processor macro WOLFSSL_USER_SETTINGS

Let me know what errors you see after following these steps.

Thanks,
David Garske, wolfSSL

Hi tiagomts,

That is a very uncommon use case. Usually they would be different ports. You could inspect the first 5 bytes to see if its a TLS header and if it was not then treat as clear text. You would need to use custom IO callbacks and add logic to handle the packets without TLS headers. For the non-secure data packets you would need to add your own custom header to know the size. Have you considered using a TLS NULL cipher (HAVE_NULL_CIPHER), which does not encrypt data, but does do the authentication and integrity?

Here is an example using custom IO callbacks:
https://github.com/wolfSSL/wolfssl-exam … callback.c

Thanks,
David Garske, wolfSSL

Hi sapi01,

The best epoll examples we have are in wolfssl-examples/tls.
https://github.com/wolfSSL/wolfssl-exam … oll-perf.c

Thanks,
David Garske, wolfSSL

Hi hp28190,

I have also seen that error with STM32F7 with the GCM auth tag calculation using the crypto hardware. There have been several fixes some post v4.6.0, so you might consider trying latest master.

Example of PR fix:
https://github.com/wolfSSL/wolfssl/pull/3649

Some other things you can consider trying are:
1. Add the define `STM32_HAL_V2`.
2. Make sure you are using the latest STM32 Cube HAL for the F7.
3. For performance speedups with the latest STM32 Cube you can consider trying STM32_AESGCM_PARTIAL.

Thanks,
David Garske, wolfSSL

Hi sEdwards,

Look in wolfcrypt/src/port/arm and you will see addition algorithm specific .c files you will need to include for Aarch64.

Thanks,
David Garske, wolfSSL

Hi hp28190,

How do you have the memory setup? I see you have `WOLFSSL_NO_MALLOC` defined, which is odd. It looks like your define for FREERTOS is mapping XMALLOC/XFREE to the pvPortMalloc/vPortFree functions. You need to increase your heap space, which is configured in the FreeRTOSConfig.h. Depending on which FreeRTOS heap implementation you have.

A good template for build options is here:
https://github.com/wolfSSL/wolfssl/blob … settings.h

If you use ./configure from the Linux world it will generate a file wolfssl/options.h, which shows the build options. See ./configure --help for list of enable/disable options.

Thanks,
David Garske, wolfSSL

Hi hp28190,

Looks like the client is connecting with TLS v1.2 only based on the wireshark. Also only using the signature algo X25519 (ED/Curve25519). Have you tried omitting the `WOLFSSL_TLS13_MIDDLEBOX_COMPAT` option? Perhaps try adding `HAVE_ED25519`.

Thanks,
David Garske, wolfSSL

Hi daniel571,

Yes. We support settings a read/write IO callback and context.

See this useful blog post. https://www.wolfssl.com/wolfssl-custom-io-setup-2/

Let me know if you have any further issues or questions.

Thanks,
David Garske, wolfSSL

Hi windyMk92,

You might also want to use these API's to set your own IO callback context pointer. This will allow you to specify a different socket/IO context for each thread.

wolfSSL_SetIOReadCtx
wolfSSL_SetIOWriteCtx

Thanks,
David Garske, wolfSSL

Hi Andreas,

Can you please try updating to the latest wolfSSL GitHub master? There are fixes in since v4.5.0 in aes.c for these STM32 functions.

The latest STM32 Cube MX HAL version I can find is v1.8. I ran our TLS cipher suite test on the H753ZI board with AES crypto hardware acceleration enabled and could not reproduce an issue.

Here is the example I am using:
https://drive.google.com/file/d/1-RIGxq … sp=sharing

Thanks,
David Garske, wolfSSL