Webscoke tAfter updating to version 07b3c of the V1.6 version, there was a disconnection issue. (IDFGH-17104)

[PoohWooh]

Answers checklist.

• I have read the documentation for esp-protocols components and the issue is not addressed there.
• I have updated my esp-protocols branch (master or release) to the latest version and checked that the issue is present there.
• I have searched the issue tracker for a similar issue and not found a similar issue.

General issue report

Answers checklist.

• I have read the documentation for esp-protocols components and the issue is not addressed there.[x] I have updated my esp-protocols branch (master or release) to the latest version and checked that the issue is present there.[x] I have searched the issue tracker for a similar issue and not found a similar issue.

General issue report

Answers checklist.

• I have read the documentation for esp-protocols components and the issue is not addressed there.[x] I have updated my esp-protocols branch (master or release) to the latest version and checked that the issue is present there.[x] I have searched the issue tracker for a similar issue and not found a similar issue.

General issue report

Hello, since last month, I have been experiencing frequent automatic disconnection errors when using Websocket to connect to my server on ESP32C3. The error message is as follows: E (84615472) transport_ws: Error read data(0)

E (84615472) transport_ws: Error reading payload data(0)
E (84646412) transport_base: tcp_read error, errno=Software caused connection abort
E (84646412) transport_ws: Error read data(-2)
E (84646413) websocket_client: esp_transport_read() failed with -2, transport_error=ESP_OK, tls_error_code=0, tls_flags=0, errno=113
E (84646445) websocket_client: Error receive data
app: Moonraker WS:disconnected...
app: Moonraker WS finish...
E (84646493) transport_ws: Error transport_poll_write(-1)
E (84646494) websocket_client: esp_transport_write() returned -1, transport_error=ESP_OK, tls_error_code=0, tls_flags=0, errno=9
app: Moonraker WS:---ERROR!!! ... !!! ... !!!
app: Moonraker WS http_code: 0
app: Moonraker WS error_type: 1
app: Moonraker WS tls_last_esp_err: 0x0
appt: Moonraker WS tls_stack_err: 0x0
app: Moonraker WS esp_sock_errno: 0 (Success)
app: WS_ERROR_UNKNOWN
app: Moonraker retry WS_ERROR_UNKNOWN...
E (84646555) websocket_client: esp_websocket_client_abort_connection(258): Websocket already stop

This really confused me. I guess it might be due to some fluctuation in my network connection or because after connecting to the server, the server would send hundreds of bytes of data every second, causing the connection to time out? 

I attempted:

1. To replace the network and router, but it was ineffective.
2. To disable IPv6, but it was ineffective.
3. To try replacing the official development board, but it was also ineffective.
   Could you please help me move forward with this issue? Because I found many related questions in the closed questions section：
   esp_websocket_client: Close connection when wtite timeout which is unexpected (IDFGH-16792) #942
   esp_websocket_client can not send ping request when receive many data (IDFGH-16701) #927

If there are any new developments, feel free to contact me. I'm willing to do something about it.Wish everyone a wonderful day!

[gabsuren]

@PoohWooh thanks for raising this. Quick question: are you using WebSocket v1.6.0 or v1.6.1??
There was a fix in v1.6.1 not sure how much it's related with current issue doh, but worth to try/

Also, could you share your sdkconfig, especially:

* CONFIG_ESP_WS_CLIENT_SEPARATE_TX_LOCK
* CONFIG_ESP_WS_CLIENT_TX_LOCK_TIMEOUT_MS (if enabled)
* your `network_timeout_ms`, `ping_interval_sec`, and `pingpong_timeout_sec` (or defaults)

From your log:

• transport_ws: Error reading payload data(0) means the WS layer called into ws_read_payload() and got 0, which in this stack usually indicates a poll/read timeout.
• tcp_read error, errno=Software caused connection abort / errno=113 points to an underlying socket/network abort/unreachable (e.g. Wi‑Fi drop/roam, AP/NAT hiccup, server reset), not a “server sends too much data so it times out”.
• The later transport_poll_write(-1) + esp_transport_write() ... errno=9 (EBADF) typically happens when something tries to write after the transport/socket was already closed (often due to a reconnect/abort racing with another send/ping).

Things to try (to narrow it down / mitigate):

