[Libwebsockets] Libwebsocket Upgrade from 1.4

Brice Hamon normandviking at gmail.com
Tue Jul 5 17:40:30 CEST 2016


Hi Andy,

I have not made progress on finding where the problem is.

One thing I was doing and seemed strange was in the SSL certs side:

if (http_ssl_)
    {
        if (!chain_file_.empty())
        {
            // cert file is not needed as it's included in the chain with
all intermediate cert.
            //info.ssl_cert_filepath = cert_file_.c_str();
            info.ssl_private_key_filepath = key_file_.c_str();
            info.ssl_cert_filepath = chain_file_.c_str();
        }
        else
        {
            // Simple key/cert WSS
            info.ssl_cert_filepath = cert_file_.c_str();
            info.ssl_private_key_filepath = key_file_.c_str();
        }
    }
    else
    {
        info.ssl_cert_filepath = NULL;
        info.ssl_private_key_filepath = NULL;
    }

    info.gid = -1;
    info.uid = -1;
    info.options = 0;
    info.ka_time = 10; // keep alive every 10
    info.ka_probes = 1; // how many times to try to get response before
giving up
    info.ka_interval = 2; // how long to wait before each ka_probes
    info.user = this; // to get ourself inthe static callback via the
context.

    context_ = libwebsocket_create_context(&info);


and this was the only way I made the lib work with 3 ssl files (key, cert
and chain).

I tried the "correct" way with

info.ssl_cert_filepath        = cert_file_.c_str();
info.ssl_private_key_filepath = key_file_.c_str();
info.ssl_ca_filepath          = chain_file_.c_str();

With no luck.

Any clues?

I think if we find the problem in 1.7, 2.0 will work as well.

Thank you in advance,
Brice.


On Mon, Jul 4, 2016 at 5:29 PM, Brice Hamon <normandviking at gmail.com> wrote:

