[Libwebsockets] Problem when running on ARM platform

Andy Green andy at warmcat.com
Sun Nov 9 00:46:26 CET 2014

On 9 November 2014 00:05:50 GMT+08:00, "Halpin, Joe" <jhalpin at navigationsolutions.com> wrote:
>I tried running tcpdump on both test-echo and the existing python
>client (using ws4py). I didn't see anything substantially different
>between the two, so I upped the debug level for test-echo to 65535 as
>suggested, and ran it again. Truncated output is shown below.  It looks
>like it's parsing a response (elided), so I don't understand the 'no
>ACCEPT' line below.
>Am I missing something? I'm still a bit uncertain as to how some of
>this works.
># ./zibox-test --client zibox -d 65535
>[411910:2030] NOTICE: Built to support client operations
>[411910:2032] NOTICE: Built to support server operations
>lwsts[4779]: libwebsockets echo test - (C) Copyright 2010-2013 Andy
>Green <andy at warmcat.com> - licensed under LGPL2.1
>lwsts[4779]: Running in client mode
>lwsts[4779]: Initial logging level 65535
>lwsts[4779]: Library version: 1.3 unknown-build-hash
>lwsts[4779]: IPV6 not compiled in
>lwsts[4779]: libev support not compiled in
>lwsts[4779]:  LWS_MAX_HEADER_LEN: 1024
>lwsts[4779]:  LWS_MAX_PROTOCOLS: 5
>lwsts[4779]:  SPEC_LATEST_SUPPORTED: 13
>lwsts[4779]:  AWAITING_TIMEOUT: 5
>lwsts[4779]:  SYSTEM_RANDOM_FILEPATH: '/dev/urandom'
>lwsts[4779]:  LWS_MAX_ZLIB_CONN_BUFFER: 65536
>lwsts[4779]:  static allocation: 4472 + (12 x 1024 fds) = 16760 bytes
>lwsts[4779]:  canonical_hostname = production-
>lwsts[4779]:  per-conn mem: 140 + 1606 headers + protocol rx buf
>lwsts[4779]:   Protocol: tabletNotification
>lwsts[4779]: Client connecting to zibox:80....
>lwsts[4779]: libwebsocket_client_connect: direct conn
>lwsts[4779]: libwebsocket_client_connect_2
>lwsts[4779]: libwebsocket_client_connect_2: address zibox
>lwsts[4779]: insert_wsi_socket_into_fds: wsi=0x265a8, sock=7, fds pos=1
>lwsts[4779]: nonblocking connect retry
>lwsts[4779]: Client connected to zibox:80
>lwsts[4779]: libwebsocket_client_connect_2
>lwsts[4779]: libwebsocket_client_connect_2: address zibox
>lwsts[4779]: connected
>[ ... ] (parsing output)
>'wsts[4779]: WSI_TOKEN_NAME_PART '
>lwsts[4779]: WSI_TOKEN_NAME_PART '
>lwsts[4779]: known hdr 8
>lwsts[4779]: no ACCEPT

It means the required sec-websocket-accept header is not there in the upgrade response from the server.

Please use tcpdump -s0 -X to capture the plaintext http upgrade request and response packets and post it here.


>lwsts[4779]: closing connection due to bail2 connection error
>lwsts[4779]: close: just_kill_connection
>lwsts[4779]: remove_wsi_socket_from_fds: wsi=0x265a8, sock=7, fds pos=1
>lwsts[4779]: not calling back closed
>^Clwsts[4779]: libwebsocket_context_destroy
>lwsts[4779]: libwebsockets-test-echo exited cleanly
>-----Original Message-----
>From: Andy Green [mailto:extracats at googlemail.com] On Behalf Of Andy
>Sent: Friday, November 07, 2014 6:36 PM
>To: Halpin, Joe; libwebsockets at ml.libwebsockets.org
>Subject: Re: [Libwebsockets] Problem when running on ARM platform
>On 8 November 2014 04:53:13 GMT+08:00, "Halpin, Joe"
><jhalpin at navigationsolutions.com> wrote:
>>I have a test program written to run on both i386 and ARM, which 
>>behaves differently from one platform to the other (it's a pared down 
>>version of test-echo.c). I'm not using command line options, so I have
>>this as part of the variable setup:
>>#ifdef __ARM_EABI__
>>    char address[256] = "";
>>    char interface_name[128] = "usb0";
>>    char address[256] = "echo.websocket.org";
>>    char interface_name[128] = "eth0";
>It's not related to your problem, but for static strings that will
>never be written, you should drop the arbitrary length inside the []
>because it's just wasting space.
>And if these are declared at function scope but are never changed, also
>mark them static to save space and code.
>>The program works perfectly on i386, but apparently does nothing on my
>>ARM platform. I added some debug output, but it just shows the 
>>[411859:4774] NOTICE: Initial logging level 7
>Force the logging level to, eg, 65535
>>[411859:4777] NOTICE: Library version: 1.3 unknown-build-hash 
>>[411859:4777] NOTICE: IPV6 not compiled in [411859:4778] NOTICE: libev
>>support not compiled in [411859:4785] NOTICE:  static allocation: 4472
>>+ (12 x 1024 fds) =
>>16760 bytes
>>[411859:4789] NOTICE:  canonical_hostname = production- 
>>[411859:4789] NOTICE:  per-conn mem: 140 + 1606 headers + protocol rx 
>>buf Calling libwebsocket_client_connect
>So starting the connection was okay?
>>wsi created
>>at bail:
>>[411860:5119] NOTICE: libwebsocket_context_destroy
>>The #ifdef block is the only difference between the two versions. Does
>>this ring a bell with anyone here?
>I would confirm the test apps work on your Arm toolchain / board before
>doing anything else.  These are the golden sanity check for lws.
>If they work everything else should work.
>Notice the connection request just starts the ball rolling, the actual
>connection happens asynchronously during subsequent service depending
>on network latencies etc.
>>Libwebsockets mailing list
>>Libwebsockets at ml.libwebsockets.org
>Libwebsockets mailing list
>Libwebsockets at ml.libwebsockets.org

More information about the Libwebsockets mailing list