ESP32-P4 disconnects after ~40 seconds: WebSocket close 1000 or mbedTLS -0x7780

Getting Started
1

Hi everyone,

I am testing the LiveKit ESP32 SDK on an ESP32-P4, but the signaling connection disconnects repeatedly after approximately 35–45 seconds.

Hardware and software

  • ESP32-P4 revision 1.3
  • ESP32-C6 Wi-Fi coprocessor
  • ESP-Hosted over 4-bit SDIO at 40 MHz
  • ESP-Hosted host and coprocessor firmware: 3.0.0
  • ESP-IDF: 5.5.4
  • LiveKit ESP32 SDK: 0.3.10
  • LiveKit Cloud
  • OV5647 MIPI camera
  • Hardware H.264 encoder
  • Video pipeline: 800x800 at 20 fps

What works

The device connects successfully to the LiveKit room.

The following stages complete successfully:

  • Signaling WebSocket connection
  • ICE candidate negotiation
  • DTLS handshake
  • SRTP connection
  • SCTP data channels
  • H.264 video pipeline
  • LiveKit signaling PING/PONG

PING/PONG runs every 5 seconds. The measured RTT is usually around 410–430 ms.

Problem

After approximately 35–45 seconds, the signaling WebSocket disconnects.

I see two different failure modes.

Failure mode 1: WebSocket close code 1000

I livekit_signaling: PING sent: rtt=415 ret=0 ws_connected=1
I livekit_signaling: PONG received: rtt=426
E livekit_signaling: WebSocket CLOSE: code=1000 reason= len=2
W transport_ws: unexpected data readable on socket
W websocket_client: Connection terminated while waiting for clean TCP close
I livekit_engine: Reconnect ..., reason=21
E livekit_example: Failure reason: Other

I livekit_signaling: PING sent: rtt=419 ret=0 ws_connected=1
E esp-tls-mbedtls: read error :-0x7780
E transport_ws: Error read data(-30592)
E websocket_client: ESP_ERR_MBEDTLS_SSL_READ_FAILED
E livekit_signaling: transport_err=0x801d
E livekit_signaling: tls_stack_err=0x7780
E livekit_signaling: tls_flags=0x0
I livekit_engine: Reconnect …, reason=1
E livekit_example: Failure reason: Unreachable

2

Do you have a session ID and even better complete logs from the device?

Without more logs and session Id it is hard to know.

Things worth trying, in order:

  1. Disable Wi-Fi power save: esp_wifi_set_ps(WIFI_PS_NONE); after Wi-Fi init. If your RTT drops from ~420 ms to tens of ms, that was it — power save on the C6 is notorious for adding hundreds of ms of latency and it may be enough to trip the server’s ICE timeout.
  2. Run the same test without publishing video (audio-only, or just join the room). If the connection then stays up indefinitely, the video bitrate is likely overwhelming the uplink.
  3. If video is the issue, try 640×480@15 or cap the encoder bitrate around 1 Mbps and step up from there. Keep in mind the C6 is 2.4 GHz-only, so real-world uplink headroom can be small on a congested channel.
  4. Watch the RTT trend in your logs right before a disconnect — if it climbs steadily, that’s queue buildup on the uplink.

If you can share the session ID (from the earlier ask) I can confirm from our side what close reason the server recorded — it should show up as a transport failure if the above is right.