> Ok 1.7.0 breaks the server. All version before are OK.
>
> The only change I can see impacting my code was the warning:
>
> bswebsocket.cpp:155:23: warning: `const lws_extension*
> lws_get_internal_extensions()' is deprecated (declared at
> /export/home/development/3rdparty/include/libwebsockets.h:1877)
> [-Wdeprecated-declarations]
>
> So I am investigating in that side.
>
> On Mon, Jul 4, 2016 at 4:25 PM, Brice Hamon <normandviking at gmail.com>
> wrote:
>
>> Hi Andy,
>>
>> I am working backwards in version. So far 2.0.2 to 1.7.2 does not work.
>> 1.5.1 does work. I will eventually where it breaks.
>>
>> I'll keep you posted.
>>
>> On Thu, Jun 30, 2016 at 1:13 PM, Brice Hamon <normandviking at gmail.com>
>> wrote:
>>
>>> Thanks Andy,
>>>
>>> I do not think it is a networking or environment issue as the same code
>>> running on the same host with 1.4 works and not 2.0.
>>>
>>> I just wanted to make sure I did not forgot an new call to init SSL or
>>> something like that not present in 1.4.
>>>
>>> I'll dig into it and report back.
>>>
>>> Thanks again
>>> Brice.
>>>
>>> On Wed, Jun 29, 2016 at 1:56 PM, Andy Green <andy at warmcat.com> wrote:
>>>
>>>>
>>>>
>>>> On June 29, 2016 11:52:31 PM GMT+08:00, Brice Hamon <
>>>> normandviking at gmail.com> wrote:
>>>> >Hi Andy,
>>>> >
>>>> >I just upgraded my server from 1.4 to 2.0.
>>>> >
>>>> >Not really a big task, just lws_ and a couple of adjustments,
>>>> >
>>>> >But now my server does not work anymore.  I use an external polling
>>>> >mechanism, and I see the first FD_ADD so the epoll is working.
>>>>
>>>> That doesn't follow actually, it means only that lws' code to expose
>>>> poll fds changes to the callback is working; it's caused by creating the
>>>> listen socket during init, not by servicing (e)poll events.  The log
>>>> doesn't show any evidence of servicing (e)poll events.
>>>>
>>>> >But when I try to connect with a browser or client program I get a CONN
>>>> >REFUSED and I don't see anything happening on the server side. I just
>>>> >see
>>>> >it listening on the correct port.
>>>>
>>>> Connection refused is really specific, it means for the peer there was
>>>> nobody listening at the port.  That can mean the listen socket bound to a
>>>> different interface than your client reached (check it with netstat -pltn
>>>> at the server, 0.0.0.0 means all interfaces) or a firewall got in the way,
>>>> or you reached the wrong ip (name resolution issue at client).
>>>>
>>>> >I compiled the lib plain vanilla with no options.
>>>> >
>>>> >Here is what I get as startup from your lib:
>>>> >
>>>> >
>>>> >16-06-29 11:38:24.694159 DEBUG: [WEBSOCKET ]: libwebsocket: Initial
>>>> >logging
>>>> >level 15
>>>> >16-06-29 11:38:24.694176 DEBUG: [WEBSOCKET ]: libwebsocket:
>>>> >Libwebsockets
>>>> >version: 2.0.0 xxxx at xxxx-v2.0.0-95-ge943a02
>>>> >16-06-29 11:38:24.694181 DEBUG: [WEBSOCKET ]: libwebsocket: IPV6 not
>>>> >compiled in
>>>> >16-06-29 11:38:24.694193 DEBUG: [WEBSOCKET ]: libwebsocket: libev
>>>> >support
>>>> >not compiled in
>>>> >16-06-29 11:38:24.694198 DEBUG: [WEBSOCKET ]: libwebsocket: libuv
>>>> >support
>>>> >not compiled in
>>>> >16-06-29 11:38:24.694356 DEBUG: [WEBSOCKET ]: libwebsocket:  Threads: 1
>>>> >each 1024 fds
>>>> >16-06-29 11:38:24.694453 DEBUG: [WEBSOCKET ]: libwebsocket:  mem:
>>>> >platform
>>>> >fd map:  8192 bytes
>>>> >16-06-29 11:38:24.694526 DEBUG: [WEBSOCKET ]: libwebsocket:  Compiled
>>>> >with
>>>> >OpenSSL support
>>>> >16-06-29 11:38:24.695057 DEBUG: [WEBSOCKET ]: libwebsocket: Creating
>>>> >Vhost
>>>> >'default' port 7682, 2 protocols, IPv6 off
>>>> >16-06-29 11:38:24.695102 DEBUG: [WEBSOCKET ]: libwebsocket:  Using SSL
>>>> >mode
>>>> >16-06-29 11:38:24.698961 DEBUG: [WEBSOCKET ]: libwebsocket:  SSL ECDH
>>>> >curve
>>>> >'prime256v1'
>>>> >16-06-29 11:38:24.699011 INFO : [WEBSOCKET ]: callback_http
>>>> >LWS_CALLBACK_OPENSSL_LOAD_EXTRA_SERVER_VERIFY_CERTS fd=0
>>>> >context=0x7efff0002800 user=[`uZ&] len=0
>>>> >16-06-29 11:38:24.699021 ERROR: [WEBSOCKET ]: callback_http: case
>>>> >LWS_CALLBACK_OPENSSL_LOAD_EXTRA_SERVER_VERIFY_CERTS not handled.
>>>> >16-06-29 11:38:24.700680 INFO : [WEBSOCKET ]: callback_http
>>>> >LWS_CALLBACK_LOCK_POLL fd=85 context=0x7efff0002800 user=[NULL] len=1
>>>> >16-06-29 11:38:24.700719 INFO : [WEBSOCKET ]: callback_http
>>>> >LWS_CALLBACK_ADD_POLL_FD fd=85 context=0x7efff0002800 user=[NULL] len=0
>>>> >16-06-29 11:38:24.700758 INFO : [WEBSOCKET ]: callback_http
>>>> >LWS_CALLBACK_UNLOCK_POLL fd=85 context=0x7efff0002800 user=[NULL] len=1
>>>> >16-06-29 11:38:24.700811 DEBUG: [WEBSOCKET ]: libwebsocket:  Listening
>>>> >on
>>>> >port 7682
>>>> >16-06-29 11:38:24.700834 DEBUG: [WEBSOCKET ]: libwebsocket:  mem:
>>>> >per-conn:
>>>> >         496 bytes + protocol rx buf
>>>> >16-06-29 11:38:24.700919 DEBUG: [WEBSOCKET ]: libwebsocket:
>>>> > canonical_hostname = xxxx
>>>> >
>>>> >Then a
>>>> >
>>>> >16-06-29 11:38:25.972014 DEBUG: [WEBSOCKET ]: libwebsocket:
>>>> >lws_protocol_init
>>>> >16-06-29 11:38:25.972043 INFO : [WEBSOCKET ]: callback_http
>>>> >LWS_CALLBACK_PROTOCOL_INIT fd=0 context=0x7efff0002800 user=[NULL]
>>>> >len=0
>>>> >16-06-29 11:38:25.972049 INFO : [WEBSOCKET ]: callback_http:
>>>> >LWS_CALLBACK_PROTOCOL_INIT
>>>> >
>>>> >And nothing else after that.
>>>>
>>>> Connection Refused is a tcp level thing, it means you did not succeed
>>>> to touch the listen socket.  So there would be no sign of activity from lws
>>>> about that.
>>>>
>>>> >I guess  my straight port from 1.4 to 2.0 was just been optimistic. I
>>>> >am
>>>> >forgetting something essential in order to have 2.0 working like in
>>>> >1.4.
>>>>
>>>> I think either lws bound to the wrong network interface for listen, or
>>>> the issue is outside lws.
>>>>
>>>> >Also the only question I had during the port is that I used the
>>>> >context->user pointer to store my own websocket object. I now need to
>>>> >to a
>>>> >// Getting the context from the wsi
>>>> >struct lws_context *wsicont = lws_get_context(wsi);
>>>> >
>>>> >// Getting the user cd from the context
>>>> >BSWebSocket *websocket = (BSWebSocket *)lws_context_user(wsicont);
>>>> >
>>>> >Is there a better way to do that? I already use the user pointer of the
>>>> >callback to get my per_session_data structure.
>>>>
>>>> No it looks good.  Both of those apis are really cheap, just resolve to
>>>> a struct member dereference each.
>>>>
>>>> -Andy
>>>>
>>>> >Thank you,
>>>> >
>>>> >Brice.
>>>> >
>>>> >
>>>> >On Thu, Jun 2, 2016 at 8:48 PM, Brice Hamon <normandviking at gmail.com>
>>>> >wrote:
>>>> >
>>>> >> Thank you Andy,
>>>> >>
>>>> >> I will get going and report my findings.
>>>> >>
>>>> >> Thanks again.
>>>> >> Brice.
>>>> >>
>>>> >>
>>>> >> On Thu, Jun 2, 2016 at 6:20 PM, Andy Green <andy at warmcat.com> wrote:
>>>> >>
>>>> >>>
>>>> >>>
>>>> >>> On June 3, 2016 1:08:32 AM GMT+08:00, Brice Hamon <
>>>> >>> normandviking at gmail.com> wrote:
>>>> >>> >Hi all,
>>>> >>> >
>>>> >>> >I have been using libwebsocket 1.4 with external epoll notification
>>>> >>> >loop
>>>> >>> >without a single problem for over a year now.
>>>> >>>
>>>> >>> Great.
>>>> >>>
>>>> >>> >All the libwebsocket functions are happening in one thread so I
>>>> >have
>>>> >>> >followed all guidelines in the README.coding
>>>> >>> >from that version.
>>>> >>> >
>>>> >>> >I think it is now time for me to upgrade as, following this group,
>>>> >many
>>>> >>> >fix
>>>> >>> >and enhancement took place.
>>>> >>> >
>>>> >>> >Is there specific areas of change I should be concerned with, or
>>>> >>> >important
>>>> >>> >changes in the notification area?
>>>> >>>
>>>> >>> Yes at 1.6 many api names got simplified and rationalized.  Mainly
>>>> >the
>>>> >>> api prefix got standardized to 'lws_'.  There are 4 steps listed in
>>>> >the
>>>> >>> changelog
>>>> >>>
>>>> >>>
>>>> >
>>>> https://github.com/warmcat/libwebsockets/blob/v2.0-stable/changelog#L643
>>>> >>>
>>>> >>> to search / replace everything in your code into shape.
>>>> >>>
>>>> >>> There are many other changes and improvements, such as multiple
>>>> >vhost
>>>> >>> support, CGI support, protocol plugins, lwsws etc.  It's hard to
>>>> >predict
>>>> >>> which are interesting, if you have external epoll() just to get
>>>> >epoll, the
>>>> >>> new built-in libuv support might be interesting... if so then lwsws
>>>> >and
>>>> >>> plugins might also simplify your life.
>>>> >>>
>>>> >>> If you need external event loop to interface to something else, then
>>>> >that
>>>> >>> should still work the same.
>>>> >>>
>>>> >>> >Thanks all and especially Andy, your lib rocks :)
>>>> >>>
>>>> >>> Thanks for the kind words ^^
>>>> >>>
>>>> >>> -Andy
>>>> >>>
>>>> >>> >Brice.
>>>> >>> >
>>>> >>> >
>>>> >>>
>>>>
>>>> >>------------------------------------------------------------------------
>>>> >>> >
>>>> >>> >_______________________________________________
>>>> >>> >Libwebsockets mailing list
>>>> >>> >Libwebsockets at ml.libwebsockets.org
>>>> >>> >http://libwebsockets.org/mailman/listinfo/libwebsockets
>>>> >>>
>>>> >>>
>>>> >>
>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://libwebsockets.org/pipermail/libwebsockets/attachments/20160705/1e121cb2/attachment-0001.html>


More information about the Libwebsockets mailing list