An additional question on this topic if I may:-

Currently, our implementation does not specifically call wolfSSL_free() when an SSL/TLS connection ends.  Instead, the memory used by the WOLFSSL structure and its subordinate structures is automatically reclaimed by an entirely separate mechanism when tracking of the TCP flow is purged.

As far as I can see this is OK, and there would not be unforeseen consequences by allowing large numbers of SSL connections to come and go without calling wolfSSL_free().

Is my assessment correct?
A.

Thanks Kaleb.

I couldn't quite see how ctx->heap could be continually modified, so I've created an 'installer' script that unpacks the wolfSSL ZIP, inserts a trivial API call into ssl.c and ssl.h:-

void __setCTXHeap(WOLFSSL_CTX* ctx, void *heap)

enables XMALLOC_USER, configures and builds.

All now seems to be working.

Regards,
A.

Hi All,

We have created a custom implementation of XMALLOC() that uses the 'type' argument to divert some requests into conventional glibc malloc(), and others into our internal mechanism.

Our internal mechanism wants to return an address that's an offset relative to 'void *heap' passed to XMALLOC().

In short, we want to use 'void *heap' for our own purposes, and set this prior to every call to wolfSSL_new().

Is this possible?
A.

4

(2 replies, posted in wolfSSL)

I had since sussed that out from the makefile, but thanks anyway.
A.

5

(2 replies, posted in wolfSSL)

Dear All,

I've created a user_settings.h file that defines XMALLOC_USER, and I run:-

./configure CFLAGS="-DWOLFSSL_USER_SETTINGS"

I was expecting the library to build such that it would want to call XMALLOC() etc which I would define in my application.

Unfortunately the 'make' phase aborts, because the examples and test suite obviously don't have this function.

If I run 'make src/libwolfssl.la' to build JUST the library, what's the correct procedure for then copying library and includes to the correct /usr/local locations?

Regards,
A.