<div dir="ltr"><div class="gmail_default" style="font-size:x-small">Hi Andy,</div><div class="gmail_default" style="font-size:x-small"><br></div><div class="gmail_default" style="font-size:x-small">Yes only one is running. I check with netstat. I recompiled lws with <span style="font-size:12.8px">-DLWS_MAX_SMP=1.</span></div><div class="gmail_default" style="font-size:x-small"><span style="font-size:12.8px"><br></span></div><div class="gmail_default" style="font-size:x-small">No change, the problem is still there.</div><div class="gmail_default" style="font-size:x-small"><br></div><div class="gmail_default" style="font-size:x-small">I believe that the problem is in the server's side as the lws test client and the browser failed to establish a WS connection. At least I now know it is not SSL related.</div><div class="gmail_default" style="font-size:x-small"><br></div><div class="gmail_default" style="font-size:x-small">I will now investigate the server side and report back.</div><div class="gmail_default" style="font-size:x-small"><br></div><div class="gmail_default" style="font-size:x-small">If you think at something obvious in the way 1.7 server side works versus 1.6, please let me know. </div><div class="gmail_default" style="font-size:x-small"><br></div><div class="gmail_default" style="font-size:x-small">Thanks</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jul 5, 2016 at 11:50 PM, Andy Green <span dir="ltr"><<a href="mailto:andy@warmcat.com" target="_blank">andy@warmcat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Tue, 2016-07-05 at 23:08 -0400, Brice Hamon wrote:<br>
> Yes I did not wait for 20 seconds to timeout the first time. <br>
><br>
> I attached the tcp dump for that port taken from the client machine.<br>
<br>
</span>Clearly the client thinks he sends the upgrade<br>
<br>
22:56:37.579369 IP bs1.blueskysystem.net.46119 ><br>
bs2.blueskysystem.net.7682: Flags [P.], seq 1:293, ack 1, win 229,<br>
options [nop,nop,TS val 1553449881 ecr 1553345730], length 292<br>
        0x0000:  4500 0158 e634 4000 4006 ce87 c0a8<br>
01c9  E..X.4@.@.......<br>
        0x0010:  c0a8 01ca b427 1e02 428c 25ab 7144<br>
4265  .....'..B.%.qDBe<br>
        0x0020:  8018 00e5 b057 0000 0101 080a 5c97<br>
c399  .....W......\...<br>
        0x0030:  5c96 2cc2 4745 5420 2f20 4854 5450<br>
2f31  \.,.GET./.HTTP/1<br>
        0x0040:  2e31 0d0a 5072 6167 6d61 3a20 6e6f<br>
2d63  .1..Pragma:.no-c<br>
        0x0050:  6163 6865 0d0a 4361 6368 652d 436f 6e74  ache..Cache-<br>
Cont<br>
        0x0060:  726f 6c3a 206e 6f2d 6361 6368 650d 0a48  rol:.no-<br>
cache..H<br>
        0x0070:  6f73 743a 2031 3932 2e31 3638 2e31<br>
2e32  ost:.192.168.1.2<br>
        0x0080:  3032 0d0a 5570 6772 6164 653a 2077<br>
6562  02..Upgrade:.web<br>
        0x0090:  736f 636b 6574 0d0a 436f 6e6e 6563<br>
7469  socket..Connecti<br>
        0x00a0:  6f6e 3a20 5570 6772 6164 650d 0a53<br>
6563  on:.Upgrade..Sec<br>
        0x00b0:  2d57 6562 536f 636b 6574 2d4b 6579 3a20  -WebSocket-<br>
Key:.<br>
        0x00c0:  2f4a 5748 7668 3976 5052 336e 5675<br>
5267  /JWHvh9vPR3nVuRg<br>
        0x00d0:  2f62 5554 5a77 3d3d 0d0a 4f72 6967<br>
696e  /bUTZw==..Origin<br>
        0x00e0:  3a20 6874 7470 3a2f 2f31 3932 2e31 3638  :.<a href="http://192" rel="noreferrer" target="_blank">http://192</a>.<br>
168<br>
        0x00f0:  2e31 2e32 3032 0d0a 5365 632d 5765 6253  .1.202..Sec-<br>
WebS<br>
        0x0100:  6f63 6b65 742d 5072 6f74 6f63 6f6c 3a20  ocket-<br>
Protocol:.<br>
        0x0110:  6273 7773 2d70 726f 746f 636f 6c0d 0a53  bsws-<br>
protocol..S<br>
        0x0120:  6563 2d57 6562 536f 636b 6574 2d45 7874  ec-WebSocket-<br>
Ext<br>
        0x0130:  656e 7369 6f6e 733a 200d 0a53 6563<br>
2d57  ensions:...Sec-W<br>
        0x0140:  6562 536f 636b 6574 2d56 6572 7369 6f6e  ebSocket-<br>
Version<br>
        0x0150:  3a20 3133 0d0a 0d0a                      :.13....<br>
