[Libwebsockets] v1.7.1

Andy Green andy at warmcat.com
Wed Feb 24 12:22:21 CET 2016



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.

-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