Close Frame payload code is a string and not short

[TheJuwlz]

Hello,

im working on a new project in my company and encountered a strange problem.
we have a websocket connection between our hardware which uses this repo and an android app which uses the OkHttp implementation of a websocket. Whats strange is, is that when i want to close the connection from the app, i get a response close frame as expected, but the close frame contains the close code "1000" as a string, so the buffer looks like this: [..., 49, 48, 48, 48, ...]
OkHttp throws an error because the first two bytes are interpreted as the value 12592 and thats not a valid close frame code.

i would check your code myself if its a problem with this repo or a problem with our implementation.. but im not that familar with code written in c.

[simon0356]

Hello TheJwlz,

Have you look at the network packet using wireshark if the close status is really encoded as a string ?
If your connection is secured (TLS encapsuled) and working with openssl you can extract the key log file to decode TLS in wireshark using environment variable SSLKEYLOGFILE=/path/to/key.log and set the path to this key in wireshark.

Simon

[TheJuwlz]

i tried that but since my android device communicates over WiFi its not that easy i guess. I couldn't see any communication packets over wireshark after the websocket communication was established, not even the encrypted stuff. Maybe i did something wrong or i need to open a wifi hotspot and try to move the communication over that network to see everything in wireshark? i dont really know.

I tested it while my android device and the hardware were in the same network and i opened wireshark on a seperate laptop thats also connected to the same network, everything is connected over WiFi.

im currently implementing another library in my android app to maybe see what packets get sent and read there, but maybe someone has a better idea for me to try.

Thanks @simon0356 for the fast reply 👍

[simon0356]

It is not possible to sniff other devices packet over wifi, you best try is to plug your hotspot on an ethernet switch with port mirroring as a gateway access and to mirror packet to you host that run wireshark.
I can't believe that libwebsockets encode the close status code in a non standard way (I never experiment it, and didn't see it on wireshark). My believe is that your client library failed somewhere in the status code decoding.
In fact maybe the exception raised is caused by something else during the close processing and the information raised is incorrect.

[TheJuwlz]

i was able to see the packets inside of wireshark but sadly didnt find a way to decrypt the messages. Since i have no easy access to the server.. i will continue my search on monday when my colleague is at work again.

[lws-team]

This is actually quite simple with recent lws, if you enable at cmake -DLWS_TLS_LOG_PLAINTEXT_RX=1 -DLWS_TLS_LOG_PLAINTEXT_TX=1 then lws will give you hexdumps of plaintext tx data just as it is given to the tls library for transmit, and plaintext rx data just as it is decrypted from the tls library on receive. In this was you can snoop on what is actually happening even on tls connections.

[TheJuwlz]

Thanks for the information! i will try that on monday.

It's a very strange problem. I switched the library i use on android side to okhttp and it seems like the previous library was not checking the response close code at all.