<div dir="ltr"><div class="gmail_default" style="font-size:x-small">Thanks Andy,</div><div class="gmail_default" style="font-size:x-small"><br></div><div class="gmail_default" style="font-size:x-small">I will report my progress.</div><div class="gmail_default" style="font-size:x-small"><br></div><div class="gmail_default" style="font-size:x-small">The "Connection refused" is reported by the browser (Chrome), so as you said, it could be something not transport related, but rather SSL as  I am inclined to think.</div><div class="gmail_default" style="font-size:x-small"><br></div><div class="gmail_default" style="font-size:x-small">Thanks</div><div class="gmail_default" style="font-size:x-small">Brice.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jul 5, 2016 at 1:44 PM, Andy Green <span dir="ltr"><<a href="mailto:andy@warmcat.com" target="_blank">andy@warmcat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
<br>
On July 5, 2016 11:40:30 PM GMT+08:00, Brice Hamon <<a href="mailto:normandviking@gmail.com">normandviking@gmail.com</a>> wrote:<br>
>Hi Andy,<br>
><br>
</span><div><div class="h5">>I have not made progress on finding where the problem is.<br>
><br>
>One thing I was doing and seemed strange was in the SSL certs side:<br>
><br>
>if (http_ssl_)<br>
>    {<br>
>        if (!chain_file_.empty())<br>
>        {<br>
>          // cert file is not needed as it's included in the chain with<br>
>all intermediate cert.<br>
>            //info.ssl_cert_filepath = cert_file_.c_str();<br>
>            info.ssl_private_key_filepath = key_file_.c_str();<br>
>            info.ssl_cert_filepath = chain_file_.c_str();<br>
>        }<br>
>        else<br>
>        {<br>
>            // Simple key/cert WSS<br>
>            info.ssl_cert_filepath = cert_file_.c_str();<br>
>            info.ssl_private_key_filepath = key_file_.c_str();<br>
>        }<br>
>    }<br>
>    else<br>
>    {<br>
>        info.ssl_cert_filepath = NULL;<br>
>        info.ssl_private_key_filepath = NULL;<br>
>    }<br>
><br>
>    info.gid = -1;<br>
>    info.uid = -1;<br>
>    info.options = 0;<br>
>    info.ka_time = 10; // keep alive every 10<br>
>    info.ka_probes = 1; // how many times to try to get response before<br>
>giving up<br>
>    info.ka_interval = 2; // how long to wait before each ka_probes<br>
>    info.user = this; // to get ourself inthe static callback via the<br>
>context.<br>
><br>
>    context_ = libwebsocket_create_context(&info);<br>
><br>
><br>
>and this was the only way I made the lib work with 3 ssl files (key,<br>
>cert<br>
>and chain).<br>
><br>
>I tried the "correct" way with<br>
><br>
>info.ssl_cert_filepath        = cert_file_.c_str();<br>
>info.ssl_private_key_filepath = key_file_.c_str();<br>
>info.ssl_ca_filepath          = chain_file_.c_str();<br>
><br>
>With no luck.<br>
><br>
>Any clues?<br>
<br>
</div></div>Yeah your biggest clue is "Connection Refused".<br>
<br>
Also you should sanity-check the lws test server itself works on your toolchain / platform.<br>
<span class=""><br>
>I think if we find the problem in 1.7, 2.0 will work as well.<br>
<br>
</span>I understand it looks like that to you, since you try 1.6 and it works and 1.7 acts different.  But it's not clear the problem is in the lib.  It's not even clear to me what the problem is.<br>
<br>
If it was happening to me I would grab hold of the Connection Refused end of it, eg look what netstat says and eyeball traffic with tcpdump.  The lib doesn't issue a tcp connection refused, as I explained it means something basic like the listen socket is not there.<br>
<br>
So the first move is confirm if that is literally a tcp connection refused, or you mean some handwaving 'communication failed' error that is actually something totally different and a red herring.<br>
<br>
Build it in debug mode<br>
<br>
cmake -DCMAKE_BUILD_TYPE=DEBUG<br>
<br>
and crank the logs up, equivalent to -d65535 on the test apps and look in there both at init and at connection attempt.  Compare the logs for test server in the same cases.<br>
<br>
-Andy<br>
<div><div class="h5"><br>
>Thank you in advance,<br>
>Brice.<br>
><br>
><br>
>On Mon, Jul 4, 2016 at 5:29 PM, Brice Hamon <<a href="mailto:normandviking@gmail.com">normandviking@gmail.com</a>><br>
>wrote:<br>
><br>
>> Ok 1.7.0 breaks the server. All version before are OK.<br>
>><br>
>> The only change I can see impacting my code was the warning:<br>
>><br>
>> bswebsocket.cpp:155:23: warning: `const lws_extension*<br>
>> lws_get_internal_extensions()' is deprecated (declared at<br>
>> /export/home/development/3rdparty/include/libwebsockets.h:1877)<br>
>> [-Wdeprecated-declarations]<br>
>><br>
>> So I am investigating in that side.<br>
>><br>
>> On Mon, Jul 4, 2016 at 4:25 PM, Brice Hamon <<a href="mailto:normandviking@gmail.com">normandviking@gmail.com</a>><br>
>> wrote:<br>
>><br>
>>> Hi Andy,<br>
>>><br>
>>> I am working backwards in version. So far 2.0.2 to 1.7.2 does not<br>
>work.<br>
>>> 1.5.1 does work. I will eventually where it breaks.<br>
>>><br>
>>> I'll keep you posted.<br>
>>><br>
>>> On Thu, Jun 30, 2016 at 1:13 PM, Brice Hamon<br>
><<a href="mailto:normandviking@gmail.com">normandviking@gmail.com</a>><br>
>>> wrote:<br>
>>><br>
>>>> Thanks Andy,<br>
>>>><br>
>>>> I do not think it is a networking or environment issue as the same<br>
>code<br>
>>>> running on the same host with 1.4 works and not 2.0.<br>
>>>><br>
>>>> I just wanted to make sure I did not forgot an new call to init SSL<br>
>or<br>
>>>> something like that not present in 1.4.<br>
>>>><br>
>>>> I'll dig into it and report back.<br>
>>>><br>
>>>> Thanks again<br>
>>>> Brice.<br>
>>>><br>
>>>> On Wed, Jun 29, 2016 at 1:56 PM, Andy Green <<a href="mailto:andy@warmcat.com">andy@warmcat.com</a>><br>
>wrote:<br>
>>>><br>
>>>>><br>
>>>>><br>
>>>>> On June 29, 2016 11:52:31 PM GMT+08:00, Brice Hamon <<br>
>>>>> <a href="mailto:normandviking@gmail.com">normandviking@gmail.com</a>> wrote:<br>
>>>>> >Hi Andy,<br>
>>>>> ><br>
>>>>> >I just upgraded my server from 1.4 to 2.0.<br>
>>>>> ><br>
>>>>> >Not really a big task, just lws_ and a couple of adjustments,<br>
>>>>> ><br>
>>>>> >But now my server does not work anymore.  I use an external<br>
>polling<br>
>>>>> >mechanism, and I see the first FD_ADD so the epoll is working.<br>
>>>>><br>
>>>>> That doesn't follow actually, it means only that lws' code to<br>
>expose<br>
>>>>> poll fds changes to the callback is working; it's caused by<br>
>creating the<br>
>>>>> listen socket during init, not by servicing (e)poll events.  The<br>
>log<br>
>>>>> doesn't show any evidence of servicing (e)poll events.<br>
>>>>><br>
>>>>> >But when I try to connect with a browser or client program I get<br>
>a CONN<br>
>>>>> >REFUSED and I don't see anything happening on the server side. I<br>
>just<br>
>>>>> >see<br>
>>>>> >it listening on the correct port.<br>
>>>>><br>
>>>>> Connection refused is really specific, it means for the peer there<br>
>was<br>
>>>>> nobody listening at the port.  That can mean the listen socket<br>
>bound to a<br>
<br>
</div></div>This observation is still true if it's literally "Connection Refused".<br>
<span class="HOEnZb"><font color="#888888"><br>
-Andy<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
>>>>> different interface than your client reached (check it with<br>
>netstat -pltn<br>
>>>>> at the server, 0.0.0.0 means all interfaces) or a firewall got in<br>
>the way,<br>
>>>>> or you reached the wrong ip (name resolution issue at client).<br>
>>>>><br>
>>>>> >I compiled the lib plain vanilla with no options.<br>
>>>>> ><br>
>>>>> >Here is what I get as startup from your lib:<br>
>>>>> ><br>
>>>>> ><br>
>>>>> >16-06-29 11:38:24.694159 DEBUG: [WEBSOCKET ]: libwebsocket:<br>
>Initial<br>
>>>>> >logging<br>
>>>>> >level 15<br>
>>>>> >16-06-29 11:38:24.694176 DEBUG: [WEBSOCKET ]: libwebsocket:<br>
>>>>> >Libwebsockets<br>
>>>>> >version: 2.0.0 xxxx@xxxx-v2.0.0-95-ge943a02<br>
>>>>> >16-06-29 11:38:24.694181 DEBUG: [WEBSOCKET ]: libwebsocket: IPV6<br>
>not<br>
>>>>> >compiled in<br>
>>>>> >16-06-29 11:38:24.694193 DEBUG: [WEBSOCKET ]: libwebsocket: libev<br>
>>>>> >support<br>
>>>>> >not compiled in<br>
>>>>> >16-06-29 11:38:24.694198 DEBUG: [WEBSOCKET ]: libwebsocket: libuv<br>
>>>>> >support<br>
>>>>> >not compiled in<br>
>>>>> >16-06-29 11:38:24.694356 DEBUG: [WEBSOCKET ]: libwebsocket:<br>
>Threads: 1<br>
>>>>> >each 1024 fds<br>
>>>>> >16-06-29 11:38:24.694453 DEBUG: [WEBSOCKET ]: libwebsocket:  mem:<br>
>>>>> >platform<br>
>>>>> >fd map:  8192 bytes<br>
>>>>> >16-06-29 11:38:24.694526 DEBUG: [WEBSOCKET ]: libwebsocket:<br>
>Compiled<br>
>>>>> >with<br>
>>>>> >OpenSSL support<br>
>>>>> >16-06-29 11:38:24.695057 DEBUG: [WEBSOCKET ]: libwebsocket:<br>
>Creating<br>
>>>>> >Vhost<br>
>>>>> >'default' port 7682, 2 protocols, IPv6 off<br>
>>>>> >16-06-29 11:38:24.695102 DEBUG: [WEBSOCKET ]: libwebsocket:<br>
>Using SSL<br>
>>>>> >mode<br>
>>>>> >16-06-29 11:38:24.698961 DEBUG: [WEBSOCKET ]: libwebsocket:  SSL<br>
>ECDH<br>
>>>>> >curve<br>
>>>>> >'prime256v1'<br>
>>>>> >16-06-29 11:38:24.699011 INFO : [WEBSOCKET ]: callback_http<br>
>>>>> >LWS_CALLBACK_OPENSSL_LOAD_EXTRA_SERVER_VERIFY_CERTS fd=0<br>
>>>>> >context=0x7efff0002800 user=[`uZ&] len=0<br>
>>>>> >16-06-29 11:38:24.699021 ERROR: [WEBSOCKET ]: callback_http: case<br>
>>>>> >LWS_CALLBACK_OPENSSL_LOAD_EXTRA_SERVER_VERIFY_CERTS not handled.<br>
>>>>> >16-06-29 11:38:24.700680 INFO : [WEBSOCKET ]: callback_http<br>
>>>>> >LWS_CALLBACK_LOCK_POLL fd=85 context=0x7efff0002800 user=[NULL]<br>
>len=1<br>
>>>>> >16-06-29 11:38:24.700719 INFO : [WEBSOCKET ]: callback_http<br>
>>>>> >LWS_CALLBACK_ADD_POLL_FD fd=85 context=0x7efff0002800 user=[NULL]<br>
>len=0<br>
>>>>> >16-06-29 11:38:24.700758 INFO : [WEBSOCKET ]: callback_http<br>
>>>>> >LWS_CALLBACK_UNLOCK_POLL fd=85 context=0x7efff0002800 user=[NULL]<br>
>len=1<br>
>>>>> >16-06-29 11:38:24.700811 DEBUG: [WEBSOCKET ]: libwebsocket:<br>
>Listening<br>
>>>>> >on<br>
>>>>> >port 7682<br>
>>>>> >16-06-29 11:38:24.700834 DEBUG: [WEBSOCKET ]: libwebsocket:  mem:<br>
>>>>> >per-conn:<br>
>>>>> >         496 bytes + protocol rx buf<br>
>>>>> >16-06-29 11:38:24.700919 DEBUG: [WEBSOCKET ]: libwebsocket:<br>
>>>>> > canonical_hostname = xxxx<br>
>>>>> ><br>
>>>>> >Then a<br>
>>>>> ><br>
>>>>> >16-06-29 11:38:25.972014 DEBUG: [WEBSOCKET ]: libwebsocket:<br>
>>>>> >lws_protocol_init<br>
>>>>> >16-06-29 11:38:25.972043 INFO : [WEBSOCKET ]: callback_http<br>
>>>>> >LWS_CALLBACK_PROTOCOL_INIT fd=0 context=0x7efff0002800<br>
>user=[NULL]<br>
>>>>> >len=0<br>
>>>>> >16-06-29 11:38:25.972049 INFO : [WEBSOCKET ]: callback_http:<br>
>>>>> >LWS_CALLBACK_PROTOCOL_INIT<br>
>>>>> ><br>
>>>>> >And nothing else after that.<br>
>>>>><br>
>>>>> Connection Refused is a tcp level thing, it means you did not<br>
>succeed<br>
>>>>> to touch the listen socket.  So there would be no sign of activity<br>
>from lws<br>
>>>>> about that.<br>
>>>>><br>
>>>>> >I guess  my straight port from 1.4 to 2.0 was just been<br>
>optimistic. I<br>
>>>>> >am<br>
>>>>> >forgetting something essential in order to have 2.0 working like<br>
>in<br>
>>>>> >1.4.<br>
>>>>><br>
>>>>> I think either lws bound to the wrong network interface for<br>
>listen, or<br>
>>>>> the issue is outside lws.<br>
>>>>><br>
>>>>> >Also the only question I had during the port is that I used the<br>
>>>>> >context->user pointer to store my own websocket object. I now<br>
>need to<br>
>>>>> >to a<br>
>>>>> >// Getting the context from the wsi<br>
>>>>> >struct lws_context *wsicont = lws_get_context(wsi);<br>
>>>>> ><br>
>>>>> >// Getting the user cd from the context<br>
>>>>> >BSWebSocket *websocket = (BSWebSocket<br>
>*)lws_context_user(wsicont);<br>
>>>>> ><br>
>>>>> >Is there a better way to do that? I already use the user pointer<br>
>of the<br>
>>>>> >callback to get my per_session_data structure.<br>
>>>>><br>
>>>>> No it looks good.  Both of those apis are really cheap, just<br>
>resolve to<br>
>>>>> a struct member dereference each.<br>
>>>>><br>
>>>>> -Andy<br>
>>>>><br>
>>>>> >Thank you,<br>
>>>>> ><br>
>>>>> >Brice.<br>
>>>>> ><br>
>>>>> ><br>
>>>>> >On Thu, Jun 2, 2016 at 8:48 PM, Brice Hamon<br>
><<a href="mailto:normandviking@gmail.com">normandviking@gmail.com</a>><br>
>>>>> >wrote:<br>
>>>>> ><br>
>>>>> >> Thank you Andy,<br>
>>>>> >><br>
>>>>> >> I will get going and report my findings.<br>
>>>>> >><br>
>>>>> >> Thanks again.<br>
>>>>> >> Brice.<br>
>>>>> >><br>
>>>>> >><br>
>>>>> >> On Thu, Jun 2, 2016 at 6:20 PM, Andy Green <<a href="mailto:andy@warmcat.com">andy@warmcat.com</a>><br>
>wrote:<br>
>>>>> >><br>
>>>>> >>><br>
>>>>> >>><br>
>>>>> >>> On June 3, 2016 1:08:32 AM GMT+08:00, Brice Hamon <<br>
>>>>> >>> <a href="mailto:normandviking@gmail.com">normandviking@gmail.com</a>> wrote:<br>
>>>>> >>> >Hi all,<br>
>>>>> >>> ><br>
>>>>> >>> >I have been using libwebsocket 1.4 with external epoll<br>
>notification<br>
>>>>> >>> >loop<br>
>>>>> >>> >without a single problem for over a year now.<br>
>>>>> >>><br>
>>>>> >>> Great.<br>
>>>>> >>><br>
>>>>> >>> >All the libwebsocket functions are happening in one thread so<br>
>I<br>
>>>>> >have<br>
>>>>> >>> >followed all guidelines in the README.coding<br>
>>>>> >>> >from that version.<br>
>>>>> >>> ><br>
>>>>> >>> >I think it is now time for me to upgrade as, following this<br>
>group,<br>
>>>>> >many<br>
>>>>> >>> >fix<br>
>>>>> >>> >and enhancement took place.<br>
>>>>> >>> ><br>
>>>>> >>> >Is there specific areas of change I should be concerned with,<br>
>or<br>
>>>>> >>> >important<br>
>>>>> >>> >changes in the notification area?<br>
>>>>> >>><br>
>>>>> >>> Yes at 1.6 many api names got simplified and rationalized.<br>
>Mainly<br>
>>>>> >the<br>
>>>>> >>> api prefix got standardized to 'lws_'.  There are 4 steps<br>
>listed in<br>
>>>>> >the<br>
>>>>> >>> changelog<br>
>>>>> >>><br>
>>>>> >>><br>
>>>>> ><br>
>>>>><br>
><a href="https://github.com/warmcat/libwebsockets/blob/v2.0-stable/changelog#L643" rel="noreferrer" target="_blank">https://github.com/warmcat/libwebsockets/blob/v2.0-stable/changelog#L643</a><br>
>>>>> >>><br>
>>>>> >>> to search / replace everything in your code into shape.<br>
>>>>> >>><br>
>>>>> >>> There are many other changes and improvements, such as<br>
>multiple<br>
>>>>> >vhost<br>
>>>>> >>> support, CGI support, protocol plugins, lwsws etc.  It's hard<br>
>to<br>
>>>>> >predict<br>
>>>>> >>> which are interesting, if you have external epoll() just to<br>
>get<br>
>>>>> >epoll, the<br>
>>>>> >>> new built-in libuv support might be interesting... if so then<br>
>lwsws<br>
>>>>> >and<br>
>>>>> >>> plugins might also simplify your life.<br>
>>>>> >>><br>
>>>>> >>> If you need external event loop to interface to something<br>
>else, then<br>
>>>>> >that<br>
>>>>> >>> should still work the same.<br>
>>>>> >>><br>
>>>>> >>> >Thanks all and especially Andy, your lib rocks :)<br>
>>>>> >>><br>
>>>>> >>> Thanks for the kind words ^^<br>
>>>>> >>><br>
>>>>> >>> -Andy<br>
>>>>> >>><br>
>>>>> >>> >Brice.<br>
>>>>> >>> ><br>
>>>>> >>> ><br>
>>>>> >>><br>
>>>>><br>
>>>>><br>
>>>------------------------------------------------------------------------<br>
>>>>> >>> ><br>
>>>>> >>> >_______________________________________________<br>
>>>>> >>> >Libwebsockets mailing list<br>
>>>>> >>> ><a href="mailto:Libwebsockets@ml.libwebsockets.org">Libwebsockets@ml.libwebsockets.org</a><br>
>>>>> >>> ><a href="http://libwebsockets.org/mailman/listinfo/libwebsockets" rel="noreferrer" target="_blank">http://libwebsockets.org/mailman/listinfo/libwebsockets</a><br>
>>>>> >>><br>
>>>>> >>><br>
>>>>> >><br>
>>>>><br>
>>>>><br>
>>>><br>
>>><br>
>><br>
<br>
</div></div></blockquote></div><br></div>