[Libwebsockets] v1.7.1

Andy Green andy at warmcat.com
Wed Feb 24 09:04:37 CET 2016

On 02/24/2016 04:01 PM, Andrejs Hanins wrote:
> Andy,
> On 02/23/2016 03:27 PM, Andrejs Hanins wrote:
>> On 02/23/2016 01:55 PM, Andy Green wrote:
>>> On 02/23/2016 07:48 PM, Andrejs Hanins wrote:
>>>> Hi,
>>>> On 02/20/2016 03:34 AM, Andy Green wrote:
>>>>> Hi -
>>>>> I have been tracking master with v1.7-stable branch except for
>>>>> patches that affect the API, it's early days but that has worked
>>>>> out well... it's the first time we had a stable branch contemporary
>>>>> with the release.  I guess that will slow down as the branches
>>>>> diverge.
>>>>> The point release is necessitated by a small but annoying bug with
>>>>> http/1.1 keepalive when lws is returning errors, the connection
>>>>> could not close but had to wait for a timeout from the peer.  This
>>>>> bug had been there for a while but was hidden by lws closing the
>>>>> connection needlessly.  Now it acts well for close this also needed
>>>>> fixing.
>>>> Having another problem with v1.7.1. To close WS connection I request
>>>> writable and return -1 from the writable callback, in previous
>>>> versions it caused CLOSED callback to be called, but not anymore with
>>>> v1.7.1. What I see from the logs is the following:
>>>> lws_calllback_as_writeable: 0x6fc600 (user=0x6f4600) lws_service_fd:
>>>> closing Close and handled lws_close_free_wsi: shutting down
>>>> connection: 0x6fc600
>>>> But my WS connection stays alive, the only callbacks I get is about
>>>> FD modification but not about WSI destroy or close. Note that
>>>> disconnect initiator side continues to send data through the
>>>> connection, but other side is stopped with kill -stop.
>>>> This again probably related to the the
>>>> 8c1f6026a7f95d0bbed342c2aabbc14b509602c3 (multithreaded stability)
>>>> commit which added shutdown(wsi->sock, SHUT_WR).
>>>> Any ideas how to get callbacks about closed WSI back?
>>> Does the test client work for you?  Because that's basically what he does
>>> ...
>>>          mirror_lifetime--;
>>>          if (!mirror_lifetime) {
>>>              lwsl_info("closing mirror session\n");
>>>              return -1;
>>>          }
>>>          /* get notified as soon as we can write again */
>>>          lws_callback_on_writable(wsi);
>>>          break;
>>> every second or so depending on your link speed to the server he uses up his lifetime and dies, the outer loop reconnects him with a new random lifetime.
>>> That seems to work fine here.... does that represent your situation?  Or something different to reproduce it?
>> Yes, test-client works fine. Actually I noticed that CLOSE callback indeed comes after PENDING_TIMEOUT_SHUTDOWN_FLUSH even in my code.
>> The problem is that after upgrade to v1.7.1 I've seen a situation, when CLOSE callback seems to be not coming at all and my code is stuck with dead WS connection, but I have no scenario for this yet.
>> I never seen anything similar before, so will continue testing.
>> Just as a reminder - my code uses external event loop.
> I have figured out that in my case CLOSE callback is not called when I do lws_context_destroy for a client context. The log is the following:
>   LWS: lws_context_destroy
>   LWS: lws_close_free_wsi: real just_kill_connection: 0xcda760
>   LWS: remove_wsi_socket_from_fds: wsi=0xcda760, sock=25, fds pos=1, end guy pos=2, endfd=0
>   LWS: not calling back closed mode=4 state=0   <<<< This looks suspicious, mode=4 is LWSCM_WS_CLIENT
>   LWS: lws_free_wsi: 0xcda760, remaining wsi 0
> So log clearly says "not calling the callback", but why? It was always working before.
> test-client seems to be working fine though. Obviously, in my code the sate of the WSI is a bit different.

There's a github issue following your situation really closely


both your recent issues he also found... last night I pushed a 
workaround for that same thing but didn't hear back from him yet.



> BR, Andrey
>> BR, Andrey
>>> -Andy
>>>> BR, Andrey
>>>>> Now we really properly support normal "official CA" certs now with
>>>>> top class ECDH cipher and SSLLABS grading (A+) on the test server.
>>>>> from v1.7.1:./changelog --->
>>>>> v1.7.1 ======
>>>>> NB: No API change since v1.7.0
>>>>> Fixes -----
>>>>> 1) MAJOR (Windows-only) fix assert firing
>>>>> 2) MAJOR http:/1.1 connections handled by  lws_return_http_status()
>>>>> did not get sent a content-length resulting in the link hanging
>>>>> until the peer closed it.  attack.sh updated to add a test for
>>>>> this.
>>>>> Changes -------
>>>>> 1) MINOR test-server gained some new switches
>>>>> -C <file>  use external SSL cert file -K <file>  use external SSL
>>>>> key file -A <file>  use external SSL CA cert file
>>>>> -u <uid>  set effective uid -g <gid>  set effective gid
>>>>> together you can use them like this to have the test-server work
>>>>> with the usual purchased SSL certs from an official CA.
>>>>> --ssl -C your.crt -K your.key -A your.cer -u 99 -g 99
>>>>> 2) MINOR the OpenSSL magic to setup ECDH cipher usage is
>>>>> implemented in the library, and the ciphers restricted to use ECDH
>>>>> only. Using this, the lws test server can score an A at SSLLABS
>>>>> test
>>>>> 3) MINOR STS (SSL always) header is added to the test server if you
>>>>> use --ssl.  With that, we score A+ at SSLLABS test
>>>>> 4) MINOR daemonize function (disabled at cmake by default) is
>>>>> updated to work with systemd
>>>>> 5) MINOR example systemd .service file now provided for test
>>>>> server (not installed by default)
>>>>> -Andy _______________________________________________ Libwebsockets
>>>>> mailing list Libwebsockets at ml.libwebsockets.org
>>>>> http://ml.libwebsockets.org/mailman/listinfo/libwebsockets
>>>> _______________________________________________ Libwebsockets mailing
>>>> list Libwebsockets at libwebsockets.org
>>>> http://libwebsockets.org/mailman/listinfo/libwebsockets

More information about the Libwebsockets mailing list