TCP Ports stuck in CLOSE-WAIT on ARI WebSocket disconnects

We have a client application that is utilizing Websocket connections with ARI to listen for events and control the call flow. There is a certain limitation on the client side that sometimes causes Websockets to close unexpectedly, i.e. with a code of 1006 and message “WebSocket disconnected without sending Close frame”.
I believe this is causing some TCP ports on the asterisk side to get stuck in a CLOSE-WAIT state and they are never cleaned up due to a lack of graceful Websocket connection shut down.

Is this a known issue? I haven’t been able to find anything regarding this, so any pointers would be helpful. Otherwise, we’re just looking to handle this in the best way possible and would appreciate any guidance while we look for solutions to address the root issue, i.e. the client side restriction.

Asterisk Version: 21.4.3.
Happy to provide any additional info!
Thank you!

It’s not clear to me which side is which here, but the side that is in the CLOSE-WAIT state is the one at fault.

The asterisk server side is the one ending up with a bunch of ports stuck in the CLOSE-WAIT state, and the client application is the one where the websocket abruptly disconnects sometimes, which I believe is causing the CLOSE-WAIT ports on the asterisk server due to a lack of graceful disconnect. Hmm, what makes you say that the side with the CLOSE-WAITs (asterisk server in this case) is at fault?

Close wait means that it should know the other side has closed, and it is the only side that can change the half close into a full close.

I’m not sure how non-blocking reads are handled, but a blocking read would have returned end of file.

Thanks for your thoughts David, helped me go back and figure out the root issue. The root issue was not with inbound WS connections, but with outbound WS connections, related to the module “app_audiofork”. Basically it wasn’t disposing closed websockets properly, thus causing connections to get stuck and eventually the server would run out of available ports. We pushed out a patch and were able to resolve it!