[Libwebsockets] v2.0 crashes

Andy Green andy at warmcat.com
Thu May 12 21:01:36 CEST 2016

On May 12, 2016 11:10:58 PM GMT+08:00, Andrejs Hanins <andrejs.hanins at ubnt.com> wrote:
>On 05/12/2016 05:36 PM, Andrejs Hanins wrote:
>> Andy,
>> On 05/12/2016 05:08 PM, Andy Green wrote:
>>> On 05/12/2016 06:50 PM, Andy Green wrote:
>>>> On 05/12/2016 06:01 PM, Andrejs Hanins wrote:
>>>>> Hi Andy,
>>>>> On 05/12/2016 12:05 PM, Andy Green wrote:
>>>>>> On 05/12/2016 04:38 PM, Andrejs Hanins wrote:
>>>>>>> Hi,
>>>>>>> Just updated to v2.0 and got crashes. The first one I figured
>>>>>>> out myself - it was necessary to add
>>>>>>> LWS_SERVER_OPTION_DO_SSL_GLOBAL_INIT option to ctx. Not sure
>>>>>>> whether it supposed to crash without this option...
>>>>>> People were complaining that lws always initialized SSL libs if
>>>>>> linked to them... it blows up valgrind due to some mysterious,
>>>>>> hopelessly inextricable incompatibility between at least OpenSSL
>>>>>> and valgrind.  So this option was added (in the examples too) so
>>>>>> that only if we explicitly want to use SSL does it get
>>>>>> initialized.
>>>>>> And it's item #2 in the changelog summary.
>>>>> Yeah, my bad. I was confused by a crash. So there is no any way to
>>>>> see if SSL was initialized outside of LWS and don't try to call
>>>>> SSL API if init wasn't done? Anyway, this is not very important,
>>>>> because user error here leads to a guaranteed crash thus will be
>>>>> fixed before code gets to the end-user :)
>>>> Examples of how to do it are in the test server and client.
>>>>>>> But the second one is more tricky - I get NULL context in
>>>>>>> lws_ssl_server_name_cb from SSL_CTX_get_ex_data. Any ideas? FYI
>>>>>>> I create two lws contexts inside the process - one for server
>>>>>>> one for client. Before v2.0 everything worked rock solid.
>>>>>> Yes: don't use two contexts.
>>>>>> Use one context, you can mix client and server connections in the
>>>>>> one context just fine.
>>>>>> Indeed you can have multiple (serving) vhosts and multiple client
>>>>>> connections just fine in one context.
>>>>> Ok, please correct my understanding: if I have one server ctx with
>>>>> non-zero port, then default vhost is created but the
>>>>> for that vhost is not created, thus when trying to create a client
>>>>> connection from this ctx leads to a crash (null ptr dereference).
>>>>> the proper solution is to crate a _client_ ctx first (with empty
>>>>> so that ssl_client_ctx is created), and then add a vhost using
>>>>> lws_create_vhost with a port to listen?
>>>> Basically the SSL init code still thinks it should init things to
>>>> either for server or client.
>>>> int lws_context_init_client_ssl(struct lws_context_creation_info
>>>>                      struct lws_vhost *vhost)
>>>> {
>>>> ...
>>>>      if (info->port != CONTEXT_PORT_NO_LISTEN)
>>>>          return 0;
>>>> However everything else already doesn't distinguish between the two
>>>> uses, before v2.0 http proxying is already working (which binds an
>>>> onward client connection to an accepted server client).  But that
>>>> only tested on http, not with SSL.
>>> Yes this was the case.  But considering the need for backwards
>compatibility (both client and server context init use the same
>ssl-related members) it's not completely straightforward.
>>> I pushed a patch on master that adds an api to init the client ssl
>context selectively on a vhost after the vhost is created.
>>> See the docs added to the api comment
>>> + * lws_init_vhost_client_ssl() - also enable client SSL on an
>existing vhost
>>> + *
>>> + * @info: client ssl related info
>>> + * @vhost: which vhost to initialize client ssl operations on
>>> + *
>>> + * You only need to call this if you plan on using SSL client
>connections on
>>> + * the vhost.  For non-SSL client connections, it's not necessary
>to call this.
>>> + *
>>> + * The following members of @info are used during the call
>>> + *
>>> + *     - @options must have LWS_SERVER_OPTION_DO_SSL_GLOBAL_INIT
>>> + *         otherwise the call does nothing
>>> + *     - @provided_client_ssl_ctx must be NULL to get a generated
>>> + *         ssl context, otherwise you can pass a prepared one in by
>setting it
>>> + *     - @ssl_cipher_list may be NULL or set to the client valid
>cipher list
>>> + *     - @ssl_ca_filepath may be NULL or client cert filepath
>>> + *     - @ssl_cert_filepath may be NULL or client cert filepath
>>> + *     - @ssl_private_key_filepath may be NULL or client cert
>private key
>>> + *
>>> + * You must create your vhost explicitly if you want to use this,
>so you have
>>> + * a pointer to the vhost.  Create the context first with the
>option flag
>lws_create_vhost() with
>>> + * the same info struct.
>>> There's also a corresponding flag added to lwsws to control this
>from JSON.
>>> Testing it was quite tricky... I added a protocol plugin
>"client-loopback-test", if you jump through the hoops to set it up, you
>can trigger it to make a client connection from a browser, at which
>point the browser connection closes.
>>> The client connection connects to the same server and the same
>protocol being served by the same plugin.  The server part sends some
>data to the client part and then they close.
>>> It works here with wss client connection to itself but I am guessing
>it's quicker to try it on your own code.
>> Thanks, will try now. Currently I do the following: create ctx with
>LWS_SERVER_OPTION_DO_SSL_GLOBAL_INIT, then create two vhosts - for
>client and for server.
>> It looks to be working fine (in/out connections are established and
>frames are running), but I get random crashes at certain conditions.
>> Let's see how it will behave with this patch.
>Well, still bad. With current master I can establish client connection
>only once. After it is disconnected I try to establish it again, but
>never get any callback back.
>I will investigate tomorrow in more details. Just to let you know - it
>was absolutely rock solid with 1.7.5, never had any single problem with

Well, v2.0 test client has no problems making multiple connections.

V2.0 is v1.7 with some patches.

There's nothing I can do about 'bad', 'crash', except wonder about the code I can't see.


>>> -Ady
>>>> At any rate, for sure the way forward is you should only use one
>>>> ( == one event loop) for all your activities.  If there are still
>>>> problems with that, I will fix them.
>>>> It seems the first step is adding a protocol plugin that opens a
>>>> connection back to his own server.
>>>> -Andy
>>>>>> -Andy
>>>>>>> My compile options are:
>>>>>>> BR, Andrey
>>>>>>> On 05/05/2016 05:20 AM, Andy Green wrote:
>>>>>>>> Hi -
>>>>>>>> Libwebsockets v2.0 is out.
>>>>>>>> The site is updated
>>>>>>>> https://libwebsockets.org/
>>>>>>>> as is the page about v2.0 new features
>>>>>>>> https://libwebsockets.org/lws-2.0-new-features.html
>>>>>>>> and the changelog
>>>> I replaced apache for my web services some weeks ago and have been
>>>> lwsws (the new generic webserver wrapper on lws) instead, you can
>>>> the new server status page here
>>>>>>>> https://libwebsockets.org/server-status/
>>>>>>>> This is an included lws protocol plugin, although you would
>>>>>>>> probably want to put it on a vhost mapped to localhost
>>>>>>>> interface only.
>>>>>>>> Basically the theme of the release is eliminate server
>>>>>>>> boilerplate code and use plugins for ws protocols.  With this
>>>>>>>> method, the test server is reduced to one short file with no
>>>>>>>> protocols or user callback.
>>>> If you use lwsws, the generic webserver wrapper which uses JSON
>>>> files, you can even eliminate the above code as well.
>>>> Protocol plugins can be be easily built against lws out-of-tree
>>>> and distributed in their own directories, lws scans in a given list
>>>> directories for them at startup (and for lwsws, that list is
>>>> from JSON config fragments in a conf.d/)
>>>>>>>> In addition to passing the usual Travis + Appveyor it's checked
>>>>>>>> on Coverity today and is zero defects.
>>>>>>>> https://scan.coverity.com/projects/warmcat-libwebsockets
>>>>>>>> Branch v2.0-stable is also set up for the usual ongoing fixes
>>>>>>>> while development continues on master.
>>>>>>>> Enjoy!
>>>>>>>> -Andy _______________________________________________
>>>>>>>> Libwebsockets mailing list Libwebsockets at ml.libwebsockets.org
>>>>>>>> http://libwebsockets.org/mailman/listinfo/libwebsockets
>>>>>>> _______________________________________________ Libwebsockets
>>>>>>> mailing list Libwebsockets at ml.libwebsockets.org
>>>>>>> http://libwebsockets.org/mailman/listinfo/libwebsockets
>>>> _______________________________________________
>>>> Libwebsockets mailing list
>>>> Libwebsockets at ml.libwebsockets.org
>>>> http://libwebsockets.org/mailman/listinfo/libwebsockets

More information about the Libwebsockets mailing list