• Registered: 2016-01-27
  • Posts: 9

Topic: Issues with non-blocking sockets with ssl_connect and ssl_accept

I'm trying to add wolfSSL to an existing application that uses non-blocking sockets.  Essentially I just want to wedge SSL and DTLS communications under the current application protocol.  I've been using the client and server examples (on Windows) as "known good" for the opposing side of my testing (using client.exe for testing my "server side" and server.exe for testing my "client side").  For both my client and server sides (server side is much more inconsistent), the wolfSSL library doesn't complete the negotiation required using ssl_connect or ssl_accept.
Comparing it to the example code (which I realize is intentionally simplified), I don't having a "blocking" while loop around the ssl_connect and ssl_accept calls.  They are called as part of a state machine within my application.  If I step through the ssl_connect call in the debugger, it will usually complete the negotiation, making it seem that the issue is that the ssl_connect/accept state machines can't handle "incomplete data" during certain states.
I've turned on DEBUG_WOLFSSL and can provide logs and Wireshark traces, although I would prefer to "sanitize" the Wireshark traces if they need to be posted.

Share

  • From: Bozeman
  • Registered: 2014-05-09
  • Posts: 777

Re: Issues with non-blocking sockets with ssl_connect and ssl_accept

Hi Michael,

From previous experience with similar issues IE "fails but not when run in the debugger" my first thought is that the state machine is not handling the threads properly. Could you configure wolfSSL with SINGLE_THREADED defined and see if that resolves the issue?

If it does you may need to implement some form of mutual exclusion / locking mechanism in the state machine if using wolfSSL in a multi-threaded fashion.

I look forward to your results.


Regards,

- Kaleb

Kaleb J. Himes's Website

Share

  • Registered: 2016-01-27
  • Posts: 9

Re: Issues with non-blocking sockets with ssl_connect and ssl_accept

I missed the SINGLE_THREADED build option, so I will certainly try that.  You are right in that the application is attempting to run "single threaded" by polling sockets (in a single thread) rather than blocking on them (creating the need for multiple threads).
The application (for "regular" sockets) uses the usually send/recv/sendto/recvfrom WITHOUT a select() call.  I noticed in your examples that when calling ssl_accept/ssl_connect it is prefixed with a select() call.  Does ssl_accept/ssl_connect REQUIRE data to be present (thus requiring the select call)?

Share

  • Registered: 2016-01-27
  • Posts: 9

Re: Issues with non-blocking sockets with ssl_connect and ssl_accept

The SINGLE_THREADED build option didn't seem to have much of an effect.  I still get either a WANT_READ (from a "would block" error) or SOCKET_ERROR_E error that ends up aborting the state machine.

Share

5 Reply by Kaleb J. Himes (edited by Kaleb J. Himes 2016-01-29 13:51:45)

  • From: Bozeman
  • Registered: 2014-05-09
  • Posts: 777

Re: Issues with non-blocking sockets with ssl_connect and ssl_accept

Hi Michael,

Since that did not help the run-time functionality of your state machine, it would be helpful for us to go over the logs you mentioned previously. Additionally a glance at the wireshark trace is often helpful but I understand if you have sensitive information wanting to sanitize those first.
If you only wish to sanitize for cleanliness you can send us the whole capture and identify the relevant IP address(s) so we can filter out only the stream in question. I leave this to your discretion.

Best Regards,

- Kaleb

Kaleb J. Himes's Website

Share

  • Registered: 2016-01-27
  • Posts: 9

Re: Issues with non-blocking sockets with ssl_connect and ssl_accept

I've already filtered out the stream in question, otherwise I wouldn't be able to see it (my network seems to have a bunch of unnecessary traffic).  It's the MAC/IP address I want to make anonymous.
I've started to dive into the code, and it definitely appears to be a problem with SERVER_HELLO_DONE case in wolfSSL_accept.  ProcessReply() returns WANT_READ, but the "error handling" won't accept any negative values.  I'm playing with it trying to be "accepting" of WANT_READ (first allow the while loop to be infinite if WANT_READ continues, maybe move on to returning and reentering with subsequent calls to ssl_accept).  I suspect there may be a few other cases where this happens (on both ssl_accept and ssl_connect)
If I get stuck or lose confidence, I'll definitely post logs (and Wireshark traces) here.  If I completely solve the problem, I'll post a patch to GitHub for review.
The toolkit has been fairly easy to work with, I'm just not that familiar with SSL to know the code I'm looking at.

Share

  • From: Bozeman
  • Registered: 2014-05-09
  • Posts: 777

Re: Issues with non-blocking sockets with ssl_connect and ssl_accept

Hi Michael,

Sounds like a good plan. We look forward to hearing your progress. For a more private channel (posting logs and traces) feel free to open a ticket by sending an email to support@wolfssl.com or via zendesk directly.

Best Regards,

- Kaleb

Kaleb J. Himes's Website

Share

  • Registered: 2016-01-27
  • Posts: 9

Re: Issues with non-blocking sockets with ssl_connect and ssl_accept

I think this issue can be closed.  It took me awhile to realize my mistake that I was setting my "regular" socket to non-blocking, but not the "SSL" socket.
Still need to work out some other issues, but I think that was the problem here.

Share