zsock_close() doesn't fully close TCP connection of Websocket

[schweigstill]

I'm using a Websocket service on Zephyr. "Everything" works fine but when I close an Websocket connection on the server side using zsock_close() the connection is removed from the Websocket list (checked on the shell with "net websocket") and also isn't visible on the normal socket list ("net sockets"). The server sends a Websocket CLOSE packet and a TCP FIN packet but not a TCP RST.

Only if I use zsock_shutdown() the TCP RST follows after a few seconds.

The only problem on the client side is that it doesn't respond to the server's WS CLOSE with another WS CLOSE. But there should be a kind of timeout also on the server side in order to prevent accidental DoS.

According to the Zephyr documentation zsock_shutdown() isn' recommended; it even says that it is only implemented for POSIX compatibility.

Is this a bug in the Zephyr network/HTTP/WS stuff or is the timeout for TCP shutdown very long?

Platform: STM32H743, Zephyr 4.2.xx main branch

[jukkar]

@schweigstill could you create a proper issue for this so this is not forgotten?

[jukkar]

@schweigstill I started to investigate this and added support for zephyr to send CLOSE back to server. Unfortunately my test servers don't wait the client CLOSE so when zephyr tries to send it, the TCP connection is already terminated. So wondering what point there is to send CLOSE in the first place from client. What server are you using that waits client CLOSE?

[jukkar]

@schweigstill please try the fix for this and report if it works for you #96492

[jukkar]

Zephyr should send websocket CLOSE now when it receives CLOSE from server, this is fixed by #96492 so marking this as resolved.

[schweigstill]

Dear jukkar,

thank you very much for your very fast response to my question and creating a bug report! I was very busy for some days, so I have to apologize for my late response.

Unfortunately you solved a problem which is not related to my question. The problem which I mentioned occurs if the other party doesn't send a JSON CLOSE. Then the TCP connection can't be closed with zsock_close() on the Zephyr server side, and it never(?) reaches a timeout. This orphaned TCP connection is neither visible using "net sockets list" nor "net websocket". Instead zsock_shutdown() has to be used to be sure that the TCP connection will be closed. This can lead to a kind of DoS when a client doesn't close its connection properly. I experienced this when using a Python websocket client.

I noticed another strange behaviour when opening additional websocket connections to the Zephyr server. When the callback function for a new websocket connection fails with an error code, close_client_connection() is called multiple times. On the second invocation the file handle isn't valid anymore and client->service is a NULL pointer. This causes a crash. I have already implemented a fix and will created a pull request.

[schweigstill]

Pull request #96760.

[jukkar]

The problem which I mentioned occurs if the other party doesn't send a JSON CLOSE

Not sure what you mean by this, I don't see how this is related to Websocket protocol.