zsock_close() doesn't fully close TCP connection of Websocket #96418
-
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 |
Beta Was this translation helpful? Give feedback.
Replies: 4 comments 2 replies
-
@schweigstill could you create a proper issue for this so this is not forgotten? |
Beta Was this translation helpful? Give feedback.
-
@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? |
Beta Was this translation helpful? Give feedback.
-
@schweigstill please try the fix for this and report if it works for you #96492 |
Beta Was this translation helpful? Give feedback.
-
Zephyr should send websocket CLOSE now when it receives CLOSE from server, this is fixed by #96492 so marking this as resolved. |
Beta Was this translation helpful? Give feedback.
Zephyr should send websocket CLOSE now when it receives CLOSE from server, this is fixed by #96492 so marking this as resolved.