You are not logged in. Please login or register.
Please post questions or comments you have about wolfSSL products here. It is helpful to be as descriptive as possible when asking your questions.
ReferenceswolfSSL - Embedded SSL Library → wolfSSL → CYASSL_CALLBACKS, more info needed
There are few paragraphs about the handshake callback. I have been digging in the code and docs but not sure how to use this feature. I have a network stack that runs on a callback. I also can't do any blocking while waiting for network data. How should I integrate with wolfSSL? Please advise Todd! 
The handshake callback is intended for embedded SSL systems for debugging support. That is, when a good debugger isn't available and sniffing is impractical. It basically allows a trace of the handshake and won't be helpful for network i/o.
You'll want to use wolfSSL's user I/O callbacks found in cyassl_io.c. By default, wolfSSL uses EmbedReceive() to get data and EmbedSend() to send data. But you can write any I/O functions you want and then register them with CyaSSL_SetIORecv() and CyaSSL_SetIOSend(). You can also set a context for each SSL session with CyaSSL_SetIOReadCtx() and CyaSSL_SetIOWriteCtx(). The void* ctx could point to a structure that has information about where the next read or write buffer is, the size, and anything else you may need to track.
Try to follow the the error handling strategy of the default send/recv functions for maximum compatibility. That is, if wolfSSL calls your Recv function and no data is ready and you don't want to block, just return IO_ERR_WANT_READ. Then when you're notified by your network callback that I/O is ready just call the wolfSSL function again that didn't have data ready, like SSL_read() or SSL_connect() and it will pick up where it left off.
I understand your recommendation. SSL_connect() appears to only work with a blocking network model.
Loking in the source code at the SSL_connect(), I see all the case statements and a while loop to block for a response...but there are no "breaks;" to jump out of the switch statement and then out of the function.
Please enlighten me.
SSL_connect() works in blocking and non-blocking mode. The while loop is there because some steps require reading multiple blocks. If the underlying I/O is non-blocking and no I/O is ready then ProcessReply() will return the error WANT_READ which causes an immediate return from the function. You can test this by defining NON_BLOCKING for the examples.
ok, I see that too. But then SSL_connect() is returning a "SSL_FATAL_ERROR". I don't know if I consider a WANT_READ as a SSL_FATAL_ERROR. How do you recommend I distinguish from an error and a WANT_READ? Look at ssl->error upon return?
You can test this by defining NON_BLOCKING for the examples.
"NON_BLOCKING" is what I should define as a compiler flag? I don't see any of those in the code.
SSL_connect() will return success (done) or failure (fatal_error), that's just the way the API was designed. To see the actual error, call SSL_get_error(). In this case WANT_READ will be converted to SSL_ERROR_WANT_READ for OpenSSL compatibility. See man SSL_connect for more details (or look online if the SSL man pages aren't installed on your system).
NON_BLOCKING is a define used by the examples. wolfSSL proper doesn't "know" blocking or non-blocking, it's neutral by design.
aaaww, found it in examples. I screwed up on my grep skillz and thought it wasn't found.
wolfSSL - Embedded SSL Library → wolfSSL → CYASSL_CALLBACKS, more info needed
Powered by PunBB, supported by Informer Technologies, Inc.
Generated in 0.016 seconds (92% PHP - 8% DB) with 9 queries