[Libwebsockets] v1.7.1

Andrejs Hanins andrejs.hanins at ubnt.com
Mon Feb 22 16:03:47 CET 2016

On 02/22/2016 04:44 PM, Andrejs Hanins wrote:
> Andy,
> On 02/22/2016 03:52 PM, Andrejs Hanins wrote:
>> On 02/22/2016 03:46 PM, Andy Green wrote:
>>> On February 22, 2016 9:32:31 PM GMT+08:00, Andrejs Hanins <andrejs.hanins at ubnt.com> wrote:
>>>> Hi,
>>>> Just as a heads up, not sure yet the reason, but with v1.7.1 I get
>>>> LWS_CALLBACK_CHANGE_MODE_POLL_FD with fd = -1. There is also no
>>>> LWS_CALLBACK_ADD_POLL_FD for that lws pointer. So it seems like
>>>> something is subtly broken.
>>> How could I reproduce that?  Test-server-extpoll doesn't give -1 fd (it's 'invalid fd') at the change callback when tested with chrome, for example.
>> It currently happens only in my complex application, I don't know how to reproduce it easily. I'm currently bisecting.
> Bisect found that 8c1f6026a7f95d0bbed342c2aabbc14b509602c3 is the first bad commit.
> Further debug shows that offending _lws_change_pollfd is called from lws_allocate_header_table (the second call).
> When entering into lws_allocate_header_table, the wsi->sock is already -1, wsi->position_in_fds_table is 0
> and wsi->state is 6 (LWSS_CLIENT_UNCONNECTED).
One more hint: lws_allocate_header_table is called right from the lws_client_connect_via_info, which doesn't yet have
sock created, but position_in_fds_table is zero-alloced to 0, which is supposed to be -1 if sock is not created, isn't it?
As a result, _lws_change_pollfd thinks that fd position is valid and uses sock value.

Andy, it should be easy to figure out for you the best way to fix it, I suppose.

BR, Andrey
> Any ideas what might be wrong here?
> BR, Andrey
>>> -Andy
>>>>    Everything is fine with v1.6.1
>>>> BR, Andrey
>>>> 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.
>>>>> 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