[Libwebsockets] Libwebsocket Upgrade from 1.4

Brice Hamon normandviking at gmail.com
Tue Jul 5 19:48:49 CEST 2016


Thanks Andy,

I will report my progress.

The "Connection refused" is reported by the browser (Chrome), so as you
said, it could be something not transport related, but rather SSL as  I am
inclined to think.

Thanks
Brice.

On Tue, Jul 5, 2016 at 1:44 PM, Andy Green <andy at warmcat.com> wrote:

>
>
> On July 5, 2016 11:40:30 PM GMT+08:00, Brice Hamon <
> normandviking at gmail.com> wrote:
> >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?
>
> Yeah your biggest clue is "Connection Refused".
>
> Also you should sanity-check the lws test server itself works on your
> toolchain / platform.
>
> >I think if we find the problem in 1.7, 2.0 will work as well.
>
> I understand it looks like that to you, since you try 1.6 and it works and
> 1.7 acts different.  But it's not clear the problem is in the lib.  It's
> not even clear to me what the problem is.
>
> If it was happening to me I would grab hold of the Connection Refused end
> of it, eg look what netstat says and eyeball traffic with tcpdump.  The lib
> doesn't issue a tcp connection refused, as I explained it means something
> basic like the listen socket is not there.
>
> So the first move is confirm if that is literally a tcp connection
> refused, or you mean some handwaving 'communication failed' error that is
> actually something totally different and a red herring.
>
> Build it in debug mode
>
> cmake -DCMAKE_BUILD_TYPE=DEBUG
>
> and crank the logs up, equivalent to -d65535 on the test apps and look in
> there both at init and at connection attempt.  Compare the logs for test
> server in the same cases.
>
> -Andy
>
> >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
>
> This observation is still true if it's literally "Connection Refused".
>
> -Andy
>
> >>>>> 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/a5e4e323/attachment-0001.html>


More information about the Libwebsockets mailing list