Hi again,

Our project is about implementing wolfssl on a STM32F0-Nucleo and a MSP430. We want wolfSSL to use UART-communication instead of default socket communication. The basic idea is to let our hardware communicate through UART to a program on a PC that will redirect the communication to a server-program on the same PC.

We want to know in which way wolfssl sends and receives data. I think the following question will give you and idea of what we're wondering about:
Is there any way to let wolfssl know that the UART is receiving data or do wolfssl try to receive the data whenever it has time?
Which arguments in EmbedSend and EmbedReceive can be ignored and how are we suppose to use the remaining ones?
Both EmbedSend and EmbedReceive returns an integer value, how does wolfssl handle these internally? Is there anything important to know about the return value? Can wolfssl in any way use the file descriptor (or context descriptor) to do anything and if so what?
Finally, in which way do wolfssl expect to send data and recieve data (by default)?

wolfSSL's I/O callbacks are prototyped by the following:

int (*CallbackIORecv)(WOLFSSL *ssl, char *buf, int sz, void *ctx);
int (*CallbackIOSend)(WOLFSSL *ssl, char *buf, int sz, void *ctx);

Whenever wolfSSL needs additional data to advance its internal state machine, it will call the RECEIVE callback. The job of the RECEIVE callback is to place data into the provided buffer “buf”. wolfSSL asks for “sz” bytes of data, but if the callback has less data than requested, it can copy the number of bytes it has available into “buf” and return the number of bytes that have been written.

Whenever wolfSSL needs to send data in order to advance its internal state machine, it will call the SEND callback. The job of the SEND callback is to send the data in the buffer “buf” to the peer. The number of bytes in “buf” is given to the callback through the “sz” parameter. If the callback is only able to send part of the data in “buf”, it should return the number of bytes that were sent. wolfSSL will internally loop back around and call the callback again to get the rest of the data.

The third thing that comes into play with the I/O callbacks is the associated context (void *ctx). This can be a pointer to anything the user would like handed back to them during the I/O callbacks. Oftentimes this is a custom structure that would hold a pointer to data buffers, data sizes, socket handles, or in your case information necessary to send/receive data over your UART connection.

These I/O callback “contexts” can be set by the application using:

void wolfSSL_SetIOReadCtx( WOLFSSL* ssl, void *ctx);
void wolfSSL_SetIOWriteCtx(WOLFSSL* ssl, void *ctx);

From your last post, it sounds like in your case, your UART might buffer data when received, then in the wolfSSL Receive callback, you would simply copy data from the buffered area to wolfSSL’s internal buffer in the callback.

Does this make sense?  Is there anything that needs clarifying?

Best Regards,
Chris

Hi LimeD,

Great!  Glad that helped clear things up.

Best Regards,
Chris