<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
  <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
  <META NAME="GENERATOR" CONTENT="GtkHTML/4.2.2">
</HEAD>
<BODY LINK="#0000ff">
El sáb, 21-11-2015 a las 01:17 +0000, Kale, Rahul escribió:
<BLOCKQUOTE TYPE=CITE>
     <BR>
    <BR>
    Hello,<BR>
</BLOCKQUOTE>
<BR>
Hi Kale,<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
    We are using the latest published version of noPoll. <BR>
</BLOCKQUOTE>
<BR>
Ok,<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
    Your suggestion of blocking nopoll_conn_wait_until_connection_ready would not fix the <BR>
    issue since the SSL_connect() returns error well before that (SSL_ERROR_SYSCALL).<BR>
</BLOCKQUOTE>
<BR>
Ok,<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
    As I mentioned in the original report,  I had put a small timeout as a workaround.<BR>
    <BR>
    However, when we started testing against a Websocket server a long distance away<BR>
    (California, US to Belgium) the problem resurfaced. <BR>
    <BR>
     <BR>
    <BR>
    Yesterday, I spent some time digging into the problem further. Turns out that <BR>
    if I increased the timeout to a large value (300 ms instead of 10 ms) the connection<BR>
    starts working. I rationalized that if the TCP connect completes (3 way handshake)<BR>
    <B>before</B> we hand the socket over to SSL/TLS for processing, the problem goes away.<BR>
    <BR>
     <BR>
    <BR>
    So now I implemented a new workaround. I wait for the TCP connection to complete<BR>
    before  telling SSL library the socket fd using SSL_set_fd().<BR>
    <BR>
     <BR>
    <BR>
    I modified nopoll_conn.c as follows:<BR>
    <BR>
     <BR>
    <BR>
    /* set socket */<BR>
    <BR>
    wait_for_socket_connect(conn->session); // workaround -- RPK<BR>
    <BR>
    SSL_set_fd (conn->ssl, conn->session);<BR>
    <BR>
     <BR>
    <BR>
    Where the wait_for_socket_connect is implemented as follows in nopoll_conn.c :<BR>
    <BR>
     <BR>
    <BR>
    staticint wait_for_socket_connect(int socketfd) <BR>
    <BR>
    {<BR>
    <BR>
        // On windows, when connect() is called on non-blocking call<BR>
    <BR>
        // connection succeeded if the socket is ready for writing<BR>
    <BR>
        fd_set write_fdset, except_fdset;<BR>
    <BR>
        struct timeval timeout;<BR>
    <BR>
     <BR>
    <BR>
        FD_ZERO(&write_fdset);<BR>
    <BR>
        FD_ZERO(&except_fdset);<BR>
    <BR>
        FD_SET((unsigned int) socketfd, &write_fdset );<BR>
    <BR>
        FD_SET((unsigned int) socketfd, &except_fdset );<BR>
    <BR>
     <BR>
    <BR>
        // Wait upto 2 seconds<BR>
    <BR>
        timeout.tv_sec =  0;<BR>
    <BR>
        timeout.tv_usec = 2000000;<BR>
    <BR>
     <BR>
    <BR>
        select( 0, NULL, &write_fdset, &except_fdset, &timeout);<BR>
    <BR>
     <BR>
    <BR>
        // connection failed<BR>
    <BR>
        if (FD_ISSET(socketfd, &except_fdset)) {<BR>
    <BR>
            return -1;<BR>
    <BR>
        }<BR>
    <BR>
        // successful connection<BR>
    <BR>
        else if (FD_ISSET(socketfd, &write_fdset)) {<BR>
    <BR>
            return 0;<BR>
    <BR>
        }<BR>
    <BR>
        return -1;<BR>
    <BR>
    }<BR>
</BLOCKQUOTE>
<BR>
And this solves the problem? Totally? ...or you are still experimenting errors? <BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
    It is very strange that this problem occurs only from the second connection using<BR>
    the library. You should be able to reproduce the problem using the test program<BR>
    I posted in the original report. <BR>