<div><div class="h5"><br>
<br>
> Yes this server is a lws server.<br>
><br>
> I don't get much on the server side:<br>
><br>
><br>
> 16-07-05 23:05:00.519960 DEBUG: [WEBSOCKET ]: libwebsocket: Initial<br>
> logging level 65535<br>
><br>
> 16-07-05 23:05:00.519981 DEBUG: [WEBSOCKET ]: libwebsocket:<br>
> Libwebsockets version: 1.7.0 ac4b079<br>
><br>
> 16-07-05 23:05:00.519988 DEBUG: [WEBSOCKET ]: libwebsocket: IPV6 not<br>
> compiled in<br>
><br>
> 16-07-05 23:05:00.520012 DEBUG: [WEBSOCKET ]: libwebsocket: libev<br>
> support not compiled in<br>
><br>
> 16-07-05 23:05:00.520021 DEBUG: [WEBSOCKET ]: libwebsocket:<br>
>  LWS_DEF_HEADER_LEN    : 1024<br>
><br>
> 16-07-05 23:05:00.520027 DEBUG: [WEBSOCKET ]: libwebsocket:<br>
>  LWS_MAX_PROTOCOLS     : 5<br>
><br>
> 16-07-05 23:05:00.520041 DEBUG: [WEBSOCKET ]: libwebsocket:<br>
>  LWS_MAX_SMP           : 32<br>
><br>
> 16-07-05 23:05:00.520049 DEBUG: [WEBSOCKET ]: libwebsocket:<br>
>  SPEC_LATEST_SUPPORTED : 13<br>
><br>
> 16-07-05 23:05:00.520055 DEBUG: [WEBSOCKET ]: libwebsocket:  sizeof<br>
> (*info)        : 216<br>
><br>
> 16-07-05 23:05:00.520061 DEBUG: [WEBSOCKET ]: libwebsocket:<br>
>  SYSTEM_RANDOM_FILEPATH: '/dev/urandom'<br>
><br>
> 16-07-05 23:05:00.520166 DEBUG: [WEBSOCKET ]: libwebsocket:  default<br>
> timeout (secs): 20<br>
><br>
> 16-07-05 23:05:00.520213 DEBUG: [WEBSOCKET ]: libwebsocket:  Threads:<br>
> 1 each 1024 fds<br>
><br>
> 16-07-05 23:05:00.520223 DEBUG: [WEBSOCKET ]: libwebsocket:  mem:<br>
> context:          9800 bytes (5704 ctx + (1 thr x 4096))<br>
><br>
> 16-07-05 23:05:00.520251 DEBUG: [WEBSOCKET ]: libwebsocket:  mem:<br>
> http hdr rsvd:    4232 bytes (1 thr x (1024 + 3208) x 1))<br>
><br>
> 16-07-05 23:05:00.520276 DEBUG: [WEBSOCKET ]: libwebsocket:  mem:<br>
> pollfd map:       8192<br>
><br>
> 16-07-05 23:05:00.520310 DEBUG: [WEBSOCKET ]: libwebsocket:  mem:<br>
> platform fd map:  8192 bytes<br>
><br>
> 16-07-05 23:05:00.520406 DEBUG: [WEBSOCKET ]: libwebsocket:<br>
>  LWS_MAX_EXTENSIONS_ACTIVE: 2<br>
><br>
> 16-07-05 23:05:00.520418 DEBUG: [WEBSOCKET ]: libwebsocket:  mem:<br>
> per-conn:          376 bytes + protocol rx buf<br>
><br>
> 16-07-05 23:05:00.520501 DEBUG: [WEBSOCKET ]: libwebsocket:  Compiled<br>
> with OpenSSL support<br>
><br>
> 16-07-05 23:05:00.520509 DEBUG: [WEBSOCKET ]: libwebsocket:  Using<br>
> non-SSL mode<br>
><br>
> 16-07-05 23:05:00.529082 DEBUG: [WEBSOCKET ]: libwebsocket:<br>
>  interface lo vs eth0<br>
><br>
> 16-07-05 23:05:00.529128 DEBUG: [WEBSOCKET ]: libwebsocket:<br>
>  interface eth0 vs eth0<br>
><br>
> 16-07-05 23:05:00.529136 DEBUG: [WEBSOCKET ]: libwebsocket:<br>
>  interface eth1 vs eth0<br>
><br>
> 16-07-05 23:05:00.529147 DEBUG: [WEBSOCKET ]: libwebsocket:<br>
>  interface lo vs eth0<br>
><br>
> 16-07-05 23:05:00.529153 DEBUG: [WEBSOCKET ]: libwebsocket:<br>
>  interface eth0 vs eth0<br>
><br>
> 16-07-05 23:05:00.529247 DEBUG: [WEBSOCKET ]: libwebsocket:<br>
> insert_wsi_socket_into_fds: 0x7fad98026450: tsi=0, sock=71, pos-in-<br>
> fds=1<br>
><br>
> 16-07-05 23:05:00.529278 INFO : [WEBSOCKET ]: callback_http<br>
> LWS_CALLBACK_LOCK_POLL fd=71 context=0x7fad98003e80 user=[NULL] len=1<br>
> 16-07-05 23:05:00.529302 INFO : [WEBSOCKET ]: callback_http<br>
> LWS_CALLBACK_ADD_POLL_FD fd=71 context=0x7fad98003e80 user=[NULL]<br>
> len=0<br>
> 16-07-05 23:05:00.529376 INFO : [WEBSOCKET ]: callback_http<br>
> LWS_CALLBACK_UNLOCK_POLL fd=71 context=0x7fad98003e80 user=[NULL]<br>
> len=1<br>
> 16-07-05 23:05:00.529453 DEBUG: [WEBSOCKET ]: libwebsocket:<br>
>  Listening on port 7682<br>
><br>
> 16-07-05 23:05:00.529470 INFO : [WEBSOCKET ]: callback_http<br>
> LWS_CALLBACK_PROTOCOL_INIT fd=0 context=0x7fad98003e80 user=[NULL]<br>
> len=0<br>
> 16-07-05 23:05:00.529475 INFO : [WEBSOCKET ]: callback_http:<br>
> LWS_CALLBACK_PROTOCOL_INIT<br>
> 16-07-05 23:05:00.529520 INFO : [WEBSOCKET ]: callback_bsws<br>
> LWS_CALLBACK_PROTOCOL_INIT wsi=0x7fada6ffcbb0 context=0x7fad98003e80<br>
> pss=(nil)<br>
> 16-07-05 23:05:00.529617 INFO : [WEBSOCKET ]: BSThread::onRunning<br>
> called<br>
> 16-07-05 23:05:00.719556 INFO : [BSWEBHTTP ]: Start(): THREAD<br>
> WebSocket started.<br>
<br>
</div></div>He doesn't seem to feel he received any connect on his listening<br>
socket.<br>
<br>
If it possible you have another lws server running on 7682?<br>
<br>
1.7 introduced using SO_REUSEPORT for listening sockets when you have<br>
LWS_MAX_SMP > 1, each thread opens his own listening socket and the<br>
load is shared between them by the OS without conflict.<br>
<br>
A side effect of that is even if another process has a listening socket<br>
on 7682, creating the new listening socket will succeed.<br>
<br>
I wonder if you have another instance still running somewhere listening<br>
on 7682 that gets the accept.<br>
<br>
I notice LWS_MAX_SMP is 32 for you, how about setting that to 1 (cmake<br>
.. -DLWS_MAX_SMP=1 ) if you are not using multiple service threads.<br>
 That will disable SO_REUSEPORT.<br>
