• Registered: 2013-02-02
  • Posts: 2

Topic: adapting reader/writer thread design to wolfSSL

I have a standard TCP socket application running with lwip and FreeRTOS, and I would like to secure it with wolfssl embedded ssl.

The application is a CAN packet relay, so we don't know if the next io over the network will be a read or a write.  I currently implement this by having 1 thread dedicated to reading the socket and another thread for writing.

As I understand it, this will not work for wolfssl.  Protecting read/write with a mutex will also not work, because the reader thread will hold the mutex and block the writer until something is received.

So my question is, what is a good way to do random read/write with wolfssl?

Thanks,
Dan.

Share

  • From: Bozeman, MT
  • Registered: 2010-10-20
  • Posts: 650

Re: adapting reader/writer thread design to wolfSSL

Hi Dan,

It sounds like there are a couple of ways you could go about using wolfSSL embedded ssl in your application:

1.  If your application uses non-blocking sockets, you can just call wolfSSL_read() when data is available for reading and wolfSSL_write() when data is available to be written.  LwIP has a select() function which is designed for this purpose.  Using this method the calls shouldn't block each other since wolfSSL_read() and wolfSSL_write() would never block.

2.  You could use wolfSSL's default I/O callbacks with a mutex.  If your application didn't get the mutex until right before the wolfSSL_read() or wolfSSL_write() call, they wouldn't block each other.  If wolfSSL needed more data but it wasn't ready yet, wolfSSL_read() will return SSL_ERROR_WANT_READ while wolfSSL_write() would return SSL_ERROR_WANT_WRITE.

Best Regards,
Chris

https://www.wolfssl.com

chrisc's Website

Share

  • Registered: 2013-02-02
  • Posts: 2

Re: adapting reader/writer thread design to wolfSSL

Thank you for the response.

I was under the (probably incorrect) assumption that wolfSSL_read() may do both reads and writes on the underlying transport.  Same with wolfSSL_write().  If this is *not* the case and SSL_read only does reads and SSL_write only does writes, then things get a little easier.

Still wrapping my head around all the details.  One aspect I struggle with is breaking a select() call when a packet comes in on CAN hardware.  On linux I would use a pipe to patch into the select(), but that's not available in this environment.  My solution of last resort will be to use non-blocking sockets in a polling loop, but would prefer to do something more elegant and less busy.

Share

  • From: Bozeman, MT
  • Registered: 2010-10-20
  • Posts: 650

Re: adapting reader/writer thread design to wolfSSL

Dan,

Your understanding is correct in that if the SSL handshake has not been completed by wolfSSL_connect() or wolfSSL_accept(), the wolfSSL_read() and wolfSSL_write() calls will end up calling wolfSSL_negotiate(), which will try to complete the handshake - doing both reads and writes. 

If for example wolfSSL_read() ends up doing both writes and reads to finish the SSL handshake, they won't interfere with each other because they are in the same thread, right?

- Chris

https://www.wolfssl.com

chrisc's Website

Share