</BLOCKQUOTE>
<BR>
Ok, I'll look for a moment to review your test...<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
    I understand that the OpenSSL library is supposed to<BR>
    automatically take care of this and there should not be any need to wait<BR>
    for the base TCP connection to be established beforehand. But for some reason it does not.<BR>
</BLOCKQUOTE>
<BR>
Certainly it does. We have used OpenSSL for many years in many different projects<BR>
and connection scenarios and we didn't face something similar as you describe...<BR>
...but as usual, there's a first time for everything,<BR>
<BR>
It can also be a noPoll's bug that some how causes that SYSCALL error at the TLS/SSL<BR>
level...dunno,<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
    The above workaround is holding up for now but we would like to resolve this<BR>
    properly.<BR>
</BLOCKQUOTE>
<BR>
Ok. I'll look for a moment to review your test. <BR>
<BR>
Best Regards,<BR>
<BR>
<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
    Thanks,<BR>
    <BR>
     <BR>
    <BR>
    Rahul<BR>
    <BR>
     <BR>
    <BR>
    Rahul Kale<BR>
    <BR>
     <BR>
    <BR>
    IP Video Systems<BR>
    <BR>
    Barco, Inc<BR>
    <BR>
    1287 Anvilwood Ave<BR>
    <BR>
    Sunnyvale, CA  94089<BR>
    <BR>
     <BR>
    <BR>
    Tel  +1 408 400 4238<BR>
    <BR>
     <BR>
    <BR>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
    <B>From:</B> Kale, Rahul <BR>
    <B>Sent:</B> Thursday, November 19, 2015 3:14 PM<BR>
    <B>To:</B> nopoll@lists.aspl.es<BR>
    <B>Cc:</B> 'Francis Brosnan Blázquez'<BR>
    <B>Subject:</B> RE: [noPoll] Issue with using Secure Sockets client connecion (wss://) from Windows<BR>
    <BR>
    <BR>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
     <BR>
    <BR>
     <BR>
    <BR>
    Hello,<BR>
    <BR>
     <BR>
    <BR>
    Any resolution to the issue regarding this?<BR>
    <BR>
    In spite of the workaround mentioned below, we see this fail<BR>
    in certain cases.<BR>
    <BR>
     <BR>
    <BR>
    Thanks,<BR>
    <BR>
     <BR>
    <BR>
    Rahul<BR>
    <BR>
     <BR>
    <BR>
    Rahul Kale<BR>
    <BR>
     <BR>
    <BR>
    IP Video Systems<BR>
    <BR>
    Barco, Inc<BR>
    <BR>
    1287 Anvilwood Ave<BR>
    <BR>
    Sunnyvale, CA  94089<BR>
    <BR>
     <BR>
    <BR>
     <BR>
    <BR>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
    <B>From:</B><A HREF="mailto:nopoll-bounces@lists.aspl.es">nopoll-bounces@lists.aspl.es</A> [<A HREF="mailto:nopoll-bounces@lists.aspl.es">mailto:nopoll-bounces@lists.aspl.es</A>] <B>On Behalf Of </B>Kale, Rahul<BR>
    <B>Sent:</B> Tuesday, September 08, 2015 6:35 PM<BR>
    <B>To:</B> <A HREF="mailto:nopoll@lists.aspl.es">nopoll@lists.aspl.es</A><BR>
    <B>Subject:</B> [noPoll] Issue with using Secure Sockets client connecion (wss://) from Windows<BR>
    <BR>
    <BR>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
     <BR>
    <BR>
     <BR>
    <BR>
    Hello,<BR>
    <BR>
     <BR>
    <BR>
    I am facing an issue with using noPoll library for Secure Websockets (wss://)<BR>
    <BR>
    client connection on Windows platform. Basically, the first connection from<BR>
    <BR>
    the same binary works but subsequent connections do not work reliably.<BR>
    <BR>
    When I tried to debug the issue, by enabling logs, the problem goes away.<BR>
    <BR>
    Strangely, if I install my own log handler with an empty (do nothing)<BR>
    <BR>
    implementation, the problem also goes away.<BR>
    <BR>
    I have been trying to track down the problem the past week and finally have<BR>
    <BR>
    something to report.<BR>
    <BR>
     <BR>
    <BR>
    Firstly, I have isolated the code (see below) to the bare minimum below for you to reproduce the<BR>
    <BR>
    issue. The code makes 100 back to back connections in a loop and exits the loop<BR>
    <BR>
    early if it fails. This code rarely lasts for 2 or more loops. However if you <BR>
    <BR>
    enable logs (setting nopoll_log_set_handler to true) or install a log <BR>
    <BR>
    handler (using nopoll_log_set_handler), it will make 100 successful connections.<BR>
    <BR>
     <BR>
    <BR>
    Since logging did not help, I ended up compiling the noPoll source myself for further<BR>
    <BR>
    debugging. Since I am using VS 2008, I had to fix the code here and there to get it<BR>
    <BR>
    to compile and also had to add __declspec(dllexport) to most functions in the header file.<BR>
    <BR>
    By adding trial and error printfs I narrowed down the spot when it fails.<BR>
    <BR>
    Whenever the connect fails, the SSL_connect() function errors out with <BR>
    <BR>
    SSL_ERROR_SYSCALL at around line 756 in nopoll_conn.c.<BR>
    <BR>
     <BR>
    <BR>
    Assuming that there is some timing issue (since logging adds just enough delay), <BR>
    <BR>
    I have put a temporary fix as a workaround which fixes the issue: I added <BR>
    <BR>
    a nopoll_sleep() just before SSL_connect() like so:<BR>
    <BR>
     <BR>
    <BR>
        nopoll_sleep (10000);<BR>
    <BR>
        while (SSL_connect (conn->ssl) <= 0) {<BR>
    <BR>
        …<BR>
    <BR>
     <BR>
    <BR>
                                    <BR>
    <BR>
    I am sure you will find the root cause and have a better fix.<BR>
    <BR>
                                    <BR>
    <BR>
    Here is the sample code:<BR>
    <BR>
     <BR>
    <BR>
    #include "nopoll.h"<BR>
    <BR>
     <BR>
    <BR>
    static void noPollLogger(noPollCtx *ctx, noPollDebugLevel level, const char *log_msg, noPollPtr user_data) {<BR>
    <BR>
        // Do nothing here<BR>
    <BR>
    }<BR>
    <BR>
     <BR>
    <BR>
    int ConnectToWebsocket()<BR>
    <BR>
    {<BR>
    <BR>
     <BR>
    <BR>
        noPollCtx * context = nopoll_ctx_new();<BR>
    <BR>
     <BR>
    <BR>
        //nopoll_log_set_handler(context, noPollLogger, NULL);<BR>
    <BR>
        nopoll_log_enable(context, false);<BR>
    <BR>
     <BR>
    <BR>
        noPollConnOpts * opts = nopoll_conn_opts_new();<BR>
    <BR>
        nopoll_conn_opts_ssl_peer_verify(opts, false); // disable cert verification<BR>
    <BR>
        noPollConn * connection = nopoll_conn_tls_new(context, opts, "10.1.2.3", "443", NULL,<BR>
    <BR>
            "wss://10.1.2.3:443/wstunnel/?dst=127.0.0.1:6060", "tunnel-protocol", "some-origin");<BR>
    <BR>
     <BR>
    <BR>
        bool connected = true;<BR>
    <BR>
        int count = 0;<BR>
    <BR>
        while (!nopoll_conn_is_ready(connection)) {<BR>
    <BR>
            if (!nopoll_conn_is_ok(connection)) {<BR>
    <BR>
                connected = false;<BR>
    <BR>
                break;<BR>
    <BR>
            }<BR>
    <BR>
            nopoll_sleep(10000);<BR>
    <BR>
            fprintf(stdout, "Info: Waiting for connection...\n", count++);<BR>
    <BR>
        }<BR>
    <BR>
     <BR>
    <BR>
        if (connected) {<BR>
    <BR>
           fprintf(stdout, "Info: Connected!!\n");<BR>
    <BR>
        }<BR>
    <BR>
        else {<BR>
    <BR>
           fprintf(stdout, "Failed websocket connection\n");<BR>
    <BR>
           exit(1);<BR>
    <BR>
        }<BR>
    <BR>
     <BR>
    <BR>
        nopoll_conn_close(connection);<BR>
    <BR>
        nopoll_ctx_unref(context);<BR>
    <BR>
     <BR>
    <BR>
        return 0;<BR>
    <BR>
    }<BR>
    <BR>
     <BR>
    <BR>
    int main(int argc, char *argv[])<BR>
    <BR>
    {<BR>
    <BR>
        for (int i = 0; i < 100; i++) {<BR>
    <BR>
            ConnectToWebsocket();<BR>
    <BR>
            fprintf(stderr, "Done Loop %d\n", i);<BR>
    <BR>
        }<BR>
    <BR>
        return 0;<BR>
    <BR>
    }<BR>
    <BR>
     <BR>
    <BR>
    Thanks,<BR>
    <BR>
     <BR>
    <BR>
    Rahul<BR>
    <BR>
     <BR>
    <BR>
    Rahul Kale<BR>
    <BR>
     <BR>
    <BR>
    IP Video Systems<BR>
    <BR>
    Barco, Inc<BR>
    <BR>
    1287 Anvilwood Ave<BR>
    <BR>
    Sunnyvale, CA  94089<BR>
    <BR>
     <BR>
    <BR>
    Tel  +1 408 400 4238<BR>
    <BR>
     <BR>
    <BR>
    This message is subject to the following terms and conditions: <A HREF="http://www.barco.com/en/maildisclaimer">MAIL DISCLAIMER</A> <BR>
    <BR>
    <BR>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
    This message is subject to the following terms and conditions: <A HREF="http://www.barco.com/en/maildisclaimer">MAIL DISCLAIMER</A><BR>
</BLOCKQUOTE>
<BR>
<TABLE CELLSPACING="0" CELLPADDING="0" WIDTH="100%">
<TR>
<TD>
<PRE>
-- 
Francis Brosnan Blázquez  -  ASPL
<A HREF="http://www.asplhosting.com/">http://www.asplhosting.com/</A>
<A HREF="http://www.aspl.es/">http://www.aspl.es/</A>
<A HREF="https://twitter.com/aspl_es">https://twitter.com/aspl_es</A>
<A HREF="https://twitter.com/asplhosting">https://twitter.com/asplhosting</A>
<A HREF="https://twitter.com/francisbrosnanb">https://twitter.com/francisbrosnanb</A>

91 134 14 22 - 91 134 14 45 - 91 116 07 57

AVISO LEGAL
 
En virtud de lo dispuesto en la Ley Orgánica 15/1999, de 13 de
diciembre, de Protección de Datos de Carácter Personal, le informamos de
que sus datos de carácter personal, recogidos de fuentes accesibles al
público o datos que usted nos ha facilitado previamente, proceden de
bases de datos propiedad de Advanced Software Production Line, S.L.
(ASPL).
 
ASPL garantiza que los datos serán tratados con la finalidad de mantener
las oportunas relaciones comerciales o promocionales con usted o la
entidad que usted representa. No obstante, usted puede ejercitar sus
derechos de acceso, rectificación, cancelación y oposición dispuestos en
la mencionada Ley Orgánica, notificándolo por escrito a ASPL -
Protección Datos, C/Antonio Suárez 10 A-102, 28802, Alcalá de Henares
(Madrid).


</PRE>
</TD>
</TR>
</TABLE>
</BODY>
</HTML>