• Update to v1.6.1

• If you have multiple tasks sending, enable CONFIG_ESP_WS_CLIENT_SEPARATE_TX_LOCK (and consider increasing the TX lock timeout).

• Increase network_timeout_ms (and/or reduce aggressive timeouts) and check whether the disconnects correlate with temporary link loss.

• Ensure the app stops calling esp_websocket_client_send_*() after DISCONNECTED/ERROR (or guard sends with esp_websocket_client_is_connected()), to avoid the write-after-close path

Regards,
Suren

[PoohWooh]

Thank you for responding to my question so promptly.
SDK configuration is as follows:
#ESP WebSocket client

CONFIG_ESP_WS_CLIENT_ENABLE_DYNAMIC_BUFFER is not set
CONFIG_ESP_WS_CLIENT_SEPARATE_TX_LOCK=y
CONFIG_ESP_WS_CLIENT_TX_LOCK_TIMEOUT_MS=2000
end of ESP WebSocket client

#Additionally, the parameters for the ws-related links are as follows:

 esp_websocket_client_config_t ws_cfg = {
.host = broker_ip,
.port = broker_port,
.path = "/websocket",
.task_prio = 8,
.disable_auto_reconnect = true,

.buffer_size = 1024 * 3,
.keep_alive_enable = true,
.keep_alive_interval = 10,
.keep_alive_idle = 10,
.keep_alive_count = 3,
.network_timeout_ms = (35 * 1000),
.ping_interval_sec = 10,
};

#Additionally, I will indeed loop through the task to send a certain JSON data in order to interact with the server. However, I have made the following settings

if (esp_websocket_client_is_connected(p_websocket->client))
{
if (websocket_is_connected())
{
ws_send_loop(p_websocket);
}
}

The top part is the component's own API, and the inner function websocket_is_connected() is my state machine.

Finally, this issue occurred in the latest 1.60 version. Since I didn't find any changes when comparing it with the 1.61 version, I continued to use the TX lock branch from version 1.6.

Thank you for taking the time to answer my questions. I hope the information I provided will help you identify the problem!

[gabsuren]

@PoohWooh thanks for your response! Actually, there were important changes in v1.6.1 compared to v1.6.0, especially regarding
CONFIG_ESP_WS_CLIENT_SEPARATE_TX_LOCK=y.

You can see this in the changelog:
https://components.espressif.com/components/espressif/esp_websocket_client/versions/1.6.1/changelog?language=en

Could you please give it a try with v1.6.1 and send the log again, ideally with debug enabled?

Best regards,
Suren

[PoohWooh]

@PoohWooh thanks for your response! Actually, there were important changes in v1.6.1 compared to v1.6.0, especially regarding感谢您的回复！实际上，v1.6.1 相较于 v1.6.0 有重要的变化，尤其是在以下方面： CONFIG_ESP_WS_CLIENT_SEPARATE_TX_LOCK=y.CONFIG_ESP_WS_CLIENT_SEPARATE_TX_LOCK=y。

You can see this in the changelog:您可以在变更日志中看到这一点： https://components.espressif.com/components/espressif/esp_websocket_client/versions/1.6.1/changelog?language=en

Could you please give it a try with v1.6.1 and send the log again, ideally with debug enabled?请您尝试使用 v1.6.1 版本，并再次发送日志，最好启用调试模式？

Best regards,  此致， Suren  苏伦

Thank you for your reply. I will try the V1.6.1 version again and will announce the results after the test.

[PoohWooh]

@gabsuren Unfortunately, during these recent tests, there were still unexpected disconnections. Tonight, I will open the log and set the level to Debug.

[bryghtlabs-richard]

E (84646413) websocket_client: esp_transport_read() failed with -2, transport_error=ESP_OK, tls_error_code=0, tls_flags=0, errno=113

Errno 113 is a route issue right?

Do you see the same disconnection if you connect to a websocket server on the same local network?

[gabsuren]

Hi @PoohWooh, just wanted to follow up on this issue.

Were you able to reproduce the disconnection with debug logs enabled, or test it against a WebSocket server on the same local network?

Any update would be helpful, especially whether the issue still happens with v1.6.1 and whether it only occurs with the Moonraker endpoint.

Regards,
Suren