On 18/10/2013 19:37, Mark Thomas wrote: > On 18/10/2013 13:54, Mark Thomas wrote: >> On 18/10/2013 12:48, Mark Thomas wrote: >>> When it goes wrong, the sequence is: >>> Read result [1] >>> Read result [48] >>> Read result [-20014] >>> 18-Oct-2013 12:23:25.298 SEVERE [http-apr-8443-exec-1] >>> websocket.drawboard.DrawboardEndpoint.onError onError: >>> java.io.IOException: Unexpected error [20,014] reading data from the >>> APR/native socket [364,180,784]. >> >> I've dug in to what could trigger the 20014 error code. I've got as far >> as ssl_socket_recv() in native\src\sslnetwork.c >> >> There appear to be a number of ways that the code could end up returning >> 20014. The next step is to figure out which it is. > > I've made some progress. I've captured a failure with Wireshark with an > SSL configuration that Wireshark can decrypt with the server's private > key (SSLProtocol="SSLv3", SSLCipherSuite="RC4-MD5") and it shows nothing > unusual until Tomcat initiates the close. > > To progress I need to create a new tcnative with some debug info so I > guess I'll have to return to trying to get my local build environment > set up correctly.
No joy getting a Windows build environment created but the error also occurs on Linux and I do have a working build environment there. The various errors reported in ssl_socket_recv() are: SSL_READ returns -1 SSL_get_error returns 5 (SSL_ERROR_SYSCALL) apr_get_netos_error returns 11 (APR_STATUS_IS_ENOTSOCK) At this point it looks like the issue is in the tcnative / APR / OpenSSL integration and I am way out of my depth. Looking at the source code for APR reads, the InternalAprInputBuffer uses Socket.recvbb() whereas AprServletInputStream current uses Socket.recv(). My short-term plan is to switch AprServletInputStream to Socket.recvbb() for SSL and see if that fixes the problem. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