<span class="HOEnZb"><font color="#888888"><br>
-Andy<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
><br>
> and when I exit:<br>
><br>
><br>
> 16-07-05 23:05:17.379324 INFO : [BSWEBHTTP ]: BSEventMgr::run Leaving<br>
> mainloop. Thread exiting<br>
> 16-07-05 23:05:17.379780 INFO : [BSWEBHTTP ]: Stopping the WebSocket<br>
> Thread...<br>
> 16-07-05 23:05:17.380160 INFO : [WEBSOCKET ]: BSEventMgr::run Leaving<br>
> mainloop. Thread exiting<br>
> 16-07-05 23:05:17.380302 DEBUG: [WEBSOCKET ]: libwebsocket:<br>
> lws_context_destroy<br>
><br>
> 16-07-05 23:05:17.380315 DEBUG: [WEBSOCKET ]: libwebsocket:<br>
> lws_close_free_wsi: real just_kill_connection: 0x7fad98026450<br>
><br>
> 16-07-05 23:05:17.380333 INFO : [WEBSOCKET ]: callback_http<br>
> LWS_CALLBACK_LOCK_POLL fd=71 context=0x7fad98003e80 user=[NULL] len=1<br>
> 16-07-05 23:05:17.380346 DEBUG: [WEBSOCKET ]: libwebsocket:<br>
> remove_wsi_socket_from_fds: wsi=0x7fad98026450, sock=71, fds pos=1,<br>
> end guy pos=2, endfd=0<br>
><br>
> 16-07-05 23:05:17.380361 INFO : [WEBSOCKET ]: callback_http<br>
> LWS_CALLBACK_DEL_POLL_FD fd=71 context=0x7fad98003e80 user=[NULL]<br>
> len=0<br>
> 16-07-05 23:05:17.380389 INFO : [WEBSOCKET ]: callback_http<br>
> LWS_CALLBACK_UNLOCK_POLL fd=71 context=0x7fad98003e80 user=[NULL]<br>
> len=1<br>
> 16-07-05 23:05:17.380398 DEBUG: [WEBSOCKET ]: libwebsocket: not<br>
> calling back closed mode=16 state=0<br>
><br>
> 16-07-05 23:05:17.380553 INFO : [WEBSOCKET ]: callback_http<br>
> LWS_CALLBACK_WSI_DESTROY fd=-1 context=0x7fad98003e80 user=[NULL]<br>
> len=0<br>
> 16-07-05 23:05:17.380573 DEBUG: [WEBSOCKET ]: libwebsocket:<br>
> lws_free_wsi: 0x7fad98026450, remaining wsi 0<br>
><br>
> 16-07-05 23:05:17.380602 INFO : [WEBSOCKET ]: callback_http<br>
> LWS_CALLBACK_PROTOCOL_DESTROY fd=0 context=0x7fad98003e80 user=[NULL]<br>
> len=0<br>
> 16-07-05 23:05:17.380612 INFO : [WEBSOCKET ]: callback_bsws<br>
> LWS_CALLBACK_PROTOCOL_DESTROY wsi=0x7fada6ffccc0<br>
> context=0x7fad98003e80 pss=(nil)<br>
> 16-07-05 23:05:17.381734 DEBUG: [WEBSOCKET ]: BSThread:: [WEBSOCKET]<br>
> Mainloop done. Bye.<br>
> 16-07-05 23:05:17.382136 INFO : [BSWEBHTTP ]: WebSocket Thread<br>
> stopped.<br>
><br>
> Thanks,<br>
> Brice.<br>
><br>
><br>
><br>
><br>
><br>
><br>
> On Tue, Jul 5, 2016 at 5:56 PM, Andy Green <<a href="mailto:andy@warmcat.com">andy@warmcat.com</a>> wrote:<br>
> ><br>
> > On July 6, 2016 5:44:26 AM GMT+08:00, Brice Hamon <normandviking@gm<br>
> > <a href="http://ail.com" rel="noreferrer" target="_blank">ail.com</a>> wrote:<br>
> > >HI Andy,<br>
> > ><br>
> > >I had to change the test client to add my own protocol name in the<br>
> > >request<br>
> > >as my server only speaks that protocol.<br>
> > ><br>
> > >That client also used to work with prior version.<br>
> > ><br>
> > >Also I could disable the SSL support on both ends and the problem<br>
> > still<br>
> > >persisted. So I concluded that this is not a SSL problem.<br>
> > ><br>
> > ><br>
> > >Yes Andy, the connection request eventually timeout like this:<br>
> > ><br>
> > ><br>
> > >aiting for connect...<br>
> > >[1467754420:5046] CLIENT: lws_client_connect_2<br>
> > >[1467754420:5047] CLIENT: lws_client_connect_2: address<br>
> > 192.168.1.202<br>
> > >[1467754420:5047] CLIENT: connected<br>
> > >callback_bsws [LWS_CALLBACK_LOCK_POLL] fd=6 user=[NULL] len=0<br>
> > >callback_bsws [LWS_CALLBACK_CHANGE_MODE_POLL_FD] fd=6 user=[NULL]<br>
> > len=0<br>
> > >callback_bsws [LWS_CALLBACK_UNLOCK_POLL] fd=6 user=[NULL] len=0<br>
> > >callback_bsws [LWS_CALLBACK_CLIENT_APPEND_HANDSHAKE_HEADER] fd=6<br>
> > >user=[NULL] len=3794<br>
> ><br>
> > Hmm this is also different than what you said before, it's creating<br>
> > the upgrade request without the peer closing, which is more<br>
> > reasonable.<br>
> ><br>
> > Check with tcpdump -s0 -X what happens on the wire.<br>
> ><br>
> > What is this server?  Also lws?  Get some logs on that as well if<br>
> > tcpdump shows it sent the upgrade.<br>
> ><br>
> > -Andy<br>
> > ><br>
> > ><br>
> > ><br>
> > >[1467754441:5268] NOTICE: wsi 0xbea580: TIMEDOUT WAITING on 4 (did<br>
> > hdr<br>
> > >0,<br>
> > >ah 0xbba730, wl 0, pfd events 0)<br>
> > >[1467754441:5268] ERR: *** not on ah wait list ***<br>
> > >[1467754441:5268] INFO: lws_close_free_wsi: real<br>
> > just_kill_connection:<br>
> > >0xbea580<br>
> > >callback_bsws [LWS_CALLBACK_LOCK_POLL] fd=6 user=[NULL] len=1<br>
> > >[1467754441:5269] INFO: remove_wsi_socket_from_fds: wsi=0xbea580,<br>
> > >sock=6,<br>
> > >fds pos=1, end guy pos=2, endfd=0<br>
> > >callback_bsws [LWS_CALLBACK_DEL_POLL_FD] fd=6 user=[NULL] len=0<br>
> > >callback_bsws [LWS_CALLBACK_UNLOCK_POLL] fd=6 user=[NULL] len=1<br>
> > >[1467754441:5269] DEBUG: Connection closed before server reply<br>
> > >callback_bsws [LWS_CALLBACK_CLIENT_CONNECTION_ERROR] fd=6<br>
> > user=[NULL]<br>
> > >len=0<br>
> > >callback_bsws [LWS_CALLBACK_WSI_DESTROY] fd=-1 user=[NULL] len=0<br>
> > >[1467754441:5270] INFO: lws_header_table_detach: wsi 0xbea580: ah<br>
> > >0xbba730<br>
> > >(tsi=0, count = 1)<br>
> > >[1467754441:5270] ERR: header assign - free time 21<br>
> > ><br>
> > ><br>
> > >It seems like after the<br>
> > LWS_CALLBACK_CLIENT_APPEND_HANDSHAKE_HEADER,<br>
> > >nothing happens.<br>
> > ><br>
> > ><br>
> > ><br>
> > >On Tue, Jul 5, 2016 at 5:26 PM, Andy Green <<a href="mailto:andy@warmcat.com">andy@warmcat.com</a>><br>
> > wrote:<br>
> > ><br>
> > >><br>
> > >><br>
> > >> On July 6, 2016 4:28:03 AM GMT+08:00, Brice Hamon<br>
> > ><<a href="mailto:normandviking@gmail.com">normandviking@gmail.com</a>><br>
> > >> wrote:<br>
> > >> >Thanks Roger,<br>
> > >> ><br>
> > >> >I'll look into it if I am unable to find the root cause<br>
> > otherwise.<br>
> > >><br>
> > >> Git bisect is a good idea and the lws history is almost always<br>
> > >buildable<br>
> > >> at any commit.  I thought it might be quicker to pull on the<br>
> > symptom<br>
> > >end<br>
> > >> but maybe not.<br>
> > >><br>
> > >> >A little bit of progress.<br>
> > >> ><br>
> > >> >1) The test server and client do work on my platform. So the<br>
> > problem<br>
> > >is<br>
> > >> >in<br>
> > >> >my code somewhere.<br>
> > >><br>
> > >> Too early to say, since we don't know what the problem is.  But<br>
> > it<br>
> > >means<br>
> > >> your toolchain + platform + lws version can basically work if it<br>
> > does<br>
> > >what<br>
> > >> the test apps do.<br>
> > >><br>
> > >> >2) I changed the client's test program and now I can see that<br>
> > the<br>
> > >><br>
> > >> What does it mean "changed the client's test program"?<br>
> > >><br>
> > >> >client<br>
> > >> >get connected to the server, but nothing after that.<br>
> > >> >That rules out a network transport problem.<br>
> > >><br>
> > >> It just means "'connection refused" was bogus.<br>
> > >><br>
> > >> >libwebsockets test client<br>
> > >><br>
> > >> >SSL Usage: Yes<br>
> > >> >[1467750112:5381] NOTICE: Initial logging level 65535<br>
> > >> >[1467750112:5382] NOTICE: Libwebsockets version: 1.7.0 ac4b079<br>
> > >> >[1467750112:5382] NOTICE: IPV6 not compiled in<br>
> > >> >[1467750112:5383] NOTICE: libev support not compiled in<br>
> > >> >[1467750112:5383] INFO:  LWS_DEF_HEADER_LEN    : 1024<br>
> > >> >[1467750112:5383] INFO:  LWS_MAX_PROTOCOLS     : 5<br>
> > >> >[1467750112:5384] INFO:  LWS_MAX_SMP           : 32<br>
> > >><br>
> > >> This defaults to 1 on later lws anyway, but it's likely<br>
> > unrelated if<br>
> > >the<br>
> > >> test apps are ok.<br>
> > >><br>
> > >> >[1467750112:5384] INFO:  SPEC_LATEST_SUPPORTED : 13<br>
> > >> >[1467750112:5384] INFO:  sizeof (*info)        : 216<br>
> > >> >[1467750112:5385] INFO:  SYSTEM_RANDOM_FILEPATH: '/dev/urandom'<br>
> > >> >[1467750112:5385] INFO:  default timeout (secs): 20<br>
> > >> >[1467750112:5386] NOTICE:  Threads: 1 each 1024 fds<br>
> > >> >[1467750112:5387] INFO:  mem: context:          9800 bytes<br>
> > (5704 ctx<br>
> > >+<br>
> > >> >(1<br>
> > >> >thr x 4096))<br>
> > >> >[1467750112:5387] INFO:  mem: http hdr rsvd:   67712 bytes (1<br>
> > thr x<br>
> > >> >(1024 +<br>
> > >> >3208) x 16))<br>
> > >> >[1467750112:5388] INFO:  mem: pollfd map:       8192<br>
> > >> >[1467750112:5388] NOTICE:  mem: platform fd map:  8192 bytes<br>
> > >> >[1467750112:5389] INFO:  LWS_MAX_EXTENSIONS_ACTIVE: 2<br>
> > >> >[1467750112:5389] NOTICE:  mem: per-conn:          376 bytes +<br>
> > >protocol<br>
> > >> >rx<br>
> > >> >buf<br>
> > >> >[1467750112:5390] NOTICE:  canonical_hostname = bs1<br>
> > >> >callback_bsws<br>
> > [LWS_CALLBACK_OPENSSL_LOAD_EXTRA_CLIENT_VERIFY_CERTS]<br>
> > >> >fd=0<br>
> > >> >user=[�`ơ#] len=0<br>
> > >> >callback_bsws [LWS_CALLBACK_PROTOCOL_INIT] fd=0 user=[NULL]<br>
> > len=0<br>
> > >> >callback_bsws [LWS_CALLBACK_CHANGE_MODE_POLL_FD] fd=-1<br>
> > user=[NULL]<br>
> > >> >len=0<br>
> > >> >libbswslog: [LOG_INFO]: lws_client_connect: direct conn<br>
> > >> ><br>
> > >> >libbswslog: [LOG_INFO]: lws_client_connect_2<br>
> > >> ><br>
> > >> >libbswslog: [LOG_INFO]: lws_client_connect_2: address<br>
> > 192.168.1.202<br>
> > >> ><br>
> > >> >callback_bsws [LWS_CALLBACK_LOCK_POLL] fd=6 user=[NULL] len=1<br>
> > >> >callback_bsws [LWS_CALLBACK_ADD_POLL_FD] fd=6 user=[NULL] len=0<br>
> > >> >callback_bsws [LWS_CALLBACK_UNLOCK_POLL] fd=6 user=[NULL] len=1<br>
> > >> >libbswslog: [LOG_INFO]: nonblocking connect retry<br>
> > >> ><br>
> > >> >callback_bsws [LWS_CALLBACK_LOCK_POLL] fd=6 user=[NULL] len=0<br>
> > >> >callback_bsws [LWS_CALLBACK_CHANGE_MODE_POLL_FD] fd=6<br>
> > user=[NULL]<br>
> > >len=0<br>
> > >> >callback_bsws [LWS_CALLBACK_UNLOCK_POLL] fd=6 user=[NULL] len=0<br>
> > >> >Waiting for connect...<br>
> > >> >libbswslog: [LOG_INFO]: lws_client_connect_2<br>
> > >> ><br>
> > >> >libbswslog: [LOG_INFO]: lws_client_connect_2: address<br>
> > 192.168.1.202<br>
> > >> ><br>
> > >> >libbswslog: [LOG_INFO]: connected<br>
> > >><br>
> > >> Hm.  "Connection refused" was a red herring then, it's not<br>
> > refused<br>
> > >and<br>
> > >> does connect.<br>
> > >><br>
> > >> >Then when I kill the server:<br>
> > >> ><br>
> > >> >callback_bsws [LWS_CALLBACK_LOCK_POLL] fd=6 user=[NULL] len=0<br>
> > >> >callback_bsws [LWS_CALLBACK_CHANGE_MODE_POLL_FD] fd=6<br>
> > user=[NULL]<br>
> > >len=0<br>
> > >> >callback_bsws [LWS_CALLBACK_UNLOCK_POLL] fd=6 user=[NULL] len=0<br>
> > >> >callback_bsws [LWS_CALLBACK_CLIENT_APPEND_HANDSHAKE_HEADER]<br>
> > fd=6<br>
> > >> >user=[NULL] len=3794<br>
> > >><br>
> > >> This comes when the client is creating his upgrade request to<br>
> > use ws<br>
> > >> instead of http.<br>
> > >><br>
> > >> But that should be sequenced automatically to be done after the<br>
> > >connect<br>
> > >> state, not happen when the peer died.<br>
> > >><br>
> > >> What is the situation with this "changed" test client about it<br>
> > >getting<br>
> > >> service?<br>
> > >><br>
> > >> -Andy<br>
> > >><br>
> > >> >callback_bsws [LWS_CALLBACK_LOCK_POLL] fd=6 user=[NULL] len=0<br>
> > >> >callback_bsws [LWS_CALLBACK_CHANGE_MODE_POLL_FD] fd=6<br>
> > user=[NULL]<br>
> > >len=0<br>
> > >> >callback_bsws [LWS_CALLBACK_UNLOCK_POLL] fd=6 user=[NULL] len=0<br>
> > >> >callback_bsws [LWS_CALLBACK_CLIENT_APPEND_HANDSHAKE_HEADER]<br>
> > fd=6<br>
> > >> >user=[NULL] len=3794<br>
> > >> >callback_bsws [LWS_CALLBACK_LOCK_POLL] fd=6 user=[NULL] len=1<br>
> > >> >callback_bsws [LWS_CALLBACK_DEL_POLL_FD] fd=6 user=[NULL] len=0<br>
> > >> >callback_bsws [LWS_CALLBACK_UNLOCK_POLL] fd=6 user=[NULL] len=1<br>
> > >> >callback_bsws [LWS_CALLBACK_WSI_DESTROY] fd=6 user=[NULL] len=0<br>
> > >> ><br>
> > >> ><br>
> > >> >Thanks guys.<br>
> > >> >Brice.<br>
> > >> ><br>
> > >> ><br>
> > >> >On Tue, Jul 5, 2016 at 3:47 PM, Roger Light <<a href="mailto:roger@atchoo.org">roger@atchoo.org</a>><br>
> > >wrote:<br>
> > >> ><br>
> > >> >> Hi Brice,<br>
> > >> >><br>
> > >> >> If you've got a working and a non-working version, then a<br>
> > good<br>
> > >option<br>
> > >> >> is to use "git bisect" to find the problem commit.<br>
> > >> >><br>
> > >> >> git clone <a href="https://github.com/warmcat/libwebsockets" rel="noreferrer" target="_blank">https://github.com/warmcat/libwebsockets</a> lws-bisect<br>
> > >> >> cd lws-bisect<br>
> > >> >> git bisect start<br>
> > >> >> git bisect good v1.6.0-chrome48-firefox42 # assuming this one<br>
> > >works<br>
> > >> >> git bisect bad v1.7.0 # assuming this version doesn't<br>
> > >> >><br>
> > >> >> git will then checkout a changeset for you to test - so make<br>
> > your<br>
> > >> >> build directory, run cmake and carry out your tests. If the<br>
> > test<br>
> > >is<br>
> > >> >> successful, run "git bisect good", else run "git bisect bad".<br>
> > >You'll<br>
> > >> >> have to carry out roughly 6 tests. At the end of the process<br>
> > >you'll<br>
> > >> >be<br>
> > >> >> told which commit in libwebsockets produced the error you are<br>
> > >seeing<br>
> > >> >-<br>
> > >> >> assuming that the problem is with libwebsockets of course.<br>
> > >> >><br>
> > >> >> When you're running your tests, make sure you start from a<br>
> > clean<br>
> > >> >build<br>
> > >> >> and that your own client code is also recompiled against the<br>
> > test<br>
> > >> >> version.<br>
> > >> >><br>
> > >> >> Best of luck,<br>
> > >> >><br>
> > >> >> Roger<br>
> > >> >><br>
> > >> >><br>
> > >> >><br>
> > >> >> On Tue, Jul 5, 2016 at 6:48 PM, Brice Hamon<br>
> > ><<a href="mailto:normandviking@gmail.com">normandviking@gmail.com</a>><br>
> > >> >> wrote:<br>
> > >> >> > Thanks Andy,<br>
> > >> >> ><br>
> > >> >> > I will report my progress.<br>
> > >> >> ><br>
> > >> >> > The "Connection refused" is reported by the browser<br>
> > (Chrome), so<br>
> > >as<br>
> > >> >you<br>
> > >> >> > said, it could be something not transport related, but<br>
> > rather<br>
> > >SSL<br>
> > >> >as  I<br>
> > >> >> am<br>
> > >> >> > inclined to think.<br>
> > >> >> ><br>
> > >> >> > Thanks<br>
> > >> >> > Brice.<br>
> > >> >> ><br>
> > >> >> > On Tue, Jul 5, 2016 at 1:44 PM, Andy Green <<a href="mailto:andy@warmcat.co">andy@warmcat.co</a><br>
> > m><br>
> > >> >wrote:<br>
> > >> >> >><br>
> > >> >> >><br>
> > >> >> >><br>
> > >> >> >> On July 5, 2016 11:40:30 PM GMT+08:00, Brice Hamon<br>
> > >> >> >> <<a href="mailto:normandviking@gmail.com">normandviking@gmail.com</a>> wrote:<br>
> > >> >> >> >Hi Andy,<br>
> > >> >> >> ><br>
> > >> >> >> >I have not made progress on finding where the problem is.<br>
> > >> >> >> ><br>
> > >> >> >> >One thing I was doing and seemed strange was in the SSL<br>
> > certs<br>
> > >> >side:<br>
> > >> >> >> ><br>
> > >> >> >> >if (http_ssl_)<br>
> > >> >> >> >    {<br>
> > >> >> >> >        if (!chain_file_.empty())<br>
> > >> >> >> >        {<br>
> > >> >> >> >          // cert file is not needed as it's included in<br>
> > the<br>
> > >> >chain with<br>
> > >> >> >> >all intermediate cert.<br>
> > >> >> >> >            //info.ssl_cert_filepath =<br>
> > cert_file_.c_str();<br>
> > >> >> >> >            info.ssl_private_key_filepath =<br>
> > key_file_.c_str();<br>
> > >> >> >> >            info.ssl_cert_filepath = chain_file_.c_str();<br>
> > >> >> >> >        }<br>
> > >> >> >> >        else<br>
> > >> >> >> >        {<br>
> > >> >> >> >            // Simple key/cert WSS<br>
> > >> >> >> >            info.ssl_cert_filepath = cert_file_.c_str();<br>
> > >> >> >> >            info.ssl_private_key_filepath =<br>
> > key_file_.c_str();<br>
> > >> >> >> >        }<br>
> > >> >> >> >    }<br>
> > >> >> >> >    else<br>
> > >> >> >> >    {<br>
> > >> >> >> >        info.ssl_cert_filepath = NULL;<br>
> > >> >> >> >        info.ssl_private_key_filepath = NULL;<br>
> > >> >> >> >    }<br>
> > >> >> >> ><br>
> > >> >> >> >    info.gid = -1;<br>
> > >> >> >> >    info.uid = -1;<br>
> > >> >> >> >    info.options = 0;<br>
> > >> >> >> >    info.ka_time = 10; // keep alive every 10<br>
> > >> >> >> >    info.ka_probes = 1; // how many times to try to get<br>
> > >response<br>
> > >> >before<br>
> > >> >> >> >giving up<br>
> > >> >> >> >    info.ka_interval = 2; // how long to wait before each<br>
> > >> >ka_probes<br>
> > >> >> >> >    info.user = this; // to get ourself inthe static<br>
> > callback<br>
> > >via<br>
> > >> >the<br>
> > >> >> >> >context.<br>
> > >> >> >> ><br>
> > >> >> >> >    context_ = libwebsocket_create_context(&info);<br>
> > >> >> >> ><br>
> > >> >> >> ><br>
> > >> >> >> >and this was the only way I made the lib work with 3 ssl<br>
> > files<br>
> > >> >(key,<br>
> > >> >> >> >cert<br>
> > >> >> >> >and chain).<br>
> > >> >> >> ><br>
> > >> >> >> >I tried the "correct" way with<br>
> > >> >> >> ><br>
> > >> >> >> >info.ssl_cert_filepath        = cert_file_.c_str();<br>
> > >> >> >> >info.ssl_private_key_filepath = key_file_.c_str();<br>
> > >> >> >> >info.ssl_ca_filepath          = chain_file_.c_str();<br>
> > >> >> >> ><br>
> > >> >> >> >With no luck.<br>
> > >> >> >> ><br>
> > >> >> >> >Any clues?<br>
> > >> >> >><br>
> > >> >> >> Yeah your biggest clue is "Connection Refused".<br>
> > >> >> >><br>
> > >> >> >> Also you should sanity-check the lws test server itself<br>
> > works<br>
> > >on<br>
> > >> >your<br>
> > >> >> >> toolchain / platform.<br>
> > >> >> >><br>
> > >> >> >> >I think if we find the problem in 1.7, 2.0 will work as<br>
> > well.<br>
> > >> >> >><br>
> > >> >> >> I understand it looks like that to you, since you try 1.6<br>
> > and<br>
> > >it<br>
> > >> >works<br>
> > >> >> and<br>
> > >> >> >> 1.7 acts different.  But it's not clear the problem is in<br>
> > the<br>
> > >lib.<br>
> > >> >> It's not<br>
> > >> >> >> even clear to me what the problem is.<br>
> > >> >> >><br>
> > >> >> >> If it was happening to me I would grab hold of the<br>
> > Connection<br>
> > >> >Refused<br>
> > >> >> end<br>
> > >> >> >> of it, eg look what netstat says and eyeball traffic with<br>
> > >tcpdump.<br>
> > >> > The<br>
> > >> >> lib<br>
> > >> >> >> doesn't issue a tcp connection refused, as I explained it<br>
> > means<br>
> > >> >> something<br>
> > >> >> >> basic like the listen socket is not there.<br>
> > >> >> >><br>
> > >> >> >> So the first move is confirm if that is literally a tcp<br>
> > >connection<br>
> > >> >> >> refused, or you mean some handwaving 'communication<br>
> > failed'<br>
> > >error<br>
> > >> >that<br>
> > >> >> is<br>
> > >> >> >> actually something totally different and a red herring.<br>
> > >> >> >><br>
> > >> >> >> Build it in debug mode<br>
> > >> >> >><br>
> > >> >> >> cmake -DCMAKE_BUILD_TYPE=DEBUG<br>
> > >> >> >><br>
> > >> >> >> and crank the logs up, equivalent to -d65535 on the test<br>
> > apps<br>
> > >and<br>
> > >> >look<br>
> > >> >> in<br>
> > >> >> >> there both at init and at connection attempt.  Compare the<br>
> > logs<br>
> > >> >for test<br>
> > >> >> >> server in the same cases.<br>
> > >> >> >><br>
> > >> >> >> -Andy<br>
> > >> >> >><br>
> > >> >> >> >Thank you in advance,<br>
> > >> >> >> >Brice.<br>
> > >> >> >> ><br>
> > >> >> >> ><br>
> > >> >> >> >On Mon, Jul 4, 2016 at 5:29 PM, Brice Hamon<br>
> > >> ><<a href="mailto:normandviking@gmail.com">normandviking@gmail.com</a>><br>
> > >> >> >> >wrote:<br>
> > >> >> >> ><br>
> > >> >> >> >> Ok 1.7.0 breaks the server. All version before are OK.<br>
> > >> >> >> >><br>
> > >> >> >> >> The only change I can see impacting my code was the<br>
> > warning:<br>
> > >> >> >> >><br>
> > >> >> >> >> bswebsocket.cpp:155:23: warning: `const lws_extension*<br>
> > >> >> >> >> lws_get_internal_extensions()' is deprecated (declared<br>
> > at<br>
> > >> >> >> >><br>
> > >/export/home/development/3rdparty/include/libwebsockets.h:1877)<br>
> > >> >> >> >> [-Wdeprecated-declarations]<br>
> > >> >> >> >><br>
> > >> >> >> >> So I am investigating in that side.<br>
> > >> >> >> >><br>
> > >> >> >> >> On Mon, Jul 4, 2016 at 4:25 PM, Brice Hamon<br>
> > >> ><<a href="mailto:normandviking@gmail.com">normandviking@gmail.com</a><br>
> > >> >> ><br>
> > >> >> >> >> wrote:<br>
> > >> >> >> >><br>
> > >> >> >> >>> Hi Andy,<br>
> > >> >> >> >>><br>
> > >> >> >> >>> I am working backwards in version. So far 2.0.2 to<br>
> > 1.7.2<br>
> > >does<br>
> > >> >not<br>
> > >> >> >> >work.<br>
> > >> >> >> >>> 1.5.1 does work. I will eventually where it breaks.<br>
> > >> >> >> >>><br>
> > >> >> >> >>> I'll keep you posted.<br>
> > >> >> >> >>><br>
> > >> >> >> >>> On Thu, Jun 30, 2016 at 1:13 PM, Brice Hamon<br>
> > >> >> >> ><<a href="mailto:normandviking@gmail.com">normandviking@gmail.com</a>><br>
> > >> >> >> >>> wrote:<br>
> > >> >> >> >>><br>
> > >> >> >> >>>> Thanks Andy,<br>
> > >> >> >> >>>><br>
> > >> >> >> >>>> I do not think it is a networking or environment<br>
> > issue as<br>
> > >the<br>
> > >> >same<br>
> > >> >> >> >code<br>
> > >> >> >> >>>> running on the same host with 1.4 works and not 2.0.<br>
> > >> >> >> >>>><br>
> > >> >> >> >>>> I just wanted to make sure I did not forgot an new<br>
> > call to<br>
> > >> >init SSL<br>
> > >> >> >> >or<br>
> > >> >> >> >>>> something like that not present in 1.4.<br>
> > >> >> >> >>>><br>
> > >> >> >> >>>> I'll dig into it and report back.<br>
> > >> >> >> >>>><br>
> > >> >> >> >>>> Thanks again<br>
> > >> >> >> >>>> Brice.<br>
> > >> >> >> >>>><br>
> > >> >> >> >>>> On Wed, Jun 29, 2016 at 1:56 PM, Andy Green<br>
> > >> ><<a href="mailto:andy@warmcat.com">andy@warmcat.com</a>><br>
> > >> >> >> >wrote:<br>
> > >> >> >> >>>><br>
> > >> >> >> >>>>><br>
> > >> >> >> >>>>><br>
> > >> >> >> >>>>> On June 29, 2016 11:52:31 PM GMT+08:00, Brice Hamon<br>
> > <<br>
> > >> >> >> >>>>> <a href="mailto:normandviking@gmail.com">normandviking@gmail.com</a>> wrote:<br>
> > >> >> >> >>>>> >Hi Andy,<br>
> > >> >> >> >>>>> ><br>
> > >> >> >> >>>>> >I just upgraded my server from 1.4 to 2.0.<br>
> > >> >> >> >>>>> ><br>
> > >> >> >> >>>>> >Not really a big task, just lws_ and a couple of<br>
> > >> >adjustments,<br>
> > >> >> >> >>>>> ><br>
> > >> >> >> >>>>> >But now my server does not work anymore.  I use an<br>
> > >external<br>
> > >> >> >> >polling<br>
> > >> >> >> >>>>> >mechanism, and I see the first FD_ADD so the epoll<br>
> > is<br>
> > >> >working.<br>
> > >> >> >> >>>>><br>
> > >> >> >> >>>>> That doesn't follow actually, it means only that<br>
> > lws'<br>
> > >code<br>
> > >> >to<br>
> > >> >> >> >expose<br>
> > >> >> >> >>>>> poll fds changes to the callback is working; it's<br>
> > caused<br>
> > >by<br>
> > >> >> >> >creating the<br>
> > >> >> >> >>>>> listen socket during init, not by servicing (e)poll<br>
> > >events.<br>
> > >> >The<br>
> > >> >> >> >log<br>
> > >> >> >> >>>>> doesn't show any evidence of servicing (e)poll<br>
> > events.<br>
> > >> >> >> >>>>><br>
> > >> >> >> >>>>> >But when I try to connect with a browser or client<br>
> > >program<br>
> > >> >I get<br>
> > >> >> >> >a CONN<br>
> > >> >> >> >>>>> >REFUSED and I don't see anything happening on the<br>
> > server<br>
> > >> >side. I<br>
> > >> >> >> >just<br>
> > >> >> >> >>>>> >see<br>
> > >> >> >> >>>>> >it listening on the correct port.<br>
> > >> >> >> >>>>><br>
> > >> >> >> >>>>> Connection refused is really specific, it means for<br>
> > the<br>
> > >peer<br>
> > >> >there<br>
> > >> >> >> >was<br>
> > >> >> >> >>>>> nobody listening at the port.  That can mean the<br>
> > listen<br>
> > >> >socket<br>
> > >> >> >> >bound to a<br>
> > >> >> >><br>
> > >> >> >> This observation is still true if it's literally<br>
> > "Connection<br>
> > >> >Refused".<br>
> > >> >> >><br>
> > >> >> >> -Andy<br>
> > >> >> >><br>
> > >> >> >> >>>>> different interface than your client reached (check<br>
> > it<br>
> > >with<br>
> > >> >> >> >netstat -pltn<br>
> > >> >> >> >>>>> at the server, 0.0.0.0 means all interfaces) or a<br>
> > >firewall<br>
> > >> >got in<br>
> > >> >> >> >the way,<br>
> > >> >> >> >>>>> or you reached the wrong ip (name resolution issue<br>
> > at<br>
> > >> >client).<br>
> > >> >> >> >>>>><br>
> > >> >> >> >>>>> >I compiled the lib plain vanilla with no options.<br>
> > >> >> >> >>>>> ><br>
> > >> >> >> >>>>> >Here is what I get as startup from your lib:<br>
> > >> >> >> >>>>> ><br>
> > >> >> >> >>>>> ><br>
> > >> >> >> >>>>> >16-06-29 11:38:24.694159 DEBUG: [WEBSOCKET ]:<br>
> > >libwebsocket:<br>
> > >> >> >> >Initial<br>
> > >> >> >> >>>>> >logging<br>
> > >> >> >> >>>>> >level 15<br>
> > >> >> >> >>>>> >16-06-29 11:38:24.694176 DEBUG: [WEBSOCKET ]:<br>
> > >libwebsocket:<br>
> > >> >> >> >>>>> >Libwebsockets<br>
> > >> >> >> >>>>> >version: 2.0.0 xxxx@xxxx-v2.0.0-95-ge943a02<br>
> > >> >> >> >>>>> >16-06-29 11:38:24.694181 DEBUG: [WEBSOCKET ]:<br>
> > >libwebsocket:<br>
> > >> >IPV6<br>
> > >> >> >> >not<br>
> > >> >> >> >>>>> >compiled in<br>
> > >> >> >> >>>>> >16-06-29 11:38:24.694193 DEBUG: [WEBSOCKET ]:<br>
> > >libwebsocket:<br>
> > >> >libev<br>
> > >> >> >> >>>>> >support<br>
> > >> >> >> >>>>> >not compiled in<br>
> > >> >> >> >>>>> >16-06-29 11:38:24.694198 DEBUG: [WEBSOCKET ]:<br>
> > >libwebsocket:<br>
> > >> >libuv<br>
> > >> >> >> >>>>> >support<br>
> > >> >> >> >>>>> >not compiled in<br>
> > >> >> >> >>>>> >16-06-29 11:38:24.694356 DEBUG: [WEBSOCKET ]:<br>
> > >libwebsocket:<br>
> > >> >> >> >Threads: 1<br>
> > >> >> >> >>>>> >each 1024 fds<br>
> > >> >> >> >>>>> >16-06-29 11:38:24.694453 DEBUG: [WEBSOCKET ]:<br>
> > >libwebsocket:<br>
> > >> > mem:<br>
> > >> >> >> >>>>> >platform<br>
> > >> >> >> >>>>> >fd map:  8192 bytes<br>
> > >> >> >> >>>>> >16-06-29 11:38:24.694526 DEBUG: [WEBSOCKET ]:<br>
> > >libwebsocket:<br>
> > >> >> >> >Compiled<br>
> > >> >> >> >>>>> >with<br>
> > >> >> >> >>>>> >OpenSSL support<br>
> > >> >> >> >>>>> >16-06-29 11:38:24.695057 DEBUG: [WEBSOCKET ]:<br>
> > >libwebsocket:<br>
> > >> >> >> >Creating<br>
> > >> >> >> >>>>> >Vhost<br>
> > >> >> >> >>>>> >'default' port 7682, 2 protocols, IPv6 off<br>
> > >> >> >> >>>>> >16-06-29 11:38:24.695102 DEBUG: [WEBSOCKET ]:<br>
> > >libwebsocket:<br>
> > >> >> >> >Using SSL<br>
> > >> >> >> >>>>> >mode<br>
> > >> >> >> >>>>> >16-06-29 11:38:24.698961 DEBUG: [WEBSOCKET ]:<br>
> > >libwebsocket:<br>
> > >> > SSL<br>
> > >> >> >> >ECDH<br>
> > >> >> >> >>>>> >curve<br>
> > >> >> >> >>>>> >'prime256v1'<br>
> > >> >> >> >>>>> >16-06-29 11:38:24.699011 INFO : [WEBSOCKET ]:<br>
> > >callback_http<br>
> > >> >> >> >>>>> >LWS_CALLBACK_OPENSSL_LOAD_EXTRA_SERVER_VERIFY_CERTS<br>
> > fd=0<br>
> > >> >> >> >>>>> >context=0x7efff0002800 user=[`uZ&] len=0<br>
> > >> >> >> >>>>> >16-06-29 11:38:24.699021 ERROR: [WEBSOCKET ]:<br>
> > >> >callback_http: case<br>
> > >> >> >> >>>>> >LWS_CALLBACK_OPENSSL_LOAD_EXTRA_SERVER_VERIFY_CERTS<br>
> > not<br>
> > >> >handled.<br>
> > >> >> >> >>>>> >16-06-29 11:38:24.700680 INFO : [WEBSOCKET ]:<br>
> > >callback_http<br>
> > >> >> >> >>>>> >LWS_CALLBACK_LOCK_POLL fd=85 context=0x7efff0002800<br>
> > >> >user=[NULL]<br>
> > >> >> >> >len=1<br>
> > >> >> >> >>>>> >16-06-29 11:38:24.700719 INFO : [WEBSOCKET ]:<br>
> > >callback_http<br>
> > >> >> >> >>>>> >LWS_CALLBACK_ADD_POLL_FD fd=85<br>
> > context=0x7efff0002800<br>
> > >> >user=[NULL]<br>
> > >> >> >> >len=0<br>
> > >> >> >> >>>>> >16-06-29 11:38:24.700758 INFO : [WEBSOCKET ]:<br>
> > >callback_http<br>
> > >> >> >> >>>>> >LWS_CALLBACK_UNLOCK_POLL fd=85<br>
> > context=0x7efff0002800<br>
> > >> >user=[NULL]<br>
> > >> >> >> >len=1<br>
> > >> >> >> >>>>> >16-06-29 11:38:24.700811 DEBUG: [WEBSOCKET ]:<br>
> > >libwebsocket:<br>
> > >> >> >> >Listening<br>
> > >> >> >> >>>>> >on<br>
> > >> >> >> >>>>> >port 7682<br>
> > >> >> >> >>>>> >16-06-29 11:38:24.700834 DEBUG: [WEBSOCKET ]:<br>
> > >libwebsocket:<br>
> > >> > mem:<br>
> > >> >> >> >>>>> >per-conn:<br>
> > >> >> >> >>>>> >         496 bytes + protocol rx buf<br>
> > >> >> >> >>>>> >16-06-29 11:38:24.700919 DEBUG: [WEBSOCKET ]:<br>
> > >libwebsocket:<br>
> > >> >> >> >>>>> > canonical_hostname = xxxx<br>
> > >> >> >> >>>>> ><br>
> > >> >> >> >>>>> >Then a<br>
> > >> >> >> >>>>> ><br>
> > >> >> >> >>>>> >16-06-29 11:38:25.972014 DEBUG: [WEBSOCKET ]:<br>
> > >libwebsocket:<br>
> > >> >> >> >>>>> >lws_protocol_init<br>
> > >> >> >> >>>>> >16-06-29 11:38:25.972043 INFO : [WEBSOCKET ]:<br>
> > >callback_http<br>
> > >> >> >> >>>>> >LWS_CALLBACK_PROTOCOL_INIT fd=0<br>
> > context=0x7efff0002800<br>
> > >> >> >> >user=[NULL]<br>
> > >> >> >> >>>>> >len=0<br>
> > >> >> >> >>>>> >16-06-29 11:38:25.972049 INFO : [WEBSOCKET ]:<br>
> > >> >callback_http:<br>
> > >> >> >> >>>>> >LWS_CALLBACK_PROTOCOL_INIT<br>
> > >> >> >> >>>>> ><br>
> > >> >> >> >>>>> >And nothing else after that.<br>
> > >> >> >> >>>>><br>
> > >> >> >> >>>>> Connection Refused is a tcp level thing, it means<br>
> > you did<br>
> > >> >not<br>
> > >> >> >> >succeed<br>
> > >> >> >> >>>>> to touch the listen socket.  So there would be no<br>
> > sign of<br>
> > >> >activity<br>
> > >> >> >> >from lws<br>
> > >> >> >> >>>>> about that.<br>
> > >> >> >> >>>>><br>
> > >> >> >> >>>>> >I guess  my straight port from 1.4 to 2.0 was just<br>
> > been<br>
> > >> >> >> >optimistic. I<br>
> > >> >> >> >>>>> >am<br>
> > >> >> >> >>>>> >forgetting something essential in order to have 2.0<br>
> > >working<br>
> > >> >like<br>
> > >> >> >> >in<br>
> > >> >> >> >>>>> >1.4.<br>
> > >> >> >> >>>>><br>
> > >> >> >> >>>>> I think either lws bound to the wrong network<br>
> > interface<br>
> > >for<br>
> > >> >> >> >listen, or<br>
> > >> >> >> >>>>> the issue is outside lws.<br>
> > >> >> >> >>>>><br>
> > >> >> >> >>>>> >Also the only question I had during the port is<br>
> > that I<br>
> > >used<br>
> > >> >the<br>
> > >> >> >> >>>>> >context->user pointer to store my own websocket<br>
> > object.<br>
> > >I<br>
> > >> >now<br>
> > >> >> >> >need to<br>
> > >> >> >> >>>>> >to a<br>
> > >> >> >> >>>>> >// Getting the context from the wsi<br>
> > >> >> >> >>>>> >struct lws_context *wsicont = lws_get_context(wsi);<br>
> > >> >> >> >>>>> ><br>
> > >> >> >> >>>>> >// Getting the user cd from the context<br>
> > >> >> >> >>>>> >BSWebSocket *websocket = (BSWebSocket<br>
> > >> >> >> >*)lws_context_user(wsicont);<br>
> > >> >> >> >>>>> ><br>
> > >> >> >> >>>>> >Is there a better way to do that? I already use the<br>
> > user<br>
> > >> >pointer<br>
> > >> >> >> >of the<br>
> > >> >> >> >>>>> >callback to get my per_session_data structure.<br>
> > >> >> >> >>>>><br>
> > >> >> >> >>>>> No it looks good.  Both of those apis are really<br>
> > cheap,<br>
> > >just<br>
> > >> >> >> >resolve to<br>
> > >> >> >> >>>>> a struct member dereference each.<br>
> > >> >> >> >>>>><br>
> > >> >> >> >>>>> -Andy<br>
> > >> >> >> >>>>><br>
> > >> >> >> >>>>> >Thank you,<br>
> > >> >> >> >>>>> ><br>
> > >> >> >> >>>>> >Brice.<br>
> > >> >> >> >>>>> ><br>
> > >> >> >> >>>>> ><br>
> > >> >> >> >>>>> >On Thu, Jun 2, 2016 at 8:48 PM, Brice Hamon<br>
> > >> >> >> ><<a href="mailto:normandviking@gmail.com">normandviking@gmail.com</a>><br>
> > >> >> >> >>>>> >wrote:<br>
> > >> >> >> >>>>> ><br>
> > >> >> >> >>>>> >> Thank you Andy,<br>
> > >> >> >> >>>>> >><br>
> > >> >> >> >>>>> >> I will get going and report my findings.<br>
> > >> >> >> >>>>> >><br>
> > >> >> >> >>>>> >> Thanks again.<br>
> > >> >> >> >>>>> >> Brice.<br>
> > >> >> >> >>>>> >><br>
> > >> >> >> >>>>> >><br>
> > >> >> >> >>>>> >> On Thu, Jun 2, 2016 at 6:20 PM, Andy Green<br>
> > >> ><<a href="mailto:andy@warmcat.com">andy@warmcat.com</a>><br>
> > >> >> >> >wrote:<br>
> > >> >> >> >>>>> >><br>
> > >> >> >> >>>>> >>><br>
> > >> >> >> >>>>> >>><br>
> > >> >> >> >>>>> >>> On June 3, 2016 1:08:32 AM GMT+08:00, Brice<br>
> > Hamon <<br>
> > >> >> >> >>>>> >>> <a href="mailto:normandviking@gmail.com">normandviking@gmail.com</a>> wrote:<br>
> > >> >> >> >>>>> >>> >Hi all,<br>
> > >> >> >> >>>>> >>> ><br>
> > >> >> >> >>>>> >>> >I have been using libwebsocket 1.4 with<br>
> > external<br>
> > >epoll<br>
> > >> >> >> >notification<br>
> > >> >> >> >>>>> >>> >loop<br>
> > >> >> >> >>>>> >>> >without a single problem for over a year now.<br>
> > >> >> >> >>>>> >>><br>
> > >> >> >> >>>>> >>> Great.<br>
> > >> >> >> >>>>> >>><br>
> > >> >> >> >>>>> >>> >All the libwebsocket functions are happening in<br>
> > one<br>
> > >> >thread so<br>
> > >> >> >> >I<br>
> > >> >> >> >>>>> >have<br>
> > >> >> >> >>>>> >>> >followed all guidelines in the README.coding<br>
> > >> >> >> >>>>> >>> >from that version.<br>
> > >> >> >> >>>>> >>> ><br>
> > >> >> >> >>>>> >>> >I think it is now time for me to upgrade as,<br>
> > >following<br>
> > >> >this<br>
> > >> >> >> >group,<br>
> > >> >> >> >>>>> >many<br>
> > >> >> >> >>>>> >>> >fix<br>
> > >> >> >> >>>>> >>> >and enhancement took place.<br>
> > >> >> >> >>>>> >>> ><br>
> > >> >> >> >>>>> >>> >Is there specific areas of change I should be<br>
> > >concerned<br>
> > >> >with,<br>
> > >> >> >> >or<br>
> > >> >> >> >>>>> >>> >important<br>
> > >> >> >> >>>>> >>> >changes in the notification area?<br>
> > >> >> >> >>>>> >>><br>
> > >> >> >> >>>>> >>> Yes at 1.6 many api names got simplified and<br>
> > >> >rationalized.<br>
> > >> >> >> >Mainly<br>
> > >> >> >> >>>>> >the<br>
> > >> >> >> >>>>> >>> api prefix got standardized to 'lws_'.  There<br>
> > are 4<br>
> > >> >steps<br>
> > >> >> >> >listed in<br>
> > >> >> >> >>>>> >the<br>
> > >> >> >> >>>>> >>> changelog<br>
> > >> >> >> >>>>> >>><br>
> > >> >> >> >>>>> >>><br>
> > >> >> >> >>>>> ><br>
> > >> >> >> >>>>><br>
> > >> >> >> ><br>
> > >> >><br>
> > >><br>
> > >><a href="https://github.com/warmcat/libwebsockets/blob/v2.0-stable/changel" rel="noreferrer" target="_blank">https://github.com/warmcat/libwebsockets/blob/v2.0-stable/changel</a><br>
> > og#L643<br>
> > >> >> >> >>>>> >>><br>
> > >> >> >> >>>>> >>> to search / replace everything in your code into<br>
> > >shape.<br>
> > >> >> >> >>>>> >>><br>
> > >> >> >> >>>>> >>> There are many other changes and improvements,<br>
> > such<br>
> > >as<br>
> > >> >> >> >multiple<br>
> > >> >> >> >>>>> >vhost<br>
> > >> >> >> >>>>> >>> support, CGI support, protocol plugins, lwsws<br>
> > etc.<br>
> > >It's<br>
> > >> >hard<br>
> > >> >> >> >to<br>
> > >> >> >> >>>>> >predict<br>
> > >> >> >> >>>>> >>> which are interesting, if you have external<br>
> > epoll()<br>
> > >just<br>
> > >> >to<br>
> > >> >> >> >get<br>
> > >> >> >> >>>>> >epoll, the<br>
> > >> >> >> >>>>> >>> new built-in libuv support might be<br>
> > interesting... if<br>
> > >so<br>
> > >> >then<br>
> > >> >> >> >lwsws<br>
> > >> >> >> >>>>> >and<br>
> > >> >> >> >>>>> >>> plugins might also simplify your life.<br>
> > >> >> >> >>>>> >>><br>
> > >> >> >> >>>>> >>> If you need external event loop to interface to<br>
> > >> >something<br>
> > >> >> >> >else, then<br>
> > >> >> >> >>>>> >that<br>
> > >> >> >> >>>>> >>> should still work the same.<br>
> > >> >> >> >>>>> >>><br>
> > >> >> >> >>>>> >>> >Thanks all and especially Andy, your lib rocks<br>
> > :)<br>
> > >> >> >> >>>>> >>><br>
> > >> >> >> >>>>> >>> Thanks for the kind words ^^<br>
> > >> >> >> >>>>> >>><br>
> > >> >> >> >>>>> >>> -Andy<br>
> > >> >> >> >>>>> >>><br>
> > >> >> >> >>>>> >>> >Brice.<br>
> > >> >> >> >>>>> >>> ><br>
> > >> >> >> >>>>> >>> ><br>
> > >> >> >> >>>>> >>><br>
> > >> >> >> >>>>><br>
> > >> >> >> >>>>><br>
> > >> >> >><br>
> > >> >> >> >>><br>
> > >> >><br>
> > >><br>
> > >><br>
> > >>>>>------------------------------------------------------------<br>
> > ------------<br>
> > >> >> >> >>>>> >>> ><br>
> > >> >> >> >>>>> >>> >_______________________________________________<br>
> > >> >> >> >>>>> >>> >Libwebsockets mailing list<br>
> > >> >> >> >>>>> >>> ><a href="mailto:Libwebsockets@ml.libwebsockets.org">Libwebsockets@ml.libwebsockets.org</a><br>
> > >> >> >> >>>>> >>><br>
> > >><a href="http://libwebsockets.org/mailman/listinfo/libwebsockets" rel="noreferrer" target="_blank">http://libwebsockets.org/mailman/listinfo/libwebsockets</a><br>
> > >> >> >> >>>>> >>><br>
> > >> >> >> >>>>> >>><br>
> > >> >> >> >>>>> >><br>
> > >> >> >> >>>>><br>
> > >> >> >> >>>>><br>
> > >> >> >> >>>><br>
> > >> >> >> >>><br>
> > >> >> >> >><br>
> > >> >> >><br>
> > >> >> ><br>
> > >> >> ><br>
> > >> >> > _______________________________________________<br>
> > >> >> > Libwebsockets mailing list<br>
> > >> >> > <a href="mailto:Libwebsockets@ml.libwebsockets.org">Libwebsockets@ml.libwebsockets.org</a><br>
> > >> >> > <a href="http://libwebsockets.org/mailman/listinfo/libwebsockets" rel="noreferrer" target="_blank">http://libwebsockets.org/mailman/listinfo/libwebsockets</a><br>
> > >> >> ><br>
> > >> >><br>
> > >><br>
> > >><br>
> ><br>
> ><br>
><br>
_______________________________________________<br>
Libwebsockets mailing list<br>
<a href="mailto:Libwebsockets@ml.libwebsockets.org">Libwebsockets@ml.libwebsockets.org</a><br>
<a href="http://libwebsockets.org/mailman/listinfo/libwebsockets" rel="noreferrer" target="_blank">http://libwebsockets.org/mailman/listinfo/libwebsockets</a><br>
</div></div></blockquote></div><br></div>