3 Replies Latest reply on Jun 2, 2015 11:37 PM by userc_16145

    Websocket handshake stuck



      I'm trying to develop a websocket client on the wiced eval board. I'm currently using SDK 3.1.2.

      Now I'm stuck at websocket_handshake() function.

      I had a websocket server up on my Mac and saw the handshake message from the client.

      However, the client was stuck at receiving handshake message from the server and finally the watch dog expired and the system got reset.

      After poking around, I find that if I comment out line the following line in in websocket_connect() function.

      wiced_tcp_register_callbacks( &websocket->socket, websocket->callbacks->on_open, NULL, websocket->callbacks->on_close );

      The handshake can process well.

      Anybody know why?

      I do have those callback functions (on_open, on_close, on_message) implemented but all of them have empty body.

      Maybe I am not supposed to leave them empty but the question is what I am supposed to implement them in order to make the handshake process successfully?




        • 1. Re: Websocket handshake stuck

          I've had the same problem, turned out to be lifetime of one of the callbacks struct parameter.


          Make sure your wiced_websocket_callbacks_t argument to wiced_websocket_connect or wiced_websocket_secure_connect is not allocated on the stack, the library does not take a copy and expects it to have lifetime at least the duration of the websocket connection. I fixed it by creating a static object for this.


          You may also find this thread helpful. It took me some hacks and fixes to make it work. Broadcom says that this library is not supported yet (?) in 3.1.2.

          • 2. Re: Websocket handshake stuck

            Thank you Alex for your quick response!

            Let me look at that thread.

            May get back to you if any question.

            Hopefully the new SDK release is coming soon.




            • 3. Re: Websocket handshake stuck

              Now I guess I know what happened.

              wiced_tcp_register_callbacks( &websocket->socket, websocket->callbacks->on_open, NULL, websocket->callbacks->on_close ) in wiced_websocket_connet() gives a NULL for on_message...

              wiced_tcp_register_callbacks() checks if the input callbacks are NULL though. internal_async_socket_callback() who actually calls the callbacks does not check if the callbacks are NULL or not. The NULL check in wiced_tcp_register_callbacks() is actually useless as it doesn't prevent internal_async_socket_callback() to call the NULL function anyway. The workaround would be whenever you call wiced_tcp_register_callbacks() you have to make sure that all three callback functions non-NULL as argument. If you really don't want to register one of the three callbacks, you have to implement it with an empty body and pass it to wiced_tcp_register_callbacks().

              Note there is a dup wiced_tcp_register_callbacks() in wiced_websocket_connect() after handshake. Basically you can combine this the two wiced_tcp_register_callbacks() together.