deal with SSL_ERROR_WANT_ in client connect action
"4b0e01f Retry SSL_connect when SSL_get_error requests it. " from David Galeano
noticed the problem that client connect may receive SSL_ERROR_WANT_* from
SSL_connect, which is basically WOULDBLOCK. That patch tried to deal with it
by blocking in a while(1) until the condition went away.
That's problematic because of it blocks service of anything else (including
the host application sockets in the external socket poll sharing case) for
up to 5s controlled by conditions at one client.
After fiddling with and researching this, the actual problem with the code is
we are not getting the SSL layer error correctly, it is not contained in the
code returned from the Connect api directly.
I was unable to get a renegotiation forced on my modern SSL libs, it complained
about protocol error are reopened the connection instead. So I think the stuff
found in the docs and the web about the SSL_ERROR_WANT_ is probably not something
we will see in reality (if we check the right error code...)
Signed-off-by: Andy Green <andy.green@linaro.org>
diff --git a/lib/client-handshake.c b/lib/client-handshake.c
index 34c29c8..58e0ede 100644
--- a/lib/client-handshake.c
+++ b/lib/client-handshake.c
@@ -123,9 +123,15 @@
* provoke service to issue the handshake directly
* we need to do it this way because in the proxy case, this is the
* next state and executed only if and when we get a good proxy
- * response inside the state machine
+ * response inside the state machine... but notice in SSL case this
+ * may not have sent anything yet with 0 return, and won't until some
+ * many retries from main loop. To stop that becoming endless,
+ * cover with a timeout.
*/
+ libwebsocket_set_timeout(wsi,
+ PENDING_TIMEOUT_SENT_CLIENT_HANDSHAKE, AWAITING_TIMEOUT);
+
wsi->mode = LWS_CONNMODE_WS_CLIENT_ISSUE_HANDSHAKE;
pfd.fd = wsi->sock;
pfd.revents = POLLIN;