[Libwebsockets] v1.7.1

Andrejs Hanins andrejs.hanins at ubnt.com
Wed Feb 24 16:08:31 CET 2016



On 02/24/2016 01:22 PM, Andy Green wrote:
>
>
> On 02/24/2016 06:59 PM, Andrejs Hanins wrote:
>>
>>
>> On 02/24/2016 10:59 AM, Andrejs Hanins wrote:
>>>
>>> On 02/24/2016 10:04 AM, Andy Green wrote:
>>>>
>>>> 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
>>>>>>>
>>>>>>>       case LWS_CALLBACK_CLIENT_WRITEABLE:
>>>>>>> ...
>>>>>>>
>>>>>>>           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
>>>>
>>>> https://github.com/warmcat/libwebsockets/issues/437
>>>>
>>>> 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.
>>>>
>>>> https://github.com/warmcat/libwebsockets/commit/021d4fb90820789b4697a02de8abb3c113582ca5
>>> It still doesn't help, because state value is different from state_pre_close, in my case I get (added more debugs):
>>>
>>> LWS: not calling back closed mode=4 state_pre_close=0 state=4 (LWSS_DEAD_SOCKET)
>> It looks like to be a proper patch for the problem: https://github.com/warmcat/libwebsockets/pull/440
>
> Ugh... yes I fumbled the patch... no way to check it if can't reproduce.  Thanks for the fixed version, which is pushed on master + v1.7-stable replacing my one.
Hmm, now I'm thinking again. When lws_close_free_wsi is called with reason=LWS_CLOSE_STATUS_NOSTATUS_CONTEXT_DESTROY, early jump to
label just_kill_connection is made _before_ state value is copied into state_pre_close. So the check for wsi->state_pre_close == LWSS_HTTP is true just
because default value of state_pre_close is zero. It is not a non-upgraded connection as written in the commit comment.

Even more strange is that when I tried to move state_pre_close initialization to be done before jumping to just_kill_connection and removing those two
new lines which check for LWSS_HTTP, then lws library crashes in various places.

Andy, what do you think about it?
>
> -Andy
>
>>>
>>>
>>>> -Andy
>>>>
>>>>> 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